Kubernetesは、コンテナアプリケーションをデプロイするためのオーケストレーションツールです。Kuberenetesは分散環境におけるスケーラブルなコンテナ実行環境をつくるための、さまざまな機能が提供されています。
もともとはGoogleが開発したBorgをもとにOSS化したものですが、今日ではマイクロソフトや（ry
Kubernetesをつかうとステートレスでマイクロサービス的なアプリケーションを1日に何度もデプロイでき、スパイクアクセスがきても水平スケールが容易なので、大規模Webシステムでスケーラブルな基盤を作れる、というのは広く知られています。
一方、Kubernetesには「Resource Requests」という機能があり、これはPodをデプロイする時に必要とするリソース(CPU/メモリ)を指定できるものです。これにより、Kubernetesクラスタのリソースの使用率を高め、効率よくアプリを稼働させることができるのも、うれしさの一つです。
Kubernetesではコンテナが使用するコンピューティングリソースを明示的に要求したり制限をかけたりすることができます。
リソース要求(Resource Request)
- コンテナに対して指定したリソースが使えるように保証するしくみ
- アプリを動かすのに最低限必要なリソースを指定
リソース制限(Resurce Limits)
- コンテナのリソース使用量の上限を決めるしくみ
- アプリケーションが使用する可能性のある最大リソースを指定
ということで、、、まずはメモリのリソース要求(Resource Request)ついて、
- コンテナアプリが使うメモリを明示的に要求するとクラスタ上でどういう動きをするのか？
- メモリをたくさん使う別アプリが邪魔してきたとき、きちんとシステムは動作するのか？
が気になり、簡単な検証をしてみました。
前提読者
- Dockerの使い方が分かる人
- クラウドマネージド(AKSまたはGKE)でKubernetesクラスタが構築できる人
- Kubernetesの基本コマンドを知っている人
実験環境
AzureのKubernetesのフルマネージドサービスであるAKSを使います。公式サイトをもとにKubernetesクラスタを構築しました。
クイック スタート:Azure Kubernetes Service クラスターをデプロイする | Microsoft Docs
ここでは、次の構成のクラスタで実験します。
MasterもNodeもkubernetes1.9.6で検証しています。
コンテナアプリが使うメモリを明示的に要求するとクラスタ上でどういう動きをするのか？
Kubernetesがシステムで使用するメモリ量を確認
今回のクラスタはAzure VMの「Standard_D1_v2」をNodeにつかっています。Standard_D1_v2は1台当たり約3.3GBのメモリが使えます。
念のため、次のコマンドで確認します。
$ kubectl describe node Name: aks-nodepool1-12354740-1 Roles: agent Labels: agentpool=nodepool1 ～中略～ Capacity: memory: 3501592Ki Allocatable: memory: 3399192Ki ～中略～ Name: aks-nodepool1-12354740-2 Roles: agent Labels: agentpool=nodepool1 Capacity: memory: 3501592Ki Allocatable: memory: 3399192Ki
Node上ではkube-proxy等も動作しているため、Podを1つも動作させていない状態でも、223M／499Mのメモリを使用しています。
$ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% aks-nodepool1-12354740-1 28m 2% 223Mi 6% aks-nodepool1-12354740-2 128m 12% 499Mi 15%
アプリを動かすのに必要なメモリを要求してPodを動かす
まずは、Resource Requestの動きを確認します。コンテナに制限をかけるには[resources:]－[requests:]で値を指定します。 次の例(resource-pod.yaml)は、「nginx」の公式イメージをもとに動かしたコンテナが1つ含まれるPodをテンプレートとして定義し、それを「replicas: 2」つまり2つのPodがKubernetesクラスタ上にスケジューリングされる定義になります。
その際、メモリのリソース要求として[memory: 1.5Gi]を指定します。つまりこれはKubernetes に対して「このPodにあるNginxコンテナは1.5Giのメモリ必要だからよろしく！」を宣言しています。
apiVersion: apps/v1 kind: ReplicaSet metadata: name: reqest-exp spec: replicas: 2 selector: matchLabels: app: replicaset-temp template: metadata: labels: app: replicaset-temp spec: containers: - name: pod-sample image: nginx resources: requests: memory: 1.5Gi
これを次のコマンドを実行してクラスタ上でリソースを作ります。
$ kubectl create -f resource-pod.yaml replicaset.apps "reqest-exp" created
PodがそれぞれNode1とNode2で1つずつ動いています。
$ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE reqest-exp-9kztw 1/1 Running 0 55s 10.244.2.153 aks-nodepool1-12354740-2 reqest-exp-b4t8h 1/1 Running 0 55s 10.244.3.184 aks-nodepool1-12354740-1
絵で描くとこんな感じ。
ただ、起動しているNginxは何も仕事をしていないので、実際のメモリ使用量はほとんど増えていません。
$ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% aks-nodepool1-12354740-1 33m 3% 251Mi 7% aks-nodepool1-12354740-2 133m 13% 505Mi 15%
要求されたメモリが実際のメモリを超えるとどうなるか
次のコマンドを実行して、Podのレプリカ数を2から3に増やします。どうなるかをみてみます。
$ kubectl scale --replicas=3 -f resource-pod.yaml replicaset.apps "reqest-exp" scaled
Node1に2つのPod、Node2に1つのPodが動いています。まだ定義ファイルで要求した総メモリ量は、実際のクラスタのメモリ量を超えていません。
$ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE reqest-exp-9kztw 1/1 Running 0 8m 10.244.2.153 aks-nodepool1-12354740-2 reqest-exp-b4t8h 1/1 Running 0 8m 10.244.3.184 aks-nodepool1-12354740-1 reqest-exp-wzg7t 1/1 Running 0 43s 10.244.3.185 aks-nodepool1-12354740-1
絵で描くとこんな感じです。
次はレプリカ数を3から4に変更します。
$ kubectl scale --replicas=4 -f resource-pod.yaml replicaset.apps "reqest-exp" scaled
4つ目のPodである「reqest-exp-fgrpn」はどこのNodeでも起動せず「Pending」になっているのが分かります。
$ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE reqest-exp-9kztw 1/1 Running 0 13m 10.244.2.153 aks-nodepool1-12354740-2 reqest-exp-b4t8h 1/1 Running 0 13m 10.244.3.184 aks-nodepool1-12354740-1 reqest-exp-fgrpn 0/1 Pending 0 12s <none> <none> reqest-exp-wzg7t 1/1 Running 0 5m 10.244.3.185 aks-nodepool1-12354740-1
またまた絵で描くとこんな感じ。
しつこいですが、実際のメモリ使用量はほとんど増えていません。つまり実際はアイドル状態なのに4つ目のPodはスケジューリングされていないということをいっています。これは、4つ目のPodを配置しようとしても、メモリの空きがマニュフェストで定義した「1.5GB」を確実に確保できるスペースがNode上にないからこのような状態になっています。
$ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% aks-nodepool1-12354740-1 30m 3% 259Mi 7% aks-nodepool1-12354740-2 133m 13% 507Mi 15%
なぜ、4つ目のPodはスケジューリングされなかったのか
KubernetesのResource Requestsは、Podに対して指定したリソースが使えるように保証する仕組みです。
この値はPodをNodeにスケジューリングするときに使われます。Resource Requestsを指定したコンテナを含むPodを作成すると、KubernetesのスケジューラーはNodeを選択して実行します。その際、各Nodeには、各リソースタイプの最大容量をもっていてスケジューラは、各リソースタイプに対して、スケジュールされたコンテナのリソース要求の合計がノードの容量よりも少ないことをチェックします。たとえ実際のメモリ使用率は非常に低くても、スケジューラはチェックが失敗した場合はNodeにPodを配置しません。
Managing Compute Resources for Containers - Kubernetes
なおこのResource Requestsの設定はPodではなく、コンテナに対して行われます。今回指定したメモリはバイト単位で設定でき、E／P／T／G／M／K（Ei／Pi／Ti／Gi／Mi／Ki）のいずれかを使用して、メモリを整数または固定小数点整数として指定します。
今回のケースでは、実際のメモリがたくさん空いているにもかかわらずPodは配置されませんでした。Nodeのメモリの最大容量は分かっているので、あらかじめ基盤の方式設計段階でNodeにぎゅうぎゅうにPodがスケジューリングされることを避けることができます。
ただ、、、今回は同じサイズのNodeで検証しているのできちんと2台でスケジューリングされそうな気もしますが、なにか見落としているのかもわかりません。というわけで、ソースコードをきちんと読みたいと思います。 (理由をご存知の人がいればおしえてください)
追記：まかべ@マイクロソフトさんから教えてもらいました！ご指摘通り、Node1だけheapsterが動いておりました。すっきり理解しました。 (以下原文ママ)前半のMemory Requestsについてですが、片方のNodeだけheapsterが動いていて非対称なので、その分メモリが296Mi足りなくて4つめのPodが行儀よく待っちゃってるかも。heapster分を考慮してPodごとのRequestを1.3Giにしたら、4つ動きました。
メモリをたくさん使う別アプリが邪魔してきたとき、きちんとシステムが動作するのか？
Kubernetesでは「Resource Requests」で宣言した分のメモリをきっちり確保してPodをスケジューリングしているのが分かりました。このResource Requestsは、実際のメモリの使用量ではなく、クラスタに割り当てられているリソースに基づいていることもわかりました。それでは、メモリリソースが余っているクラスタ上に、「Resource Requests」の宣言なしにメモリをたくさん使う野良Podががんがんデプロイされたらどうなるでしょうか？
まず実験のため、次のようなメモリを1.0GBつかうDockerイメージを作ります。これをビルドしてmem-stressという名前のDockerイメージを作ります。
FROM ubuntu:latest RUN apt-get -y update && apt-get -y upgrade RUN apt-get -y install stress # 1つのstressプロセスが起動し、プロセスあたり1GBのメモリの負荷をかける CMD ["stress", "-m","1", "--vm-bytes" ,"1G","--vm-hang","0","-q"]
これをDocker HubやAzure Container Registryなどのレジストリで公開します。
次にこのDockerイメージを動かすPodを起動するReplicaSetのマニュフェスト(mem-stress.yaml)を作ります。この例では上記のDockerfileをビルドした「image: asashiho/mem-stress:latest」から生成するコンテナが1つ含まれたPodをテンプレートで定義し、そのPodを2つ動かすため「replicas: 5」と定義しています。クラスタには理論上各Nodeに3.5GBずつメモリがありますので、ざっくり5つくらいの野良Podを起動してみます。
このマニュフェストのポイントは、上のNginxのPodと異なりメモリに対するリソース要求(Resource Request)を指定していないことです。 このコンテナを作った張本人である私はアプリがメモリを1.0G使うことを知っていますが、Kubernetes はどれだけリソースを使うコンテナが入ったPodなのか一切知らないのです。
apiVersion: apps/v1 kind: ReplicaSet metadata: name: mem-exp spec: replicas: 5 selector: matchLabels: app: mem-stress-temp template: metadata: labels: app: mem-stress-temp spec: containers: - name: pod-sample image: asashiho/mem-stress:latest
次のコマンドを実行すると、新しく1Gのメモリを使うPodが5つ動く、、、、、はずです
$ kubectl create -f mem-stress.yaml replicaset.apps "mem-exp" created
なるほど。
「mem-exp-xxx」のPodは4つしか起動せず、うちいずれかの1つはCrashLoopBackOff―Errorで再起動を繰り返しています。
$ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE mem-exp-6dcgh 0/1 CrashLoopBackOff 2 1m 10.244.3.188 aks-nodepool1-12354740-1 mem-exp-dnwjk 1/1 Running 1 1m 10.244.3.186 aks-nodepool1-12354740-1 mem-exp-grxvz 1/1 Running 0 1m 10.244.2.155 aks-nodepool1-12354740-2 mem-exp-v5j29 1/1 Running 0 1m 10.244.2.154 aks-nodepool1-12354740-2 mem-exp-x9gxl 1/1 Running 2 1m 10.244.3.187 aks-nodepool1-12354740-1 reqest-exp-9kztw 1/1 Running 0 26m 10.244.2.153 aks-nodepool1-12354740-2 reqest-exp-b4t8h 1/1 Running 0 26m 10.244.3.184 aks-nodepool1-12354740-1 reqest-exp-fgrpn 0/1 Pending 0 13m <none> <none> reqest-exp-wzg7t 1/1 Running 0 18m 10.244.3.185 aks-nodepool1-12354740-1
絵にかくと次の感じです。
Podのログを確認するとエラーが出ているのが分かります。
$ kubectl logs mem-exp-6dcgh stress: FAIL: [1] (415) <-- worker 5 got signal 9 stress: FAIL: [1] (421) kill error: No such process stress: FAIL: [1] (451) failed run completed in 39s
システム全体のメモリ使用量はきちんと上がっています。
$ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% aks-nodepool1-12354740-1 33m 3% 2275Mi 68% aks-nodepool1-12354740-2 127m 12% 2573Mi 77%
これを、40分ほど放置します。その間に夕飯のしたくを。
$ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE mem-exp-6dcgh 0/1 CrashLoopBackOff 11 44m 10.244.3.188 aks-nodepool1-12354740-1 mem-exp-dnwjk 1/1 Running 6 44m 10.244.3.186 aks-nodepool1-12354740-1 mem-exp-grxvz 1/1 Running 0 44m 10.244.2.155 aks-nodepool1-12354740-2 mem-exp-v5j29 1/1 Running 0 44m 10.244.2.154 aks-nodepool1-12354740-2 mem-exp-x9gxl 1/1 Running 6 44m 10.244.3.187 aks-nodepool1-12354740-1 reqest-exp-9kztw 1/1 Running 0 1h 10.244.2.153 aks-nodepool1-12354740-2 reqest-exp-b4t8h 1/1 Running 0 1h 10.244.3.184 aks-nodepool1-12354740-1 reqest-exp-fgrpn 0/1 Pending 0 56m <none> <none> reqest-exp-wzg7t 1/1 Running 0 1h 10.244.3.185 aks-nodepool1-12354740-1
何が起こっているか、よーく見てみます。
1．Node1にスケジューリングされた野良Pod3つ
「mem-exp-6dcgh」と「mem-exp-dnwjk」と「mem-exp-x9gxl」はPodを稼働させたくても実際のメモリが足りないため、うち1つのいずれかが再起動を繰り返し「CrashLoopBackOff」のステータスになっています。
2．Node2にスケジューリングされた野良Pod2つ
「mem-exp-grxvz」と「mem-exp-v5j29」は再起動されることもなく順調に稼働しています。
3.マニュフェストでメモリの使用量をあらかじめ宣言したPod4つ
「reqest-exp-9kztw」は再起動されることなく3つが稼働中、そして空き容量待ち「reqest-exp-fgrpn」はPenddingでお行儀よく待っていること分かります。
なるほど！
どのようなしくみでPodがスケジューリングされたのか
KubernetesのResource Requestsでメモリを記述しないと、「Podがいつメモリ不足で終了されても構わない」という意味になります。なにがそうさせているかというと、、、、、
Pod QoSについて
KubernetesはPodに対して3つのQuality of Service (QoS)クラスを提供しています。このQoSは、今回検証したResource Requestsとリソースの上限を決めるResource Limitsの2つから次の条件でclassが決まります。
BestEffort
pod内のどのコンテナにもResource RequestsとResource Limitsが設定されていない時に設定される
Burstable
BestEffortもGuaranteedも設定されていないときに設定される
Guaranteed
CPUとメモリの両方に、Resouce RequestsとResource Limitsがセットされていること／Pod内のそれぞれのコンテナにセットされていること／Resouce RequestsとResource Limitsの値がそれぞれ同じであること、で設定される
このQoSの確認は、kubectl describeでできます。例えば「mem-exp-96vdn」のQoSを確認するときは次のコマンドになります。
$ kubectl describe pod mem-exp-96vdn |grep QoS
QoS Class: BestEffort
ちなみにpod内に複数のコンテナが存在する場合はまず各コンテナに上記のルールに従ってQoSを割り当てます。全てのコンテナがBestEffortならPodのQoSはBestEffortとなり、全てのコンテナがGuaranteedならPodのQoSはGuaranteedになるとのことです。そして、いずれの条件にも当てはまらない場合BestEffortになるとのことです。
今回の検証では、1.5GのResouce Requestsを指定したPodのQoSは「Burstable」、なにも指定しない野良Podは「BestEffort」が設定されていました。
Nodeのメモリ上限に達した場合、どういった判断でkillされるか
Kubernetesクラスタは魔法の箱ではないので、実際のメモリを超えるアプリは実行できません。今回の検証のNode1でなにがおきていたかというと。。。
Kubernetesでは、QoSに従ってどのPodのコンテナがkillされるか決まります。最も優先度が低く最初にkillされるのはBestEffort、つぎにはBurstable、最後にGuaranteedがkillされます。このGuaranteedはsystem processがメモリを必要とした場合のみkillされます。
もし同じQoSクラスだった場合、OutOfMemory (OOM) scoreのよってどのプロセスをkillするかを比較して決めているようです。決して、適当にkillしているわけではなく、Kubernetesはちゃんと忖度しながらkillしています。
今回の検証では、メモリが足りていないNode0上で、優先度の低い野良Podがkillされ、再起動されていました。この再起動のルールも、実はとても興味深い処理方式で動いています。こちらは後日別ブログで。
まとめ
Kubernetesでは、アプリケーション(コンテナ)が使うメモリに制限をかけると、クラスタ上の理論的なリソースが配分されてPodがスケジューリングされることがわかりました。また、Podの優先度が高くなり、クラスタの実際の使用メモリが多くなったときも、killされる可能性が低くなることが分かりました。
検証していませんが、ServiveやIngressでサービスディスカバリーを定義しておけば、今回のケースではいずれかのPodは動いているはずですので、クラスタ外部からのアクセスをみてみると、サービスが正しく動作している状態を維持できているはずです。
すごい。
なお、今回は設定しませんでしたがメモリにRequest Limitsを与えたときの動きや、CPUに関しても後日ひまを見つけて検証してまとめてみたいと思います。
というわけで、クラウドのKubernetesマネージドサービスを使うと、クラスタそのものの構築やMasterのメンテはお任せできますので、分散基盤のめんどうがみられるレベルのインフラエンジニアがいなくても、快適なデプロイ環境を作れますが、一方、、、知識としてのインフラ技術は、ある程度勉強しておかないと、障害時に中でなにがおこっているのか、だけでなく適切な基盤方式設計ができない、ということにもなります。難しいですが勉強だいじ。
おわり
