はじめに

前回はリソース制御の基本的な動作を確認しました。
今回は前回に続いて、こういう場合はどうなるんだろう？ということを実際に確認してみたいと思います。
なお、今回はCPUだけに絞って検証していきます。

リソース不足の場合

今回の検証環境のworkerノードは2vCPU（2000m）搭載しています。
ここにNginxとRedis 2つのコンテナを持つPodをデプロイしますが、requestsとlimitsを以下の図のように設定します。
requests（下限）の合計が2200mとなり、workerノードのリソースを超えています。

このPodをデプロイします。マニフェストは前回と同様で、requestsとlimitsの値が異なるだけです。

$ kubectl apply -f nginx_redis-quota.yaml
deployment.apps/resource-quota created
$ kubectl get pod
NAME                                 READY   STATUS    RESTARTS   AGE
no-resource-quota-77d577889b-2lsck   2/2     Running   0          45s
no-resource-quota-77d577889b-mlgvr   2/2     Running   0          46s
resource-quota-6bfdcb475d-5hqn5      0/2     Pending   0          9s
resource-quota-6bfdcb475d-fjk29      0/2     Pending   0          9s

PodがPendingとなりました。詳細を確認します。

$ kubectl describe pod resource-quota-6bfdcb475d-5hqn5
Name:           resource-quota-6bfdcb475d-5hqn5
・・・
Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  36s (x2 over 36s)  default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

CPUが足りなくてスケジューリングできていませんね。
前回確認した結果だとrequestsの値は、無負荷状態では確保されていなかったですが、requestsの合計値がノードのvCPUを超えるとスケジューリングできないようですね。

リソース競合の場合

requestsとlimitsの値を変更して、「requestsの合計＜ vCPU ＜ limitsの合計」としました。

$ kubectl apply -f nginx_redis-quota.yaml
deployment.apps/resource-quota configured
$ kubectl get pod
NAME                                 READY   STATUS    RESTARTS   AGE
no-resource-quota-77d577889b-2lsck   2/2     Running   0          32m
no-resource-quota-77d577889b-mlgvr   2/2     Running   0          32m
resource-quota-7549bdf4df-845dw      2/2     Running   0          19s
resource-quota-7549bdf4df-r9rc6      2/2     Running   0          10s

設定値を確認しておきます。

$ kubectl describe node k8s-worker01
Name:               k8s-worker01
・・・
Non-terminated Pods:          (5 in total)
  Namespace                   Name                                  CPU Requests  CPU Limits    Memory Requests  Memory Limits  AGE
  ---------                   ----                                  ------------  ----------    ---------------  -------------  ---
  default                     no-resource-quota-77d577889b-mlgvr    0 (0%)        0 (0%)        0 (0%)           0 (0%)         40m
  default                     resource-quota-7549bdf4df-845dw       1500m (75%)   2500m (125%)  300Mi (10%)      500Mi (18%)    8m24s
  kube-system                 calico-node-cgdgk                     250m (12%)    0 (0%)        0 (0%)           0 (0%)         80d
  kube-system                 kube-proxy-gqt42                      0 (0%)        0 (0%)        0 (0%)           0 (0%)         80d
  metallb-system              speaker-scqps                         100m (5%)     100m (5%)     100Mi (3%)       100Mi (3%)     36d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                1850m (92%)  2600m (130%)
  memory             400Mi (14%)  600Mi (21%)
  ephemeral-storage  0 (0%)       0 (0%)

Requestsの設定値は92％ですが、Limitsは130％とvCPUの値を超えていますね。

動作確認

各コンテナにログインして、CPUに負荷をかけてCPUの使用率を確認します。
ただ、Pod単位でしか負荷がわからないので、Podを作り直すことにしました。以下のように1Pod/1コンテナにしました。

リソース制御しているPodはReplicaSetをスケールしても良かったんですが、設定値が異なる場合にどのようになるのか確認したかったので、別のDeploymentにしました。

