Question

我试图通过将minReadySeconds和readinessprobe应用于现有Deployment来了解kubernetes部署策略。但是如果我提到了副本字段，则会获得不同的结果。现有部署清单如下：

kind: Deployment
apiVersion: apps/v1
metadata:
 name: kubia-dep
spec:
 replicas: 3
 selector:
  matchLabels:
   app: dev
 template:
  metadata:
    name: dep-spec
    labels:
     app: dev
  spec:
   containers:
   - name: kubia-dep-cn
     image: luksa/kubia:v2

部署和吊舱状态如下

[root@master ~]# kubectl get deployments
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
kubia-dep   3/3     3            3           30s
[root@master ~]#

[root@master ~]# kubectl get po
NAME                         READY   STATUS    RESTARTS   AGE
kubia-dep-54cd566dc8-4vbjq   1/1     Running   0          113s
kubia-dep-54cd566dc8-kssrb   1/1     Running   0          113s
kubia-dep-54cd566dc8-vgjpv   1/1     Running   0          113s
[root@master ~]#

现在，我正在应用minReadySeconds，readinessProbe并将映像更新为luksa / kubia：v3，其中从第五个请求开始的代码均为All http请求，将返回内部服务器错误（HTTP状态代码500）以测试以下优点minReadySeconds，readinessProbe的组合

kind: Deployment
apiVersion: apps/v1
metadata:
 name: kubia-dep
spec:
 replicas: 3
 minReadySeconds: 10
 selector:
  matchLabels:
   app: dev
 strategy:
  rollingUpdate:
   maxSurge: 1
   maxUnavailable: 0
  type: RollingUpdate
 template:
  metadata:
   name: dep-spec
   labels:
    app: dev
  spec:
   containers:
   - name: kubia-dep-cn
     image: luksa/kubia:v3
     readinessProbe:
      httpGet:
       path: /
       port: 8080
      periodSeconds: 1

部署状态，吊舱状态如下

[root@master ~]# kubectl get deployments
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
kubia-dep   0/3     3            0           9m4s
[root@master ~]#

[root@master ~]# kubectl get po
NAME                        READY   STATUS    RESTARTS   AGE
kubia-dep-7c884d659-h4svd   0/1     Running   0          6m3s
kubia-dep-7c884d659-nrwdf   0/1     Running   0          6m5s
kubia-dep-7c884d659-wmzfk   0/1     Running   0          6m8s
[root@master ~]#

现在没有吊舱处于就绪状态。我的意思是像所有3个吊舱都具有错误图像版本一样，如果我碰到卷曲，我就会得到

while true;do curl http://10.104.60.165;done
curl: (7) Failed connect to 10.104.60.165:80; Connection refused
curl: (7) Failed connect to 10.104.60.165:80; Connection refused
curl: (7) Failed connect to 10.104.60.165:80; Connection refused

期望：在第一个新的第3版pod可用之前，推广过程将不会继续，现有的第2版pod将为传入的请求提供服务

实际： 3个具有新的越野车v3版本的Pod正在运行，并拒绝了所有与应用程序的连接

那么这是在更新现有部署时提到副本字段的影响吗？如果是这样，它是如何工作的？

更新kubernetes中的现有部署时，副本字段有什么影响？

0 个答案: