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児のパパ。