コルドンと排水: Kubernetesノードのメンテナンス準備方法

Kubernetesノードは定期的なメンテナンスが必要です。ノードのカーネルを更新したり、クラウドアカウントでコンピュートリソースのサイズを変更したり、セルフホステッドインストールで物理ハードウェアコンポーネントを交換したりすることがあります。

Kubernetesのコルドンとドレインは、ノードのダウンタイムに安全に備えるために使用できる2つのメカニズムです。これにより、ターゲットノード上で実行されているワークロードを他のノードに再スケジュールすることができます。その後、ノードをシャットダウンしたり、クラスターから削除したりしても、サービスの可用性に影響を与えることなく実行できます。

ノードコルドンの適用

ノードをコルドンすると、そのノードはKubernetesスケジューラに対して利用不可としてマークされます。その後、クラスタに追加される新しいPodをホストすることができなくなります。

使用してください

kubectl cordon

指定されたノードの周りに封鎖を行うコマンド:

kubectl cordon node-1
node/node-1 cordoned

ノード上で既に実行中のポッドはコーダンの影響を受けません。それらは引き続きアクセス可能で、コーダンされたノードによってホストされます。

どのノードが現在コーディンされているかは、get nodesコマンドを使って確認できます:

kubectl get nodes
NAME STATUS ROLES AGE VERSION
node-1Ready,SchedulingDisabledcontrol-plane,master 26mv1.23.3

周囲が封鎖されたノードは、SchedulingDisabled ステータスで表示されます。

ノードを排出する

次のステップは、ノードから残っているポッドを排出することです。この手順では、ポッドが強制的に他のノードに再スケジュールされるために退去させられます。ポッドは、ターゲットノードから強制的に削除される前に、優雅に終了することが許可されています。

kubectl drain を実行して排出手続きを開始します。メンテナンスのために取り出すノードの名前を指定してください:

kubectl drain node-1
node/node-1 already cordoned
evicting pod kube-system/storage-provisioner
evicting pod default/nginx-7c658794b9-zszdd
evicting pod kube-system/coredns-64897985d-dp6lx
pod/storage-provisioner evicted
pod/nginx-7c658794b9-zszdd evicted
pod/coredns-64897985d-dp6lx evicted
node/node-1 evicted

drainプロシージャは、手動でコルドンを置いていない場合、最初にノードをコルドンします。それから、実行中のKubernetesワークロードを安全に再スケジュールして、クラスタ内の他のノードに移動させます。

ドレインが完了したら、ノードをシャットダウンまたは破壊できます。あなたはノードをクラスタに対する責任から解放しました。コルドンは、ドレインが完了して以来、新しいワークロードがスケジュールされていないことを保証します。

ポッドの猶予期間を無視する

Podのグレース期間が長い場合、ドレインが完了するまでに時間がかかることがあります。これは、ノードを緊急にオフラインにする必要があるときには理想的ではありません。--grace-period フラグを使用して、Podの終了グレース期間を上書きし、即時の退去を強制して下さい:

kubectl drain node-1 --grace-period 0

これは注意して使用する必要があります - 一部のワークロードは、クリーンアップの機会を与えられずに停止されると、うまく応答しない可能性があります。

排水エラーの解決

drainは、クラスターに存在するポッドの種類によってはエラーが発生することがあります。ここに、一般的な2つの問題とその解決策があります。

1. "ReplicationController、ReplicaSet、Job、またはStatefulSetによって管理されていないPodを削除できません"

このメッセージは、ノードがコントローラーに管理されていないポッドをホストしている場合に表示されます。これは、スタンドアロンオブジェクトとして作成されたポッドを指し、デプロイメントやレプリカセットのようなより高次のリソースの一部ではありません。

Kubernetesはこれらの「ベア」Podを自動的に再スケジュールできないため、これらを追い出すと利用できなくなります。排出を行う前にこれらのPodを手動で処理するか、--forceフラグを使用して削除を許可してください:

