Kubernetes扩缩容与滚动更新_kubectl scale 5个副本-CSDN博客

本文链接：https://blog.csdn.net/cj151525/article/details/147358741

一、应用扩缩容

1.1 应用扩容

在本节中，你将手动编辑Deployment YAML文件，将副本的数量增加到10个，并重新将其发送给Kubernetes。检查当前的副本数量：

$ kubectl get deployment qsk-deploy
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
qsk-deploy    5/5     5            5           16h

编辑deploy.yml文件，将spec.replicas字段设置为10，并保存修改：

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: qsk-deploy 
spec:
  replicas: 5           <<== 将这里改成10
  selector: 
    matchLabels: 
      project: qsk-book 
<Snip>

使用kubectl将更新的文件重新发送给Kubernetes。当Kubernetes收到该文件时，它将把期望状态从5个副本改为10个。Deployment控制器将观察集群上的5个副本，并注意到它不符合新的期望状态。它将调度5个新副本，使观察到的状态与期望状态一致。

执行下面命令更新 deploy.yml文件：

$ kubectl apply -f deploy.yml
deployment.apps/qsk-deploy configured

使用的这种方法被称为声明式方法，因为你在YAML清单文件中声明了一个新的期望状态，并使用该文件更新集群。

1.2 应用缩容

可以使用kubectl scale命令将Pod的数量缩减回5个。这种方法被称为命令式方法，不像声明式方法那样常见，在声明式方法中，是通过更新YAML文件并将其重新发送给Kubernetes来进行所有配置更改。

$ kubectl scale --replicas 5 deployment/qsk-deploy
deployment.apps/qsk-deploy scaled

用kubectl scale命令式地完成扩缩容操作会很危险。如果以后你编辑deploy.yml文件，指定一个容器镜像被更新过的版本，并重新发送给Kubernetes，你也会将副本的数量增加到10。这可能不是你想要的。在真实世界中，你应该非常小心这一点，因为它可能会导致重大问题。考虑到这一点，一般来说，好的做法是只通过更新YAML文件并重新发送给Kubernetes来声明式地完成更新。

二、执行滚动更新

接下来配置一个滚动更新，迫使Kubernetes以有条不紊的方式每次更新1个副本，直到5个副本都运行新版本。实施步骤如下：

编写新版本的应用。
为新版本应用构建新的容器镜像。
将新的容器镜像推送到容器仓库。你将完成以下步骤。
编辑deploy.yml文件，指定一个新版本镜像并配置更新设置。
重新将YAML文件发送给Kubernetes。
观察这个更新过程。
测试新版本。

打开deploy.yml文件，修改最后一行（第26行）以引用1.1版本的镜像。同时添加6行代码（第10～15行），代码清单如下：

1 apiVersion: apps/v1
2 kind: Deployment 
3 metadata:
4   name: qsk-deploy 
5 spec:
6   replicas: 5 
7   selector:
8     matchLabels:
9       project: qsk-book 
10  minReadySeconds: 20            <<== 添加这一行
11  strategy:                      <<== 添加这一行
12    type: RollingUpdate          <<== 添加这一行
13    rollingUpdate:               <<== 添加这一行
14      maxSurge: 1                <<== 添加这一行
15      maxUnavailable: 0          <<== 添加这一行
16  template:
17    metadata:
18      labels:
19        project: qsk-book 
20    spec:
21      containers:
22      - name: hello-pod 
23        imagePullPolicy: Always 
24        ports:
25        - containerPort: 8080 
26        image: nigelpoulton/qsk-book:1.1 <<== 设置为1.1

第10行中的minReadySeconds告诉Kubernetes在更新每个副本后要等待20秒。也就是说，Kubernetes将先更新第一个副本，等待20秒；更新第二个副本，等待20秒；更新第三个……如此往复。这样的间隔等待让你有机会运行测试，确保新副本按预期工作。在实际情况中，在两个副本更新之间你可能会等待超过20秒。另外，Kubernetes实际上没有更新副本，它所做的是删除现有的副本，并用一个运行新版本的全新副本来代替它们。第11行和第12行强制Kubernetes以滚动更新的方式执行对此Deployment的所有更新。第14行和第15行强制Kubernetes一次更新一个Pod，运行机制是：第14行中maxSurge=1允许Kubernetes在更新操作中增加一个额外的Pod，期望状态需要5个Pod，所以Kubernetes可以在更新期间将其增加到6个；第15行中maxUnavailable=0防止Kubernetes在更新期间减少Pod的数量，期望状态还是需要5个Pod，所以Kubernetes不允许比这更少。结合起来，第14行和第15行迫使Kubernetes删除运行旧版本的副本的同时增加运行新版本的第六个副本。这个过程一直重复，直到5个副本全都在运行需要的版本。

确保你已经保存了修改，并将更新过的配置发送给Kubernetes：

$ kubectl apply -f deploy.yml
deployment.apps/qsk-deploy configured

你可以用以下命令监控工作的进展：

$ kubectl rollout status deployment qsk-deploy
Waiting for rollout to finish: 1 out of 5 have been updated...
Waiting for rollout to finish: 1 out of 5 have been updated...
Waiting for rollout to finish: 2 out of 5 have been updated...
Waiting for rollout to finish: 2 out of 5 have been updated...
Waiting for rollout to finish: 3 out of 5 have been updated...
Waiting for rollout to finish: 3 out of 5 have been updated...
Waiting for rollout to finish: 4 out of 5 have been updated...
Waiting for rollout to finish: 4 out of 5 have been updated...
Waiting for rollout to finish: 2 old replicas are pending termination...
Waiting for rollout to finish: 1 old replicas are pending termination...
deployment "qsk-deploy" successfully rolled out