Metadataは、HorizontalPodAutoscaler(HPA)、Event、LimitRangeなどといったものがあります。

Metadataには含まれませんが、HPAの類似リソースのVerticalPodAutoscaler(VPA)についても併せて紹介します。Label/Annotationもここで紹介します。

リソースを定義するYAMLの記述方法の詳細はAPIドキュメントを参照ください。

リソースタイプ(再掲)

マシンリソースをスケールさせる

マシンリソースを固定的に利用する場合は、ReplicaSetによりPod数を定義可能です。3つ必要なら3を、5つ必要なら5を、といった具合にYAMLファイル内で固定値を定義し、性能や信頼性を担保します。

一方で、オートスケーリングと呼ばれ、負荷に応じて自動的にノードの数などを増減させる機能もあります。クラウド環境などにおいて採用されることが多くなってきています。Kuberntesを利用する場合は、HorizontalAutoScaler(HPA)を用いることでオートスケーリングを実現します。HPAリソースは、CPUやメモリの使用状況に応じて、Pod数を増減させるリソースです。

また、VerticalAutoScaler(VPA)を用いることで、動的な垂直スケーリングを実現します。HPAとは異なり、CPUやメモリの状況に応じて、Pod数を増減させるのではなく、Podに割り当てるCPUやメモリの量を増減させます。

誤解を恐れずにカンタンに言うならば、Webサーバなど永続化データを持たないサーバに対しては水平スケーリングを、DBサーバなど永続化データを持つサーバに対しては垂直スケーリングを利用します。

HPAとVPAの違い

動的スケーリング種別 増減対象 主な用途
HPA 水平 Pod数 Webサーバ
VPA 垂直 CPU/メモリ DBサーバ

Kubernetesの状態を確認する

「kubectlコマンドを用いて環境構築したがなぜか動作しない」「指定したYAMLのどこかが間違っているはずだが、原因がわからない」――こういったトラブルはだれしもが経験したことがあるのでしょうはないでしょうか。本節では、Kubernetesの状態を確認することで、その後の対処につなげるためのやり方を紹介します。

Eventはkubectlコマンドで実施した操作などを記録したリソースです。kubectl get eventsと実行することで、各リソースのさまざまな状態を確認することができます。

