シンプルな Kubernetes デプロイがあります。レプリケートされていない単一のコンテナーで構成されます。コンテナーを公開するサービスはありません。コンテナーには、コンテナーが正しく構成されており、外部の依存関係と通信できることを確認するヘルス チェックがあります。を使用して展開を更新しkubectl applyます。
デプロイを更新した後、新しいバージョンが完全にロールアウトされ、ヘルス チェックに合格していることを確認したいと思います。それを実現するために展開を構成する方法がわかりません。
liveness プローブと readiness プローブ、展開戦略、ready/progress 展開プロパティのさまざまな組み合わせを試しました。デプロイ、そのポッド、およびロールアウト コマンドのステータスを調べてみました。すべて役に立たない。
ステータスを理解するために展開条件を確認する必要があるという印象を受けましたが、それらの条件が何であるか、またはそれらをどのように実現するかについての明確なドキュメントを見つけることができません。
展開戦略について言及していません。しかし、k8s の展開で見た一般的な問題の 1 つは、アプリケーションが起動に失敗すると、無限に再起動されることです。kubectl delete deploy/******そのため、展開の失敗ステータスを検出した後、明示的に行う必要がある場合があります。（プローブ用もありますがfailureThreshold、まだ試していません）。
ケースの再現:
progressDeadlineSecondsと を組み合わせて使用できますreadinessProbe。アプリケーションの起動/スピンアップに 60 秒かかるとします。progressDeadlineSeconds安全のために、60 秒より少し長く設定する必要があります。kubectl apply -f my-deploy.yamlを実行した後、コマンドを実行しますkubectl rollout status deploy/my-deployment。私にとっては、次のようになります。
12:03:37 kubectl apply -f deploy.yaml
12:03:38 deployment "my-deployment" configured
12:04:18 kubectl rollout status deploy/my-deployment
12:04:18 Waiting for rollout to finish: 0 of 1 updated replicas are available (minimum required: 1)...
12:04:44 deployment "my-deployment" successfully rolled out
コマンドを実行するとrollout、kubectl は応答があるまで待機し続けます。また、適切な終了コードが返されますecho $?。これをプログラムで確認し、デプロイを削除できます。
ケースローリングアップデート:
複数のレプリカがある場合は、上記のトリックが機能するはずです。レプリカが 1 つしかない場合は、上記の構成とともにmaxUnavailable: 0andを使用します。maxSurge: 1