Kubernetesポッドの中断とは何ですか？

Kubernetesポッドは、Kubernetesプラットフォームで展開可能な最小のユニットです。 各ポッドは、システム内で実行中の単一のプロセスに信号を送り、Kubernetes内のノードまたはワーカーマシンから機能します。これは、仮想形式または物理形式をとることがあります。 

時折、Kubernetesポッドの中断は、自発的または非自発的な原因のいずれかから、システム内で発生する可能性があります。 Kubernetesポッドの中断は、可用性の高いアプリケーションで発生する可能性が高く、自動クラスターアクションを実行するクラスター管理者にとって懸念事項であることがわかります。 

基本的に、ポッドは、ユーザーまたはコントローラーがポッドを削除するか、システムプロセスに障害がない限り、Kubernetesに残ります。 システム管理者は、Kubernetesポッド中断バジェット（PDB）を適用して、同時ポッド中断の許容量/バッファーを作成することにより、システムが中断されないようにすることができます。 

内容

• Kubernetes Pod Disruptionとは何ですか？
• ポッドディスラプションバジェット（PDB）とは何ですか？
• 自発的および非自発的混乱の違いは何ですか？
• 中断予算を指定する方法
• ポッドの中断ステータスの評価
• Pod Disruption Budget（PDB）を使用して停止を回避する方法
• KubernetesPDBのその他の役立つ詳細
• まとめ

Kubernetes Pod Disruptionとは何ですか？

Kubernetesシステムのすべてのポッドは、保留中、実行中、成功、失敗などのフェーズ全体で定義されたライフサイクルに従います。 Kubernetes API内で、各ポッドは一連の条件によって決定される仕様とアクティブステータスを備えています。 Kubernetesを使用すると、ユーザーはポッドをノードにXNUMX回だけスケジュールでき、そこから停止または終了するまで実行されます。 

一部のシステムシナリオでは、KubernetesノードでRAMまたはディスク容量が不足する場合があります。これにより、システム（つまり、コントローラー）がポッド（つまり、ライフサイクル）を中断して、ノードの実行を維持します。 クラスター管理者/コントローラーは、ポッドを意図的に中断したり（任意）、ソフトウェアまたはハードウェアのエラーによって中断が発生したりする場合があります。 

ポッドディスラプションバジェット（PDB）とは何ですか？

PDBは、ReplicaSet、StatefulSet、ReplicationController、Deploymentなどのさまざまなコントローラーで管理されるKubernetesポッドの中断に対するソリューションです。 PDBは、特定の期間にシャットダウンするポッドが多すぎるため、サーバーのダウンタイムや停止を防ぎます。 

実際には、PDBは、損失を被ることなくSLA（サービスレベルアグリーメント）をサポートするために必要な最小限のポッドを維持します。 Kubernetesユーザーは、自発的な排除中にクラスターが安定して機能し続けるために必要な利用可能なレプリカの最小数を定義するプラットフォームオブジェクトとしてPDBを定義することもできます。 

PDBは、スケールダウン操作中にノードをドレインする方法を決定するためにclusterautoscalerによって使用されます。 ノードのアップグレード中のポッド排除のペースを制御します。 たとえば、XNUMXつのポッドとXNUMXつのminAvailable設定を持つサービスの場合、ReplicaSetコントローラーはXNUMXつのポッドを削除し、新しいポッドに置き換えられるのを待ってから別のポッドを削除します。

NGINXを実行しているサービスのポッド中断バジェットを設定するには、次のコマンドを使用します。

kubectl create poddisruptionbudget my-pdb –selector = app = nginx –min-available = 80％

上記の例では、PDBはnginxポッドの80％が常に正常である必要があるという要件を設定しています。 ユーザーがポッドの削除を要求すると、クラスターはPDB要件を満たしている場合にのみグレースフルプロセスを有効にします。 

PDBを開始する前に、ユーザーはいくつかの考慮事項にアクセスする必要があります。 

まず、ユーザーはPDBによって保護されるアプリケーションの種類を確立する必要があります。 プロセスは、アプリケーションがポッドの中断にどのように応答するかを調べることから始まります。 次に、ユーザーはPDB定義のYAMLファイルを作成し、それらのファイルからPDBオブジェクトを作成する必要があります。 

ただし、ユーザーは、PDBが意図的なadmin / userコマンドの下での自発的な中断にのみ適用されることに注意する必要があります。 したがって、PDBは、意図せずに中断されたアプリケーション/ポッドのフリートでは機能しません。 

ユーザーが規定値よりも多くのポッドを自発的に中断しようとすると、PDB値の違反によるポッドの削除を防ぐエラーコード429メッセージが表示されます。 

自発的および非自発的混乱の違いは何ですか？

Kubernetes Pod Disruptionsには、主にXNUMXつのタイプがあります。コントローラーとユーザーの意図的なアクションによって引き起こされる自発的な中断と、ハードウェアまたはソフトウェアの障害による避けられない非自発的な中断です。 

