Kubernetes クラスターの健全性を確認する 5 つの方法

Kubernetes は非常にスマートなテクノロジーですが、適切に使用しないと逆効果になる可能性があります。ほとんどのスマート テクノロジーと同様に、そのスマートさはそれを使用する人のスマートさによって決まります。成功する Kubernetes チームを構築するには、Kubernetes の健全性を理解することが重要です。ここでは、エンジニアがクラスターの潜在的な健康リスクをより適切に特定できる 5 つの方法を紹介します。

幸いなことに、Kubernetes クラスターからログ、さまざまなメトリック データ、イベント、セキュリティの脅威を収集し、クラスターの健全性を監視するために使用できる、すぐに利用できるテクノロジがいくつかあります。これらのコレクターは、Kubernetes クラスターのさまざまな部分からデータを収集し、そのデータを集約して、リソースの使用率、構成ミス、その他の問題に関する視覚的な高レベルビューとリアルタイムの分析情報を生成します。

すべてのポッドのCPU使用量の上限と下限を設定する

Kubernetes クラスターでは、Pod のスケジューリング メカニズムは、リクエストと制限という 2 つのパラメーターに依存します。 CPU とメモリのリクエストと制限を設定できます。 CPU の場合、単位はミリコアで、1000m が 1 つの CPU コアに相当します。 Requests はコンテナに必要な CPU とメモリの最小量であり、limits はコンテナが実際に使用できる上限です。

すべてのポッドに対して CPU リクエストを設定してください。ベストプラクティスとしては、これを 1 つの CPU コア以下に設定し、さらに計算能力が必要な場合は追加の Pod レプリカを追加することです。 CPU 要求が 2000m など高すぎるが、使用可能な CPU コアが 1 つしかない場合、この Pod は Kubernetes クラスターにスケジュールされないことに注意することが重要です。ポイント 5 では、スケジュールされていない Pod を確認する方法を説明します。

すべてのポッドに CPU 制限を設定してください。前述のように、このパラメータは Pod の CPU 使用量に上限を設定するため、Kubernetes は Pod が制限で定義された量を超えて CPU を使用することを許可しません。とはいえ、CPU は圧縮可能なリソースと見なされるため、より寛容です。 Pod が CPU 制限に達した場合、Pod は終了されずに調整されるため、パフォーマンスが低下する可能性があります。

すべてのポッドのメモリ使用量の上限と下限を設定する

すべてのポッドに対してメモリ要求を必ず設定してください。メモリ要求は、コンテナに最低限必要と思われるメモリの量です。 CPU と同様に、Pod のメモリ要求がクラスターが提供できるメモリよりも大きい場合、Kubernetes は Pod を Kubernetes クラスターにスケジュールしません。

すべての Pod にメモリ制限を設定してください。メモリ制限は、Pod に許可されるメモリの上限です。 CPU とは異なり、メモリは圧縮できず、調整することもできません。コンテナがメモリ制限を超えると、コンテナは終了します。

監査リソースの割り当て

Kubernetes のリソースが不足または過剰になっていないか確認します。 Kubernetes クラスターに空き CPU とメモリが残っている場合、クラスターは消費状態にあり、消費は増加し続ける可能性があります。一方、CPU とメモリの使用率が 100% に近い場合、クラスターを水平方向に拡張する必要がある場合や、大量のリクエストが到着した場合に、クラスターで問題が発生する可能性があります。

ポッドの残り容量を確認します。 Kubernetes には、インジケーター データ「kube_node_status_allocatable」があります。これは、平均的な Pod リソース使用率を考慮して、ノードが収容できる Pod の数を Kubernetes が推定したものです。残りのポッド容量を合計すると、問題が発生することなくクラスターをどれだけ大きくできるかを大まかに見積もることができます。

合計 CPU 使用率、CPU 要求使用率、CPU 制限使用率を確認します。合計 CPU 使用率から、現在使用されている量がわかります。 CPU 要求の使用率のパーセンテージから、どれくらいの量を使用すべきかがわかります。 CPU 制限は、使用できる量をパーセンテージで制限するものです。

