rancher 的 deployment does not have minimum availability 問題

結論，沒找到原因，但有解決方案。

背景：

公司要進行服務容器化，經過一番考察決定使用rancher(2.0)進行容器化管理。

存疑點：在進行docker打包的時候，如果是大版本，我會打包一個新版本；如果是修復一個小bug的話，我會在已有版本上進行重複發版。比如之前釋出了一個版本1.8，如果後來及時發現小bug並修正的話，我會繼續在1.8上修復，然後upgrade pods：

docker build -t xxx:1.8 .

然後有一天增加了一臺伺服器，在upgrade pods之後發現pods並沒有按照batch size進行新建pod和舊pod銷燬，僅僅新建了batch size個pod之後就停滯了，舊的pod仍然是舊的replicaset版本。並且有一個紅色的提示：

“ReplicaSet "vplay-sock-678f59d96b" has timed out progressing.; Deployment does not have minimum availability.”

這是什麼意思？這是第一個問題。

第二個問題是，如果正常的話，所有的pod應該是執行的都是同一個replicaset版本，但是我現在是多個replicaset版本共存的，而且我想通過rancher刪掉舊的pod是刪不掉的，即使你刪掉它，它依然會自動重新建立一個被刪掉的舊版本。

對於第二個問題，我不知道為何會出現這樣的問題，所以我在上面提了一個“存疑點”，我懷疑所有的問題都是這個“存疑點”引起的。但我是通過如下的方法進行刪除的：

[root@rc02 ~]# kubectl get rs -n uc-hd
NAME                    DESIRED   CURRENT   READY   AGE
vplay-sock-5446b85b85   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       22d
vplay-sock-65bf7f85fb   0         0         0       9d
vplay-sock-66598896b9   0         0         0       17h
vplay-sock-66f6dd9bcb   0         0         0       18h
vplay-sock-694f79c576   0         0         0       18h
vplay-sock-69b4f8b5f    0         0         0       9d
vplay-sock-69c9bb9947   0         0         0       11d
vplay-sock-6f4d6df54    0         0         0       14d
vplay-sock-6f6d5f94     0         0         0       17h
vplay-sock-796dbc59cf   0         0         0       9d
vplay-sock-7d6df65f6b   30        30        15      15h
vplay-sock-856b56bb46   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

在列出來的來的replicaset名稱裡，你找到要刪掉的舊版本，你可以通過AGE列來進行判斷哪個是舊版本。

刪除之後就不會再產生新的老版本了。這個問題算是解決了，但是不知道因為什麼。

 

關於問題一“Deployment does not have minimum availability”，看意思是“沒有滿足最小的部署要求”，那我們是哪裡沒滿足呢？查了關於quota配額的配置，我們都沒給pod設定配額，都是不限的。每次在我upgrade的時候，都會先提示“Deployment does not have minimum availability”，然後過幾分鐘，前面多了一句“ReplicaSet "xxxx" has timed out progressing.”，一起翻譯過來就是“沒有滿足最小的部署要求，導致副本集xxx處理超時”，所以我看到的是先產生batch size個pods，然後變成紅色的loading狀，最後變成綠色就部署ok了。但是！按理說，正常的情況是比如之前我又20個pods，那麼當我upgrade之後，應該會根據設定的rolling策略（我的策略是先建立batch size個新的pod，然後等ok了再關掉相應數量的久的pods）進行升級替換的，但並沒有，只是進行了一個批次就結束了。這個問題是最後也沒有找到原因，我懷疑還是我的存疑點導致的。

問題找不到原因，但也得解決啊，畢竟要過元旦放假了，不能每天守著，遇到問題就讓slb下線伺服器（這個可以作為一個），這不行。那我只能是重新再部署一個新的服務了，於是直接克隆了一個。

克隆的時候你要考慮的事情有幾點來保證服務：

1、之前我的服務是通過unix domain socket進行ipc的，那這個時候可能就要給克隆出來的部署一個新的sock路徑

2、修改nginx的upstream的共享目錄，指向克隆出來的那個新的sock路徑

3、其他的共享目錄路徑仔細排查

 

最後記錄一些links：

ref：

1、10個k8s部署常見的失敗情景：https://kukulinski.com/10-most-common-reasons-kubernetes-deployments-fail-part-2/