不本意な中断の一般的な例には、物理​​マシンのハードウェア障害、ノードネットワークパーティションによるノードの消失、カーネルパニックなどがあります。 ポッドの自発的な中断の例には、ノードをドレインしてクラスターをスケーリングしたり、システムの更新やメンテナンスに合わせてノードからポッドを削除したりするなど、クラスター管理者のアクションが含まれます。 

PDBは、ユーザーと管理者が特定のクラスターアクションのためにポッドを一時的に削除する自発的なポッドの中断/削除にのみ適用されることを覚えておくことが重要です。 ユーザーは、アプリケーションを複製してゾーン全体に分散させるなど、ポッドの不本意な中断に対して他のソリューションを適用できます。 

ポッドの中断は、ノードプレッシャーの排除という形で発生する可能性があります。この場合、コントローラーはポッドを積極的に削除してノード上のリソースを再利用し、システムの枯渇を防ぎます。 このような場合、kubeletはPDBを無視します。 あるいは、APIによって開始されるエビクションは、ユーザーの事前構成されたPDBとterminalgraceperiodseconds（つまり、ポッドの正常な削除に許容される時間）を尊重します。 

デフォルトの時間枠が30秒であるポッドの正常なシャットダウンは、Kubernetesクラスター管理に不可欠であり、潜在的なワークロードの中断を防ぎ、適切なクリーンアップ手順を容易にします。 ビジネス/組織の観点から、ポッドを適切に終了することで、エンドユーザーエクスペリエンスへの影響を最小限に抑えながら、システムのリカバリを高速化できます。 

したがって、PDBは、利用できないすべてのインスタンスに対する絶対確実なソリューションではなく、APIによって開始されるエビクション専用のオブジェクトです。 

中断予算を指定する方法

PDBは、.spec.selector、.spec.minAvailable、および.spec.maxAvailableのXNUMXつのフィールドで構成されます。 基本的に、.spec.selectorは、システム内で選択されたポッドのセットのラベルとして機能します。  

PDBを配置すると、ユーザー/管理者はレプリカの最小数または最大数を設定し、.spec.minAvailableフィールドと.spec.maxAvailableフィールドを使用してポッドの中断を制御できます。 .spec.minAvailableは、常に必要なアクティブなポッドの数を決定し、.spec.maxAvailableは、許可される中断されたポッドの最大数を示します。 

クラスター管理者/コントローラーは、各PDBの.spec.maxAvailableフィールドと.spec.minAvailableフィールドから0つだけを選択できます。 .spec.maxAvailableまたは100％.spec.minAvailableにXNUMXの値を設定すると、ユーザーはポッドの削除を禁止します。 

さらに、KubernetesPDBを指定する前に考慮すべきいくつかの要素があります。 ユーザー/管理者は、v1.21以上で実行されているKubernetesシステムを持っている必要があります。 そうでない場合は、必要な互換性を満たすためにプログラムをアップグレードする必要があります。 

さらに、PDBを適用するユーザーは、クォーラムベースのアプリケーションなど、高可用性を必要とするKubernetesクラスターで実行されているアプリケーションの所有者である必要があります。 また、サービスプロバイダーまたはクラスター所有者（ユーザーが許可を必要とする場合）が開始する前に予算の使用に同意することを確認することも不可欠です。 

アプリケーションの反応を理解する 

さまざまなアプリケーションタイプが、ポッドの中断プロセスに対してさまざまな応答を表示します。 したがって、ユーザーは、処理するKubernetesアプリケーションのタイプに基づいてPDBの実装を常に検討する必要があります。 アプリケーションの反応を評価することで、ユーザーはPDB機能を最適化し、一部のシナリオで余分なプロセスを回避できます。 

たとえば、ユーザーがジョブを完了する必要がある再起動可能なジョブでは、それぞれのジョブコントローラーがPDBなしで代替ポッドを作成します。 同様に、権限を必要とする単一インスタンスのステートフルアプリケーションの場合、ユーザーはPDBを適用せずにダウンタイムを許容するか、maxUnavailable = 0でPDBを設定し、ダウンタイム/更新の準備をして、PDBを削除することを選択できます。これは、ユーザーが必要に応じて後で再作成できるためです。 

丸めロジック 

ユーザーは、PDBの必要な値を整数またはパーセンテージ形式で表すことができます。 具体的には、minAvailableの場合は50つで、常に最低XNUMXつのアクティブなポッドが必要であると述べています。XNUMX％minAvailableは、ポッド全体の少なくとも半分が常にアクティブである必要があることを意味します。 

Kubernetes はポッドの値を切り上げます. たとえば、合計 50 個のポッドと XNUMX% の minAvailable を持つクラスター シナリオでは、PDB は少なくとも XNUMX 個のポッドが常にオンラインであることを保証します。 

ポッドの中断ステータスの評価 

Kubernetesユーザーは、システムパフォーマンスをよりよく理解し、システムをオンラインに保つために、PDBステータスを定期的に確認する必要があります。 いくつかの重要な要素には、現在の正常なポッドの数、必要な正常なポッドの最小数（つまり、.spec.maxAvailable値）、および中断の許容可能な理由（たとえば、SufficientPods –クラスターに最小数の正常なポッドがある場合）が含まれます。中断を続行します）。 

