在kubectl编辑后，旧的ReplicaSet未被新的ReplicaSet替换

Question

我正在使用this yaml文件创建展开。它创建了4个busybox pod的副本。一切都很好，直到这里。

但是，当我使用命令kubectl edit deployment my-dep2编辑此部署时，仅将busybox镜像的版本更改为1.31 (从K8s的角度来看，这是一个降级，但仍然是更新)，ReplicaSet并没有完全被替换。

kubectl get all --selector app=my-dep2 post编辑后的输出为：

NAME                          READY   STATUS             RESTARTS   AGE
pod/my-dep2-55f67b974-5k7t9   0/1     ErrImagePull       2          5m26s
pod/my-dep2-55f67b974-wjwfv   0/1     CrashLoopBackOff   2          5m26s
pod/my-dep2-dcf7978b7-22khz   0/1     CrashLoopBackOff   6          12m
pod/my-dep2-dcf7978b7-2q5lw   0/1     CrashLoopBackOff   6          12m
pod/my-dep2-dcf7978b7-8mmvb   0/1     CrashLoopBackOff   6          12m

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-dep2   0/4     2            0           12m

NAME                                DESIRED   CURRENT   READY   AGE
replicaset.apps/my-dep2-55f67b974   2         2         0       5m27s
replicaset.apps/my-dep2-dcf7978b7   3         3         0       12m

从上面的输出中可以看到，有2个ReplicaSet是并行存在的。我希望旧的ReplicaSet能被新的ReplicaSet (包含1.31版本的BusyBox1.31)完全取代。但这并没有发生。这里我漏掉了什么？

Answer 1

您忽略了错误ErrImagePull和CrashLoopBackOff。他们告诉你不可能运行新的容器(在docker注册表中找不到镜像)，所以保留旧的容器以确保服务运行(蓝绿色默认/滚动更新)。

编辑

此外，Busybox容器启动后什么也不运行(据我所知)，然后结束，这会导致Kubernetes重新启动它，并且永远不会到达alive状态。也许你最好运行一些sleep 300到它的入口点？

Answer 2

正如@emi所说的，busybox和alpine等不会做任何事情，以防你给出一个明确的命令。Kubernetes尝试继续运行，但默认容器不执行任何操作，最后，Kubernetes说，好的，有问题不需要一次又一次地尝试重新启动容器。出于测试目的，它可能如下所示。

kind: Pod
apiVersion: v1
metadata:
  name: my-test-pod
spec:
  containers:
  - image: nginx
    name: enginx
  - image: alpine
    name: alpine
    command: ["sleep", "3600"]

Answer 3

这是完全正常的，预期的结果，与kubernetes中的Rolling Update机制有关

快速查看下面的工作示例，其中我使用了sample nginx Deployment。一旦部署完成，我就会运行：

kubectl edit deployments.apps nginx-deployment

并删除了图像标记，这实际上相当于对nginx:latest执行更新。应用更改后，您可以立即看到以下内容：

$ kubectl get all --selector=app=nginx
NAME                                    READY   STATUS              RESTARTS   AGE
pod/nginx-deployment-574b87c764-bvmln   0/1     Terminating         0          2m6s
pod/nginx-deployment-574b87c764-zfzmh   1/1     Running             0          2m6s
pod/nginx-deployment-574b87c764-zskkk   1/1     Running             0          2m7s
pod/nginx-deployment-6fcf476c4-88fdm    0/1     ContainerCreating   0          1s
pod/nginx-deployment-6fcf476c4-btvgv    1/1     Running             0          3s

NAME                       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/nginx-deployment   ClusterIP   10.3.247.159   <none>        80/TCP    6d4h

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     2            3           2m7s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-574b87c764   2         2         2       2m7s
replicaset.apps/nginx-deployment-6fcf476c4    2         2         1       3s

正如您所看到的，在某个时间点，两个副本中都有正在运行的pod。这是因为前面提到的滚动更新机制，它可以确保应用程序在更新时的可用性。

当更新过程结束时，旧replicaset中的副本计数减少到0，因此没有正在运行的pods，当新的pods达到其所需状态时，由此replicaset管理：

$ kubectl get all --selector=app=nginx
NAME                                   READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-6fcf476c4-88fdm   1/1     Running   0          10s
pod/nginx-deployment-6fcf476c4-btvgv   1/1     Running   0          12s
pod/nginx-deployment-6fcf476c4-db5z7   1/1     Running   0          8s

NAME                       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/nginx-deployment   ClusterIP   10.3.247.159   <none>        80/TCP    6d4h

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           2m16s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-574b87c764   0         0         0       2m16s
replicaset.apps/nginx-deployment-6fcf476c4    3         3         3       12s

你可能会问自己:为什么它还在那里？为什么没有在新的版本准备好后立即删除。尝试以下操作：

$ kubectl rollout history deployment nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

如您所见，此部署有两个版本。因此，现在我们可能想要简单地撤消最近的更改：

$ kubectl rollout undo deployment nginx-deployment
deployment.apps/nginx-deployment rolled back

现在，当我们查看我们的副本时，我们可以观察到一个相反的过程：

$ kubectl get all --selector=app=nginx
NAME                                    READY   STATUS              RESTARTS   AGE
pod/nginx-deployment-574b87c764-6j7l5   0/1     ContainerCreating   0          1s
pod/nginx-deployment-574b87c764-m7956   1/1     Running             0          4s
pod/nginx-deployment-574b87c764-v2r75   1/1     Running             0          3s
pod/nginx-deployment-6fcf476c4-88fdm    0/1     Terminating         0          3m25s
pod/nginx-deployment-6fcf476c4-btvgv    1/1     Running             0          3m27s
pod/nginx-deployment-6fcf476c4-db5z7    0/1     Terminating         0          3m23s

NAME                       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/nginx-deployment   ClusterIP   10.3.247.159   <none>        80/TCP    6d4h

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           5m31s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-574b87c764   3         3         2       5m31s
replicaset.apps/nginx-deployment-6fcf476c4    1         1         1       3m27s

注意，不需要创建第三个replicaset，因为仍然有一个旧的可以用来撤消我们最近的更改。最终结果如下所示：

$ kubectl get all --selector=app=nginx
NAME                                    READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-574b87c764-6j7l5   1/1     Running   0          40s
pod/nginx-deployment-574b87c764-m7956   1/1     Running   0          43s
pod/nginx-deployment-574b87c764-v2r75   1/1     Running   0          42s

NAME                       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/nginx-deployment   ClusterIP   10.3.247.159   <none>        80/TCP    6d4h

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           6m10s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-574b87c764   3         3         3       6m10s
replicaset.apps/nginx-deployment-6fcf476c4    0         0         0       4m6s

我希望上面的例子能帮助你理解为什么这个旧的replicaset没有被立即删除，以及它仍然有用的地方。