ブログ

Kubernetes pod evictedとスケジューリングの問題を理解する

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2020年1月23日にSysdigのCarlos Arillaが投稿したブログ(https://sysdig.com/blog/kubernetes-pod-evicted/)を元に日本語に翻訳・再構成した内容となっております。

通常、ポッドのevictedとスケジューリングの問題は、計画の不足が原因で発生するKubernetesのリミットとリクエストの副作用です。

初心者は、リミットはオプションであり、実行するものの障害に過ぎないと考える傾向があります。リミットを設定できないのに、なぜリミットを設定する必要があるのですか?最終的にはすべてのCPUが必要になる場合があります。

この考え方では、Kubernetesは今のような状況になれなかったでしょう。幸いなことに、Kubernetes開発者はこれを念頭に置いており、クォータメカニズムはリソースの誤用を避けるように設計されています。

アプリケーションのポッドを作成するときに、内部のすべてのコンテナのCPUとメモリのリクエストとリミットを設定できます。

これらの値を適切に設定することは、アプリリソースの管理方法をKubernetesに指示する方法です。 Kubernetesは、すべてのポッドにそのリミットとリクエストに基づいてスコアを付与し、公正使用規則に準拠していないポッドをクラスターからキックする準備ができています。

リクエストの設定とは、コンテナが通常の操作で実行する必要があるリソースの数を宣言することです。

リミットを設定すると、使用できるメモリまたはCPUの量が宣言されます。

リクエストとリミットに応じたKubernetes QoS

Kubernetesのコンテナには2つの異なるクォータがあります。

        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 768Mi 
  • リクエスト:この値はスケジューリングに使用されます。 コンテナを実行するのに必要な最小限のリソースです。 注意してください、リクエストはこれらが常にコンテナ専用のリソースであることを意味するものではありません。
  • リミット:これは、ノードがコンテナに使用を許可するこのリソースの最大量です。

この記事で説明したように、どちらもCPUとメモリでさまざまな意味で使用できます。

クォータ設定に応じて3種類のポッドがあります。

Guaranteed:すべてのコンテナにリクエストとリミットがあるポッドで、同じでなければなりません

Burstable:コンテナの1つに少なくとも1つのCPUまたはメモリリクエストがある「保証されていない」ポッド

Best effort:リクエストやリミットのないポッド

この投稿で見るように、ポッドのQoSタイプは、リソースを割り当てて再利用するときに重要です。

リクエスト値の設定が不十分なために発生するスケジューリングの問題

クラスターポッドの割り当ては、リクエスト(CPUとメモリ)に基づいています。 ポッドがノード内の使用可能なCPUまたはメモリよりも大きい(リクエストを要求する)場合、ポッドはそのノードで実行できません。 ポッドを実行するのに十分なリソースがクラスターノードにない場合、ポッドは十分なリソースがあるまでスケジュールがペンディングのままになります。

あまりにも多くのリソースを要求すると、ポッドのスケジュール設定が難しくなります。 さらに、リクエストがリソースの通常の使用よりも多い場合、リクエストされ使用されていないリソースを他のポッドに割り当てることはできず、クラスターの運用容量が減少します。 クラスター管理者はおそらくあなたに知らせてくれるでしょう。

ポッドの割り当てを待機しており、スケジューラがポッドを実行するのに十分なリソースを持つノードを見つけられない場合、十分なリソースがあるまで「ペンディング」フェーズのままになります。

NAME       READY   STATUS    RESTARTS   AGE
frontend   0/2     Pending   0          10s 

「kubectl describe pod」コマンドは、問題に関する情報を提供します。

Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  44s (x2 over 44s)  default-scheduler  0/4 nodes are available: 4 Insufficient memory. 

ポッドのデプロイメントに必要なリソースが、見た目と異なる場合があることに注意してください。 割り当てに使用されるポッドの有効なリクエストは、次の2つの値のうち最も高い値です。

  • ポッド内のコンテナのリクエストの合計
  • 初期化コンテナのリクエスト

たとえば、この定義のポッドがある場合:

apiVersion: v1
kind: Pod
...
  containers:
  - name: myapp-container
    image: busybox:1.28
    resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 768Mi
  - name: myapp2-container
    image: busybox:1.28
    resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 768Mi
...
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'sleep 3']
    resources:
          requests:
            cpu: 300m
            memory: 750Mi 

アプリケーションを実行するコンテナの合計は、200ミリコアのCPUと256 MBのリクエストです。 ただし、ポッドのスケジュールに使用される有効なポッドリクエスト、および占有としてマークされたリソースの量は、initコンテナごとに要求される300mおよび750MBになります。

