現在表示しているのは、次のバージョン向けのドキュメントです。Kubernetesバージョン: v1.25
Kubernetes v1.25 のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: 最新バージョン
APIを起点とした退避
APIを起点とした退避は、Eviction APIを使用して退避オブジェクトを作成し、Podの正常終了を起動させるプロセスです。
Eviction APIを直接呼び出すか、kubectl drain
コマンドのようにAPIサーバーのクライアントを使って退避を要求することが可能です。これにより、Eviction
オブジェクトを作成し、APIサーバーにPodを終了させます。
APIを起点とした退避はPodDisruptionBudgets
とterminationGracePeriodSeconds
の設定を優先します。
APIを使用してPodのEvictionオブジェクトを作成することは、Podに対してポリシー制御されたDELETE
操作を実行することに似ています。
Eviction APIの実行
Kubernetes APIへアクセスしてEviction
オブジェクトを作るためにKubernetesのプログラミング言語のクライアントを使用できます。
そのためには、次の例のようなデータをPOSTすることで操作を試みることができます。
policy/v1
においてEvictionはv1.22以上で利用可能です。それ以前のリリースでは、policy/v1beta1
を使用してください。{
"apiVersion": "policy/v1",
"kind": "Eviction",
"metadata": {
"name": "quux",
"namespace": "default"
}
}
policy/v1
が採用されました。{
"apiVersion": "policy/v1beta1",
"kind": "Eviction",
"metadata": {
"name": "quux",
"namespace": "default"
}
}
また、以下の例のようにcurl
やwget
を使ってAPIにアクセスすることで、操作を試みることもできます。
curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
APIを起点とした退避の仕組み
APIを使用して退去を要求した場合、APIサーバーはアドミッションチェックを行い、以下のいずれかを返します。
200 OK
:この場合、退去が許可されるとEviction
サブリソースが作成され、PodのURLにDELETE
リクエストを送るのと同じように、Podが削除されます。429 Too Many Requests
:PodDisruptionBudgetの設定により、現在退去が許可されていないことを示します。しばらく時間を空けてみてください。また、APIのレート制限のため、このようなレスポンスが表示されることもあります。500 Internal Server Error
:複数のPodDisruptionBudgetが同じPodを参照している場合など、設定に誤りがあり退去が許可されないことを示します。
退去させたいPodがPodDisruptionBudgetを持つワークロードの一部でない場合、APIサーバーは常に200 OK
を返して退去を許可します。
APIサーバーが退去を許可した場合、以下の流れでPodが削除されます。
- APIサーバーの
Pod
リソースの削除タイムスタンプが更新され、APIサーバーはPod
リソースが終了したと見なします。またPod
リソースは、設定された猶予期間が設けられます。 - ローカルのPodが動作しているNodeのkubeletは、
Pod
リソースが終了するようにマークされていることに気付き、Podの適切なシャットダウンを開始します。 - kubeletがPodをシャットダウンしている間、コントロールプレーンはEndpointオブジェクトからPodを削除します。その結果、コントローラーはPodを有効なオブジェクトと見なさないようになります。
- Podの猶予期間が終了すると、kubeletはローカルPodを強制的に終了します。
- kubeletはAPIサーバーに
Pod
リソースを削除するように指示します。 - APIサーバーは
Pod
リソースを削除します。
トラブルシューティング
場合によっては、アプリケーションが壊れた状態になり、対処しない限りEviction APIが429
または500
レスポンスを返すだけとなることがあります。例えば、ReplicaSetがアプリケーション用のPodを作成しても、新しいPodがReady
状態にならない場合などです。また、最後に退去したPodの終了猶予期間が長い場合にも、この事象が見られます。
退去が進まない場合は、以下の解決策を試してみてください。
- 問題を引き起こしている自動化された操作を中止または一時停止し、操作を再開する前に、スタックしているアプリケーションを調査を行ってください。
- しばらく待ってから、Eviction APIを使用する代わりに、クラスターのコントロールプレーンから直接Podを削除してください。
次の項目
- Pod Disruption Budgetでアプリケーションを保護する方法について学ぶ
- Node不足による退避について学ぶ
- Podの優先度とプリエンプションについて学ぶ