(O+P)ut

アウトプット



(O+P)ut

Output Log

【Kubernetes】PodのQoSクラス:Guaranteed/Burstable/BestEffortについて

スポンサーリンク

はじめに

Kubernetesではコンテナを管理するためにコンテナが使用できるリソースを制限することが可能です。
それに伴いノードがコンテナに割り当てるリソースを管理することができますが、万が一ノードが割り当てられる以上のリソース要求があった場合はPodを強制終了することで空きリソースを確保する動きを取ります。

本記事では特定のPodに対して以下のサービス品質レベルを設定する流れを説明します。

  • Guaranteed
  • Burstable
  • BestEffort
環境情報
$ kubectl get nodes
NAME            STATUS   ROLES    AGE     VERSION
test1   Ready    master   4m29s   v1.15.7
test2   Ready    worker   4m6s    v1.15.7
test3   Ready    worker   4m8s    v1.15.7

BestEffort

ベストエフォート、つまりPodのリソース要求や制限がない状態なので最も優先度が低いQoSです。

例えば以下のようなyamlを

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

以下のようにPodが生成されます。

$ kubectl apply -f nginx.yaml
deployment.apps/nginx-deployment created
$ kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP              NODE            NOMINATED NODE   READINESS GATES
nginx-deployment-5754944d6c-xzngz   1/1     Running   0          16s   192.168.111.1   test3   <none>           <none>

該当のPodの詳細情報にて以下のように「BestEffort」という文言があります。

$ kubectl describe pods nginx-deployment-5754944d6c-xzngz | grep QoS
QoS Class:       BestEffort

Burstable

Podのリソースの要求はあるが制限がない状態をBurstableと言い、QoSで言えばBestEffortよりも優先度が高くGuaranteedより優先度が低いクラスです。

先ほどのyamlのspec.template.spec.containersの下にresources.requestsを追記します。

以下はCPUを500ミリを要求し、メモリを128MiB要求しています。

...
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        resources:
          requests:
            cpu: 500m
            memory: 128Mi
        ports:
        - containerPort: 80

こちらを再度適用して

$ kubectl apply -f nginx.yaml
deployment.apps/nginx-deployment configured
$ kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP              NODE            NOMINATED NODE   READINESS GATES
nginx-deployment-5856b795ff-w7qq5   1/1     Running   0          22s   192.168.111.2   test3   <none>           <none>

QoS Classを確認すると確かに「Burstable」となっています。

$ kubectl describe pods nginx-deployment-5856b795ff-w7qq5 | grep QoS
QoS Class:       Burstable

割り当てノードを見ると以下のようになっておりリクエストが反映されています。

$ kubectl describe nodes test3
...
  Namespace                  Name                                 CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                 ------------  ----------  ---------------  -------------  ---
  default                    nginx-deployment-5856b795ff-w7qq5    500m (25%)    0 (0%)      128Mi (3%)       0 (0%)         8m5s
  kube-system                calico-node-sppjx                    250m (12%)    0 (0%)      0 (0%)           0 (0%)         25m
  kube-system                kube-proxy-p776n                     0 (0%)        0 (0%)      0 (0%)           0 (0%)         25m
....

Guaranteed

最後のQoSですが、こちらはリソース要求と制限が設定されている&値が等しい 場合で最も優先度が高くなります。
ここでの制限とはコンテナが利用できる最大量のリソースを指し、これを超えてリソースを消費しにいこうとするとKubernetesが制限内に抑えます。

yamlファイルでは以下のようにlimitsをrequestsと同じ値で追記すれば

..
resources:
          requests:
            cpu: 500m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 128i
...

起動したPodには

$ kubectl apply -f nginx.yaml
deployment.apps/nginx-deployment configured
$ kubectl get pods -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP                NODE            NOMINATED NODE   READINESS GATES
nginx-deployment-cbb7c5b4c-pmj8n   1/1     Running   0          10s   192.168.163.196   test2   <none>           <none>

Guaranteedが設定されています。

$ kubectl describe pods nginx-deployment-cbb7c5b4c-pmj8n | grep QoS
QoS Class:       Guaranteed

ちなみにリソース要求に対してリソース制限の方が大きく設定している場合はGuaranteedではなくBurstableとなります。

終わりに

以下記事でも触れたKubernetesのリソース管理ですが
https://www.mtioutput.com/entry/kube-heapster-topcmd
サーバの資源が逼迫すればBestEffort→Burstable→Guaranteedの順でPodが停止候補として選定されていきます。

動的に圧縮可能なCPUとは異なり、メモリに関してはプロセスを落とすことでメモリを解放しにいくのでこの動きは覚えておくと役立ちます。

以上、ご参考になれば幸いです。


他の記事を読む