kubectl drain node-1 --force

2. "DaemonSetによって管理されるPodを削除できません"

デーモンセットの一部であるポッドは、退避作業に対して課題を呈します。DaemonSetコントローラーは、ノードのスケジューラブル状態を無視します。デーモンセットの一部であるポッドを削除すると、ノードをコルドンしていてもすぐに戻ってしまいます。そのため、排出操作はこの動作について警告するエラーで中止されます。

ダイモンセットを無視して、他のすべてを立ち退かせるために、--ignore-daemonsets フラグを追加することで、立ち退きを進めることができます。

kubectl drain node-1 --ignore-daemonsets

自分でDaemonSetを作成していなくても、このフラグを使用する必要があるかもしれません。kube-system名前空間内の内部コンポーネントがDaemonSetリソースを使用している可能性があります。

ポッド障害予算を使用してダウンタイムを最小限に抑える

ノードを排水することは、ワークロードが常にアクセス可能であることを保証するものではありません。他のノードはスケジューリングリクエストを処理し新しいコンテナを作成するための時間が必要です。

これは、短時間に複数のノードを draining している場合、特に影響を与える可能性があります。最初のノードを draining することで、そのポッドが第2のノードに再スケジュールされる可能性があり、その第2のノードも削除されることになります。

ポッドの中断予算は、この状況を回避するためのメカニズムです。これらはデプロイメント、レプリケーショントローラー、レプリカセット、ステートフルセットと一緒に使用できます。

Podの中断予算によって対象とされるオブジェクトは、特定の数のアクセス可能なPodが常に存在することが保証されています。Kubernetesは、利用可能なPodの数があまりにも低下する原因となるノードの排出をブロックします。

こちらは PodDisruptionBudget YAML オブジェクトの例です:

apiVersion: policy/v1


kind: PodDisruptionBudget

metadata:

 name: demo-pdb

spec:

 minAvailable: 4

 selector:

 matchLabels:

 app: my-app

このポリシーは、app=my-appラベルが付いたランニングポッドが少なくとも4つ存在することを要求します。3つのポッドしかスケジュールできないようなノードの排出は防止されます。

許可される混乱のレベルは、maxUnavailable または minAvailable フィールドのいずれかとして表現されます。これらのうちの1つだけが単一のポッド混乱予算オブジェクトに存在できます。それぞれは、絶対的なポッドの数または完全な可用性に対する割合を受け入れます:

• 利用可能な最小数: 4 - 利用可能なPodが少なくとも4つ必要です。
• maxUnavailable: 50% - Podの総数の半分までが利用できないことを許可します。

ポッド中断予算の上書き

ポッドの混乱予算は、ワークロードを保護するためのメカニズムです。ノードをすぐにシャットダウンしなければならない場合を除き、オーバーライドすべきではありません。drainコマンドの--disable-evictionフラグは、これを実現する方法を提供します。

kubectl drain node-1 --disable-eviction

これにより、通常のポッド退去プロセスを回避します。ポッドは直接削除され、適用された混乱予算は無視されます。

ノードを再起動する

メンテナンスが完了したら、ノードの電源を再投入してクラスターに再接続できます。その後、ノードをスケジュール可能として再びマークするために作成したコルドンを削除する必要があります:

kubectl uncordon node-1
node/node-1 uncordoned

Kubernetesは新しいワークロードをノードに割り当て始め、これをアクティブサービスに戻します。

要約

Kubernetesノードのメンテナンスは、既存のワークロードを排出し、コーダンを設定するまで試みるべきではありません。これらの対策は、使用中のノードをサービスする際の予期しないダウンタイムを回避するのに役立ちます。

基本的なドレインは、クラスターに他のノードにワークロードを即座に再スケジュールする能力がある場合、しばしば十分です。安定した可用性が保証されなければならない状況では、ポッド中断予算を使用してください。これにより、複数のドレインが同時に開始される際の意図しないダウンタイムから保護することができます。