クラスター内の割り当て可能なリソースの明確な視点を持つことにより、クラスター管理者は現在および予想されるワークロードに応じてニーズをより適切に計画できます。リクエストされたリソースを実際に使用しているポッドを正確に把握することは、ノードごとのクラスター占有率とアプリケーション密度を最大化するための貴重なツールになります。

v01.png

Sysdig MonitorのダッシュボードにKubernetes → Resource usage → Kubernetes cluster and node capacityにメトリクスがあります。

Pod evicted の問題

Kubernetesクラスター内のノードでメモリまたはディスクが不足すると、圧力がかかっていることを示すフラグがアクティブになります。これにより、ノード内の新しい割り当てがブロックされ、evictionプロセスが開始されます。

ヒント:この情報は、Sysdigモニターダッシュボードで見つけることができます。

v02.png

その瞬間、kubeletはリソースの再利用を開始し、リソースの使用量が再びevictionのしきい値を下回るまで、コンテナを強制終了し、ポッドをフェイルとして宣言します。

まず、kubeletは、無効なポッドとそのコンテナを削除してから、未使用のイメージを削除することにより、ノードリソース、特にディスクを解放しようとします。これだけでは不十分な場合、kubeletは次の順序でエンドユーザーポッドの削除を開始します。

  • ベストエフォート
  • 不足した状態リソースのリクエストよりも多くのリソースを使用するバースト可能なポッド
  • 不足した状態のリソースのリクエストよりも少ないリソースを使用するバースト可能なポッド

ポッドの1つがメモリ使用によってevictedされると、次のようなメッセージが表示されます。

NAME       READY   STATUS    RESTARTS   AGE
frontend   0/2     Evicted   0          10s
Events:
  Type     Reason               Age    From                                                  Message
  ----     ------               ----   ----                                                  -------
  Normal   Scheduled            12m    default-scheduler                                     Successfully assigned test/frontend to gke-lab-kube-gke-default-pool-02126501-qcbb
  Normal   Pulling              12m    kubelet, gke-lab-kube-gke-default-pool-02126501-qcbb  pulling image "nginx"
  Normal   Pulled               12m    kubelet, gke-lab-kube-gke-default-pool-02126501-qcbb  Successfully pulled image "nginx"
  Normal   Created              12m    kubelet, gke-lab-kube-gke-default-pool-02126501-qcbb  Created container
  Normal   Started              12m    kubelet, gke-lab-kube-gke-default-pool-02126501-qcbb  Started container
  Warning  Evicted              4m8s   kubelet, gke-lab-kube-gke-default-pool-02126501-qcbb  The node was low on resource: memory. Container db was using 1557408Ki, which exceeds its request of 200Mi.
  Warning  ExceededGracePeriod  3m58s  kubelet, gke-lab-kube-gke-default-pool-02126501-qcbb  Container runtime did not kill the pod within specified grace period.
  Normal   Killing              3m27s  kubelet, gke-lab-kube-gke-default-pool-02126501-qcbb  Killing container with id docker://db:Need to kill Pod 

evictionの場合、保証されたポッドは安全であるはずです。 ポッドでリクエストとリミットを設定していない場合、これはそうする非常に良い理由です。 これらの値を適切に設定すると、予期しない停止から保護できます。

これには特別な例外があります。一部のシステムサービスが予約されている量よりも多くのリソースを必要とし、保証されたポッドしかない場合、kubeletは圧力がなくなるまでリソースの使用順にそれらのポッドを排除します。

まとめ

クラスター内のさまざまなアプリケーションを共存させるには、リクエストとリミットを適切に構成することが重要です。これらのリミットを理解することで、コールローテーションをより良くすることができます。

このことから学ぶべき教訓は次のとおりです。

  • 重要なポッドの設定値を保護して、保証済みとして分類します。
  • バースト可能なポッドは、ほとんどのタスクに適しています。
  • ポッドのリミットとリクエストを合理的に設定してください。これにより、クラスターの容量を調整し、ポッドによって引き起こされる問題を改善できます。
  • ベストエフォートポッドを避け、時間の制約がないか、フォールトトレラントなもののためにこれを保持するようにします。

sysdigモニターのような優れたモニタリングシステムは、ポッドの削除およびペンディングのポッドを確実に回避するのに役立ちます。試されたい方は、https://sysdig.jp/ 内の無料お試しをクリックすると14日間のトライアルライセンスが発行されます。

Sysdig Secureも試されたい方は、http://www.scsk.jp/sp/sysdig/index.htmlからお問い合わせいただければと存じます。

Sysdigに関するお問い合わせはこちらから

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top