以下の例では、利用可能な計算能力の 2.5% のみを使用しています。余剰資源が多すぎます。比較すると、私たちが定義した CPU リクエストは 46% だったので、Pod が実際に使用した量よりもはるかに多くの量が必要であると考えました。私たちの見積りは十分に正確ではありませんでした。

最終的に、CPU 制限の合計は 37% になります。これは CPU 要求よりも低いため、構成ミスであり、CPU 制限を再確認する必要があります。

メモリ使用量のパーセンテージ、メモリ要求のパーセンテージ、メモリ制限のパーセンテージを確認します。 CPU の場合と同様に、残りのリソースが多すぎないかどうかを確認します。使用率はわずか 3.8% なので、確かにリソースが過剰であることがわかりますが、水平方向に安全に拡張できます。

ノード間のポッド分布を確認する

クラスター全体のポッドの分布を見ると、ほぼ均等に分布していることがわかります。一部のノードが完全に過負荷または過負荷になっている場合は、さらに調査する価値のある問題である可能性があります。

不均等な配布を引き起こす可能性のある要因は次のとおりです。

• ノード アフィニティは、Pod が特定のプロパティを持つノードを優先するようにする Pod 設定です。たとえば、Pod は GPU または SSD が接続されたノード上で実行する必要がある場合や、Pod に特定のセキュリティ分離またはポリシーを備えたノードが必要な場合があります。アフィニティ設定を確認すると、不均一な配布の原因を分析し、起こりうる問題を軽減するのに役立ちます。

汚点と容認、汚点は容認の反意語です。ポッドは、これらの「汚染された」ノードに割り当てられることを好みません。このアプローチは、特定のポッド用にノードを予約する場合、またはそのノード上のポッドが利用可能なリソースに完全にアクセスできることを確認する場合に使用できます。

制限とリクエスト、制限とリクエストの設定を表示します。これは Pod の不均等な分散の原因となることが多いため、このセクションの 3 つの部分で説明する価値があります。 Kubernetes スケジューラがポッドに必要なものに関する正しい情報を持っていない場合、スケジューラはポッドのスケジュールを適切に実行できません。

ポッドの状態が悪いかどうかを確認する

Kubernetes 環境では、Pod の状態は常に変化するため、終了するすべての Pod に注意を払いすぎると、徐々に時間と精神が消耗してしまいます。ただし、目的のクラスター状態が達成されていることを確認するには、次のリストに注意する価値があります。

• ノードの準備ができていません: ノードがこの状態で停止する理由はさまざまですが、通常はメモリまたはディスク容量が不足していることが原因です。
• スケジュールされていないポッド: ポッドが要求する CPU またはメモリの要求をスケジューラが満たすことができないため、ポッドは通常、スケジュールされていない状態になります。クラスターに十分な利用可能なリソースがあるかどうかを確認します。
• 作成に失敗したポッド: ポッドの作成に失敗しました。これは通常、ポッドの起動スクリプト内の一部の依存関係などのイメージが不足していることが原因です。この場合は、開始点に戻って、Pod のさまざまなパラメータ構成を繰り返し確認してください。

コンテナの再起動: コンテナの再起動が数回発生することは心配する必要はありませんが、頻繁に発生する場合は、Pod が OOMKill (メモリ不足) 状態にある可能性があります。メモリ不足は、Kubernetes クラスターで最も一般的なエラーの 1 つであり、イメージの問題、ダウンストリームの依存関係の問題、またはさまざまな予期しないスロットリングやリクエストの問題によって発生する可能性があります。

これらのクラスターの健全性に関するベスト プラクティスにより、Kubernetes クラスターの予期しない動作を制限し、クラスターの拡張時に問題が発生しないようにすることができます。また、「Kubernetes クラスターは正常ですか?」などの漠然とした質問に答えるのに役立つ優れた出発点も提供します。これらのチェックポイントがすべて緑色であれば、クラスターはおそらく正常であり、安心できます。