$ kubectl get pod -o wide
NAME                                 READY   STATUS    RESTARTS   AGE   IP               NODE           NOMINATED NODE   READINESS GATES
no-resource-quota-77d577889b-2lsck   2/2     Running   2          23h   192.168.69.252   k8s-worker02   <none>           <none>
no-resource-quota-77d577889b-mlgvr   2/2     Running   2          23h   192.168.79.77    k8s-worker01   <none>           <none>
resource-quota1-557b598fc9-2lqqg     1/1     Running   1          17h   192.168.79.66    k8s-worker01   <none>           <none>
resource-quota1-557b598fc9-8bcdr     1/1     Running   1          17h   192.168.69.205   k8s-worker02   <none>           <none>
resource-quota2-565c7b64fc-8tr5r     1/1     Running   1          17h   192.168.79.76    k8s-worker01   <none>           <none>
resource-quota2-565c7b64fc-qtng4     1/1     Running   1          17h   192.168.69.251   k8s-worker02   <none>           <none>

まずはrequests:500m/limits:1000mのPodに負荷をかけます。

$ kubectl exec -it resource-quota1-557b598fc9-2lqqg /bin/bash
root@resource-quota1-557b598fc9-2lqqg:/# yes >/dev/null &
[1] 12
root@resource-quota1-557b598fc9-2lqqg:/# yes >/dev/null &
[2] 13

CPU使用率を確認します。

$ kubectl top pod
NAME                                 CPU(cores)   MEMORY(bytes)
no-resource-quota-77d577889b-2lsck   2m           11Mi
no-resource-quota-77d577889b-mlgvr   2m           11Mi
resource-quota1-557b598fc9-2lqqg     992m         2Mi
resource-quota1-557b598fc9-8bcdr     0m           1Mi
resource-quota2-565c7b64fc-8tr5r     0m           1Mi
resource-quota2-565c7b64fc-qtng4     0m           1Mi

ほぼlimitsの値になってますね。

次にrequests:1000m/limits:1500mのPodに同様に負荷をかけ、CPU使用率を確認します。

$ kubectl top pod
NAME                                 CPU(cores)   MEMORY(bytes)
no-resource-quota-77d577889b-2lsck   1m           11Mi
no-resource-quota-77d577889b-mlgvr   1m           11Mi
resource-quota1-557b598fc9-2lqqg     625m         2Mi
resource-quota1-557b598fc9-8bcdr     0m           1Mi
resource-quota2-565c7b64fc-8tr5r     1251m        2Mi
resource-quota2-565c7b64fc-qtng4     0m           1Mi

どちらもrequestsを超えて同じような比率でリソースを分け合っていますね。
なお、この時点でノードのvCPUは使い切っています。

$ kubectl top node
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k8s-master     209m         10%    1007Mi          36%
k8s-worker01   2000m        100%   484Mi           17%
k8s-worker02   129m         6%     525Mi           19%

さらに、制限をかけていないPodにログインして同様に負荷をかけ、CPU使用率を確認します。

$ kubectl top pod
NAME                                 CPU(cores)   MEMORY(bytes)
no-resource-quota-77d577889b-2lsck   2m           11Mi
no-resource-quota-77d577889b-mlgvr   4m           11Mi
resource-quota1-557b598fc9-2lqqg     626m         2Mi
resource-quota1-557b598fc9-8bcdr     0m           1Mi
resource-quota2-565c7b64fc-8tr5r     1280m        2Mi
resource-quota2-565c7b64fc-qtng4     0m           1Mi

5分ほど待ってみましたが、制限をかけていないPod（no-resource-quota-77d577889b-mlgvr）は使用率がほとんど上がりませんでした。

まとめ

前回は、「リソース制御をしていないPod -> リソース制御をしているPod」の順に負荷をかけました。リソース制御をしていないPodだけでCPUを使い切っている状態でリソース制御しているPodに負荷をかけると、requests（下限）ではなく、limits（上限）までPodはCPUを割り当てられました。
ということは、リソースの割り当ては早い順ではなく、リソース制御の設定値（requestsだけでなくlimitsも）が優先されて、リソース制御していないPodは他のPodの上限値まで割り当てたあとの余りのリソースが割り当てられるということになりますね。