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/