$kubectl get events
LAST SEEN   TYPE      REASON             OBJECT                       MESSAGE
2m10s       Warning   BackOff            pod/busybox-sleep            Back-off restarting failed container
2m3s        Warning   FailedNeedsStart   cronjob/hello                Cannot determine if job needs to be started: too many missed start time ( > 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew
30h         Normal    Pulling            pod/myapp-replicaset-6lp7p   Pulling image "busybox"
30h         Normal    Pulled             pod/myapp-replicaset-6lp7p   Successfully pulled image "busybox"
30h         Normal    Created            pod/myapp-replicaset-6lp7p   Created container myapp-container
30h         Normal    Started            pod/myapp-replicaset-6lp7p   Started container myapp-container
30h         Normal    Pulling            pod/myapp-replicaset-ggxnt   Pulling image "busybox"
30h         Normal    Pulled             pod/myapp-replicaset-ggxnt   Successfully pulled image "busybox"
30h         Normal    Created            pod/myapp-replicaset-ggxnt   Created container myapp-container
30h         Normal    Started            pod/myapp-replicaset-ggxnt   Started container myapp-container
30h         Normal    Pulling            pod/myapp-replicaset-qg92c   Pulling image "busybox"
30h         Normal    Pulled             pod/myapp-replicaset-qg92c   Successfully pulled image "busybox"
30h         Normal    Created            pod/myapp-replicaset-qg92c   Created container myapp-container
30h         Normal    Started            pod/myapp-replicaset-qg92c   Started container myapp-container

個別のリソース状態を確認するためにはkubectl describeを実行します。Events欄において、先ほどkubectl get eventsにおいて表示した内容が表示されています。他にもContainers欄においては利用しているコンテナイメージや起動状況などが表示されています。

構築したリソースが意図した設定になっているか、想定外のステータスで止まっていないかなどを確認しみると良いでしょう。

$kubectl describe pod myapp-replicaset-6lp7p
Name:           myapp-replicaset-6lp7p
Namespace:      default
Priority:       0
Node:           minikube/10.0.2.15
Start Time:     Mon, 02 Sep 2019 06:53:17 +0900
Labels:         app=myapp
Annotations:    <none>
Status:         Running
IP:             172.17.0.5
Controlled By:  ReplicaSet/myapp-replicaset
Containers:
  myapp-container:
    Container ID:  docker://e143b4c7bf867c6e904d27f9847eb1b62a361e8690723cfd43ec18f07e594917
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:fe301db49df08c384001ed752dff6d52b4305a73a7f608f21528048e8a08b51e
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
      echo Hello Kubernetes! && sleep 3600
    State:          Running
      Started:      Sat, 14 Sep 2019 02:42:03 +0900
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Mon, 09 Sep 2019 08:39:17 +0900
      Finished:     Sat, 14 Sep 2019 02:41:56 +0900
    Ready:          True
    Restart Count:  2
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-4vvvb (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-4vvvb:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-4vvvb
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason   Age               From               Message
  ----    ------   ----              ----               -------
  Normal  Pulling  30h (x2 over 6d)  kubelet, minikube  Pulling image "busybox"
  Normal  Pulled   30h (x2 over 6d)  kubelet, minikube  Successfully pulled image "busybox"
  Normal  Created  30h (x2 over 6d)  kubelet, minikube  Created container myapp-container
  Normal  Started  30h (x2 over 6d)  kubelet, minikube  Started container myapp-container

個別のリソースのログを確認するには、kubectl logsを実行します。意図したログが出力されているか確認すると良いでしょう。以下の例では、起動時にechoコマンドで「Hello Kubernetes!」と出力させた結果が記録されています。

$kubectl logs myapp-replicaset-6lp7p
Hello Kubernetes!

マシンリソースの使用状況を確認するにはkubectl topを利用します。NodeやPod単位に確認できますので、試してみてください。

$kubectl top nodes
NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
minikube   183m         9%     1152Mi          60%
$kubectl top pods
NAME                                CPU(cores)   MEMORY(bytes)
hello-deployment-6cfcb7d478-5rkd6   0m           2Mi
hello-deployment-6cfcb7d478-9rqct   0m           2Mi
hello-deployment-6cfcb7d478-f4c9t   0m           4Mi
myapp-replicaset-6lp7p              0m           0Mi
myapp-replicaset-ggxnt              0m           0Mi
myapp-replicaset-qg92c              0m           0Mi

 

LabelとAnnotation

LabelとAnnotaionについては、Metadataリソースではないですが、これまで紹介してきたリソースタイプを取り扱うために押さえておくべき考え方なので、ここで紹介します。

LabelはPodなどのリソースに付与するKey-Valueのペアです。例えば、metadata.label.environmentにprocuction(本番環境)を定義しておくことで、本番環境のPodだけを抽出することができます。

$cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    environment: production
spec:
  containers:
    - name: nginx-container
      image: nginx
      ports:
      - containerPort: 80
$kubectl get pod -l environment=production
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          85s

以下のように、Podに定義されているLabelを表示することができます。

$kubectl get po --show-labels
NAME                                READY   STATUS             RESTARTS   AGE   LABELS
myapp-replicaset-6lp7p              1/1     Running            4          14d   app=myapp
myapp-replicaset-ggxnt              1/1     Running            4          14d   app=myapp
myapp-replicaset-qg92c              1/1     Running            4          14d   app=myapp
nginx-pod                           1/1     Running            0          13m   environment=production

Deploymentリソースを作成する際、keyにapp、valueにhello-podを指定しておきます。spec.selector.matchLabelsにてhello-podを指定することで、対応するPodを生成します。

$cat v1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-pod
  template:
    metadata:
      labels:
        app: hello-pod
    spec:
      containers:
      - name: hello
        image: nginx
        ports:
        - containerPort: 80

次にAnnotationを説明します。

AnnotationもLabelと同様Key-Valueのペアです。ビルド番号の記録などに利用されます。Labelとは異なり、Selectorなどマニフェストの中での参照には利用されません。

$kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
hello-deployment   3/3     3            3           19d
$kubectl annotate --overwrite deployment hello-deployment ver=1.0.0
deployment.extensions/hello-deployment annotated
$kubectl describe deployment/hello-deployment

~中略~

Labels:                 app=hello-pod
Annotations:            deployment.kubernetes.io/revision: 1
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"hello-pod"},"name":"hello-deployment","namespace...
                        ver: 1.0.0
~後略~

*  *  *

今回はMetadataリソースタイプについて説明しました。HPAやVPAといったリソースをスケールさせる技術や、EventなどのKubernetesの状態を確認する技術を紹介しました。併せて、各リソースに対して付与する情報を取り扱うLabel/Annotationを紹介しました。

連載第5~9回にかけてWorkloads/Discovery & LB/Config & Storage/Cluster/Metadataリソースタイプを紹介しました。Kubernetesを学ぶ上でのベースとなりますので、一通り押さえておくと良いでしょう。

次回以降は、Rancherなどの構築ツール、マイクロサービス構築のためのIstioなどKubernetesを取り巻く技術を紹介していきます。

著者紹介


正野 勇嗣 (SHONO Yuji ) - NTTデータ 課長

2011年まで開発自動化技術のR&Dに従事。その後、開発プロジェクト支援やトラブルシューティング等に主戦場を移す。「ソースコード自動生成」に加えて、JenkinsやMaven等の「ビルド自動化」、JsTestDriverやSelenium等の「テスト自動化」を扱うようになり、多様化する開発自動化技術動向に興味。

最近は第四の自動化であるInfrastructure as Code等の「基盤自動化」の魅力に惹かれている。開発自動化技術に関する雑誌・記事執筆も行う。3児のパパ。