rancher のデプロイメントに最小限の可用性の問題はありません。

結論、理由は見つかりませんでしたが、解決策はあります。

背景を説明します。

自社サービスをコンテナ化することになり、検討の結果、コンテナ化管理にrancher（2.0）を使用することになりました。

dockerをパッケージ化する際、大きなリリースであれば新しいバージョンをパッケージ化し、小さなバグの修正であれば既存のバージョンの上にリピートリリースを行います。例えば、バージョン1.8をリリースして、小さなバグを見つけて修正するのに間に合った場合、1.8で修正を続けてからポッドをアップグレードする、というようなことです。

docker build -t xxx:1.8 .

そんなある日、サーバーを追加し、ポッドをアップグレードしたところ、バッチサイズに応じたポッドの破壊ではなく、バッチサイズのポッドを作成しただけで止まってしまい、古いポッドは古いレプリカセットのバージョンのままになっていました。という赤い警告が出ています。

" ReplicaSet "vplay-sock-678f59d96b"は進行がタイムアウトになりました。

これはどういうことでしょうか？それが最初の質問です。

2つ目の問題は、正常であればすべてのポッドが同じレプリカセットのバージョンで動いているはずなのに、今は複数のレプリカセットのバージョンが共存しており、古いポッドを削除したくてもrancherを通して削除できない、削除しても削除した古いバージョンが自動的に再作成されてしまうことです。

2つ目の問題については、なぜこのようなことが起こるのかわからないので、上記で "疑わしい点" を挙げましたが、これがすべての問題の原因だと思われます。しかし、私は以下のようにしてそれを取り除きました。

[root@rc02 ~]# kubectl get rs -n uc-hd
NAME DESIRED CURRENT READY AGE
vplay-sock-5446b85b85 0 0 0 0 18h
vplay-sock-5b7d4c6f87 0 0 0 24d
vplay-sock-5b958c5cf7 0 0 0 2d
vplay-sock-5dcdb94b9b 0 0 0 17h
vplay-sock-64bc86bd68 0 0 0 18h
vplay-sock-64dbd48dc5 0 0 0 0 22d
vplay-sock-65bf7f85fb 0 0 0 9d
vplay-sock-66598896b9 0 0 0 0 17h
vplay-sock-66f6dd9bcb 0 0 0 0 18h
vplay-sock-694f79c576 0 0 0 0 18h
vplay-sock-69b4f8b5f 0 0 0 0 9d
vplay-sock-69c9bb9947 0 0 0 11d
vplay-sock-6f4d6df54 0 0 0 0 14d
vplay-sock-6f6d5f94 0 0 0 0 17h
vplay-sock-796dbc59cf 0 0 0 0 9d
vplay-sock-7d6df65f6b 30 30 15 15h
vplay-sock-856b56bb46 0 0 0 0 29d
vplay-sock-d8cd77597 0 0 0 29d
[root@rc02 ~]# kubectl get rs -n uc-hd|wc -l
19
[root@rc02 ~]# kubectl delete rs -n uc-hd vplay-sock-5b7d4c6f87
[root@rc02 ~]# kubectl get rs -n uc-hd|wc -l
18

受信したレプリカセット名の一覧で、削除する旧バージョンを見つけ、AGEカラムでどれが旧バージョンかを判断します。

一度削除すると、新しい古いバージョンは作成されません。この問題は一応解決したのですが、何が原因なのかわかりません。

質問1の"Deployment does not have minimum availability"については、"最低限必要なデプロイが満たされていない"という意味ですが、どこが満たされていないのでしょうか？quotaの設定を確認したところ、Podにquotaはなく、無制限になっています。アップグレードすると毎回、最初に "Deployment does not have minimum availability" と表示され、数分後に "ReplicaSet " xxxx" has timed out progressing という文が表示されます。 "と共に、訳は "最低限のデプロイ要件を満たしていないため、レプリカセットxxxの処理タイムアウトが発生しました"となっているので、最初にポッドのバッチサイズが生成されています。 そこで目にするのは、最初にポッドのバッチサイズが生成されて、それが赤いロード状態に変わり、最後に緑になってデプロイがOKになります。しかし！通常であれば、以前から20個のPodがあれば、アップグレードする際に、設定したローリング戦略（最初に新しいPodのバッチサイズを作成し、OKが出たら対応する数の古いPodを消すという戦略）通りにアップグレードして入れ替えることができるはずなのに、そうならず、1バッチで終了してしまったのである。問題は、結局原因がわからなかったことで、やはり私の疑心暗鬼が原因なのではないかと思っています。

問題は、原因を見つけることができないだけでなく、すべての後に、元旦の休日に、ああ解決しなければならない、毎日守ることができない、問題が発生すると、これは動作しませんオフラインサーバー（これはすることができます）SLBを聞かせてください。その後、私は再び新しいサービスを再デプロイする必要があったので、私はちょうど1つをクローン。

クローンを作成する際、サービスを確実にするために考慮しなければならないことがいくつかあります。

1. 以前は、私のサービスはunixドメインソケットを介してipcだったので、今回は、クローンアウトのために新しいsockパスを展開する必要があるかもしれません

2. nginx のアップストリームの共有ディレクトリを、クローンした新しい sock パスを指すように修正します。

3、他の共有ディレクトリのパスは慎重にトラブルシュートする

最後に、リンクをいくつか記録します。

を参照してください。

1. k8sのデプロイメントによくある10の失敗シナリオ https://kukulinski.com/10-most-common-reasons-kubernetes-deployments-fail-part-2/