Poddisruption Budget（PDB）を使用して停止を回避する方法

PDBを作成するための最初のステップは、ターゲットポッドに一致するPoddisruptionbudgetリソースを作成することです。 これらのリソースは、Kubernetesシステムをポッドドレインリクエストのタイミングに向けて駆動し、無停止での排除を実現するのに役立ちます。  

排出プロセスの開始時にPDBを配置すると、ユーザーはセレクターと関連するすべてのポッドの状態を判別できます。 そうすることで、ユーザーは、悪影響を回避するためにアクティブなポッドの最小数を維持しながら、ノードを効果的に排出できます（つまり、システムの更新中）。 そのため、PDBはシステムの停止を削減または排除して、クラスターのパフォーマンスを維持できます。  

KubernetesPDBのその他の役立つ詳細

Kubernetes 1.21は、PDBAPIを含むプラットフォームに多数の更新と変更をもたらします。 特に、空のセレクターは、デフォルトでゼロポッドと一致していましたが、最近のパッチでは、特定の名前空間内のすべてのポッドと一致します。 

時々、ユーザーはノードのアップグレードまたはクラスターのアクション中にさまざまなPDB構成の複雑さを経験する可能性があります。 したがって、迅速な対応と最小限のダウンタイムを促進するために、いくつかの一般的なシナリオを特定することが重要です。 

PDBの潜在的な問題は次のとおりです。

水平ポッドオートスケーラーを使用する場合の注意

水平ポッドオートスケーラーを使用すると、ユーザーは入力された指標に基づいてシステム負荷に応じてKubernetesリソースをスケーリングできます。 ただし、PDBの構成が不十分な場合、値の不一致が発生する可能性があります。これにより、オートスケーラーの値のシフトを考慮せずに、既存のポッドが計算されます。 

PDBでポッドスケーラーを使用するベストプラクティスの場合、ユーザーは、スケールダウンをブロックする可能性のあるアプリケーションまたはシステムポッドのPDBを定義する必要があります。 あるいは、ユーザーは、サーバーアクティビティの急増中に追加の要求を処理するために必要なブーストをシステムに提供する一時停止ポッドを使用することもできます。 

さらに、一部のユーザーは、クラスターがPDBを実行していることに気付かない場合があります（OperatorなどのKubernetesソフトウェア拡張機能にパッケージ化されている可能性があるため）。 したがって、ユーザーは、PDB構成と、ノードのアップグレードなどのプラットフォームアクションから発生する可能性のある複雑さや問題に細心の注意を払う必要があります。 

単一のレプリカを持つPDB

単一のポッドを使用したデプロイメントでPDBを適用するユーザーは、kubectlドレインがスタックしたままになります。 このようなシナリオでは、ユーザーはポッドのドレインと更新を手動で管理する必要があります。 したがって、ユーザーは、アクセシビリティの高いKubernetesシステムに必要な、複数のレプリカを使用したデプロイで常にPDBを実行する必要があります。   

複数のPDBによる無期限のデッドロック

複数のPDBを使用すると、クラスター内で混乱（つまり、セレクターの重複）が発生し、ドレインプロセスが無期限にハングする可能性があります。 したがって、ベストプラクティスとして、ユーザーは、ポッドの各セットにリンクされた意味のあるセレクター名と、コントローラーセレクターに適合するmatchLabelを適用する必要があります。 

まとめ

Kubernetesは、PDBなどの非常に直感的な機能により、世界中で最も広く使用されているワークロード管理プラットフォームのXNUMXつです。 PDBを使用すると、ユーザーはAPI排除プロセスをより細かく制御できるため、ワークロードの中断や停止のリスクを最小限に抑えることができます。 ただし、ユーザーはPDBに制限があり、特定のKubernetesシナリオに従ってのみ適用する必要があることに注意する必要があります。 

PDBは次の用途に適しています。

• 自発的なポッドの中断（つまり、定期的なメンテナンスの実行などのクラスター管理者のアクション）。
• アクセシビリティの高い展開。

PDBは次の場合には適していません。

• 不本意なポッドの中断（つまり、大規模なハードウェアまたはソフトウェアのエラー）。
• ノード圧力の排除。
• 単一のレプリカを含む展開。

アプリケーションごとにPDBを作成することにより、ユーザーは、ポッドの自発的な中断（ソフトウェア拡張など）が頻繁に発生する場合でも、可用性の高いアプリケーションを維持できます。 

Kubernetesスケジューラは、ユーザーが利用可能なリソースに基づいてポッドをノードに割り当てるのに役立ちますが、一部のポッドが実行され続けている間にシステムの再スケジュール中に余分なノードを排出または削除する必要がある場合、複雑さが生じる可能性があります（潜在的なダウンタイムにつながります）。 PDBリソースを配置すると、ユーザーはk8アプリケーションを機能させて、最小限の遅延で着信要求を受け入れることができます。