目录
文章目录
实验环境
实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
k8s version：v1.22.2
containerd://1.5.5
实验软件(无)
1、Deployment 控制器
前面我们学习了 ReplicaSet 控制器，了解到该控制器是用来维护集群中运行的 Pod 数量的，但是往往在实际操作的时候，我们反而不会去直接使用 RS，而是会使用更上层的控制器，比如我们今天要学习的主角 Deployment。Deployment 一个非常重要的功能就是实现了 Pod 的滚动更新，比如我们应用更新了，我们只需要更新我们的容器镜像，然后修改 Deployment 里面的 Pod 模板镜像，那么 Deployment 就会用滚动更新（Rolling Update）的方式来升级现在的 Pod，这个能力是非常重要的。因为对于线上的服务我们需要做到不中断服务，所以滚动更新就成了必须的一个功能。而 Deployment 这个能力的实现，依赖的就是上节课我们学习的ReplicaSet 这个资源对象，实际上我们可以通俗的理解就是每个 Deployment 就对应集群中的一次部署，这样就更好理解了。
2、Deployment
Deployment 资源对象的格式和 ReplicaSet 几乎一致，如下资源对象就是一个常见的 Deployment 资源类型：
[root@master1 ~]#vim nginx-deploy.yaml
# nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
namespace: default
labels: #这个标签仅仅用于标记deployment本身这个资源对象
role: deploy
spec:
replicas: 3 #期望的Pod副本数量
selector: #label selector
matchLabels:
app: nginx
test: course
template: #Pod模板
metadata:
labels: #一定要和上面的selector 保持一致
app: nginx
test: course
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
我们这里只是将类型替换成了 Deployment，我们可以先来创建下这个资源对象：
[root@master1 ~]#kubectl apply -f nginx-deploy.yaml
deployment.apps/nginx created
创建完成后，查看 Pod 状态：
[root@master1 ~]#kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 53s
nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 53s
nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 53s
[root@master1 ~]#kubectl get po -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 58s
nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 58s
nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 58s
[root@master1 ~]#kubectl get po -l test=course
NAME READY STATUS RESTARTS AGE
nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 64s
nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 64s
nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 64s
[root@master1 ~]#
到这里我们发现和之前的 RS 对象是否没有什么两样，都是根据spec.replicas来维持的副本数量，我们随意查看一个 Pod 的描述信息：
[root@master1 ~]#kubectl describe pod nginx-deploy-fd46765d4-8nzmp
Name: nginx-deploy-fd46765d4-8nzmp
Namespace: default
Priority: 0
Node: node1/172.29.9.52
Start Time: Sat, 13 Nov 2021 10:41:09 +0800
Labels: app=nginx
pod-template-hash=fd46765d4
test=course
Annotations: <none>
Status: Running
IP: 10.244.1.67
IPs:
IP: 10.244.1.67
Controlled By: ReplicaSet/nginx-deploy-fd46765d4 #注意这个
Containers:
nginx:
Container ID: containerd://8165e2ebf54336560b40e22ec42600aec52ff3154408573a7776aef3517fafda
Image: nginx
Image ID: docker.io/library/nginx@sha256:dfef797ddddfc01645503cef9036369f03ae920cac82d344d58b637ee861fda1
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sat, 13 Nov 2021 10:41:26 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-ftwv7 (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-ftwv7:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 93s default-scheduler Successfully assigned default/nginx-deploy-fd46765d4-8nzmp to node1
Normal Pulling 92s kubelet Pulling image "nginx"
Normal Pulled 77s kubelet Successfully pulled image "nginx" in 15.219437288s
Normal Created 77s kubelet Created container nginx
Normal Started 77s kubelet Started container nginx
[root@master1 ~]#
我们仔细查看其中有这样一个信息ReplicaSet/nginx-deploy-fd46765d4，什么意思？**是不是表示当前我们这个 Pod 的控制器是一个 ReplicaSet 对象啊，我们不是创建的一个 Deployment 吗？为什么 Pod 会被 RS 所控制呢？**那我们再去看下这个对应的 RS 对象的详细信息如何呢：
[root@master1 ~]#kubectl describe rs nginx-deploy-fd46765d4
Name: nginx-deploy-fd46765d4
Namespace: default
Selector: app=nginx,pod-template-hash=fd46765d4,test=course
Labels: app=nginx
pod-template-hash=fd46765d4
test=course
Annotations: deployment.kubernetes.io/desired-replicas: 3
deployment.kubernetes.io/max-replicas: 4
deployment.kubernetes.io/revision: 1
Controlled By: Deployment/nginx-deploy
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
pod-template-hash=fd46765d4
test=course
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 2m1s replicaset-controller Created pod: nginx-deploy-fd46765d4-ckdhw
Normal SuccessfulCreate 2m1s replicaset-controller Created pod: nginx-deploy-fd46765d4-9rzqt
Normal SuccessfulCreate 2m1s replicaset-controller Created pod: nginx-deploy-fd46765d4-8nzmp
[root@master1 ~]#
其中有这样的一个信息：Controlled By: Deployment/nginx-deploy，明白了吧？意思就是我们的 Pod 依赖的控制器 RS 实际上被我们的 Deployment 控制着呢。
我们再来看一下我们的deployment nginx-deploy：
[root@master1 ~]#kubectl describe deployments.apps nginx-deploy
Name: nginx-deploy
Namespace: default
CreationTimestamp: Sat, 13 Nov 2021 10:41:09 +0800
Labels: role=deploy
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=nginx,test=course
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
test=course
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deploy-fd46765d4 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 2m36s deployment-controller Scaled up replica set nginx-deploy-fd46765d4 to 3 #注意这个
[root@master1 ~]#
我们可以用下图来说明 Pod、ReplicaSet、Deployment 三者之间的关系：
通过上图我们可以很清楚的看到，定义了3个副本的 Deployment 与 ReplicaSet 和 Pod 的关系，就是一层一层进行控制的。ReplicaSet 作用和之前一样还是来保证 Pod 的个数始终保存指定的数量，所以 Deployment 中的容器 restartPolicy=Always 是唯一的就是这个原因，因为容器必须始终保证自己处于 Running 状态，ReplicaSet 才可以去明确调整 Pod 的个数。***而 Deployment 是通过管理 ReplicaSet 的数量和属性来实现水平扩展/收缩以及滚动更新两个功能的。***
1.水平伸缩
水平扩展/收缩的功能比较简单，因为 ReplicaSet 就可以实现，所以 Deployment 控制器只需要去修改它缩控制的 ReplicaSet 的 Pod 副本数量就可以了。比如现在我们把 Pod 的副本调整到 4 个，那么 Deployment 所对应的 ReplicaSet 就会自动创建一个新的 Pod 出来，这样就水平扩展了，我们可以使用一个新的命令 kubectl scale 命令来完成这个操作：
先来看下当前deployment、rs的数量:
[root@master1 ~]#kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 3/3 3 3 22m #这里表示有3个replica
[root@master1 ~]#kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-fd46765d4 3 3 3 22m #这里表示有3个replica 即：deployment和rs这的replicas的数量是保持一致的
[root@master1 ~]#
开始扩容pod：
[root@master1 ~]#kubectl scale deployment nginx-deploy --replicas=4
deployment.apps/nginx-deploy scaled
扩展完成后可以查看当前的 RS 对象：
[root@master1 ~]#kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-fd46765d4 4 4 3 23m
[root@master1 ~]#kubectl get rs #这里的4代表4个副本replica(pod)
NAME DESIRED CURRENT READY AGE
nginx-deploy-fd46765d4 4 4 4 24m
[root@master1 ~]#kubectl get deployments.apps #这里的4代表4个副本replica(pod)
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 4/4 4 4 24m
[root@master1 ~]#kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 6m52s
nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 6m52s
nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 6m52s
nginx-deploy-fd46765d4-tdkjv 1/1 Running 0 22s
[root@master1 ~]#
可以看到期望的 Pod 数量已经变成 4 了，只是 Pod 还没准备完成，所以 READY 状态数量还是 3，同样查看 RS 的详细信息：
[root@master1 ~]#kubectl describe rs nginx-deploy-fd46765d4
Name: nginx-deploy-fd46765d4
Namespace: default
Selector: app=nginx,pod-template-hash=fd46765d4,test=course
Labels: app=nginx
pod-template-hash=fd46765d4
test=course
Annotations: deployment.kubernetes.io/desired-replicas: 4
deployment.kubernetes.io/max-replicas: 5
deployment.kubernetes.io/revision: 1
Controlled By: Deployment/nginx-deploy
Replicas: 4 current / 4 desired
Pods Status: 4 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
pod-template-hash=fd46765d4
test=course
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 7m16s replicaset-controller Created pod: nginx-deploy-fd46765d4-ckdhw
Normal SuccessfulCreate 7m16s replicaset-controller Created pod: nginx-deploy-fd46765d4-9rzqt
Normal SuccessfulCreate 7m16s replicaset-controller Created pod: nginx-deploy-fd46765d4-8nzmp
Normal SuccessfulCreate 46s replicaset-controller Created pod: nginx-deploy-fd46765d4-tdkjv
[root@master1 ~]#
可以看到 ReplicaSet 控制器增加了一个新的 Pod，同样的 Deployment 资源对象的事件中也可以看到完成了扩容的操作：
[root@master1 ~]#kubectl describe deployments.apps nginx-deploy
Name: nginx-deploy
Namespace: default
CreationTimestamp: Sat, 13 Nov 2021 10:41:09 +0800
Labels: role=deploy
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=nginx,test=course
Replicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
test=course
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deploy-fd46765d4 (4/4 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 7m39s deployment-controller Scaled up replica set nginx-deploy-fd46765d4 to 3
Normal ScalingReplicaSet 69s deployment-controller Scaled up replica set nginx-deploy-fd46765d4 to 4
[root@master1 ~]#
注意：水平伸缩，并不是一次升级，因此这里的revision不会变的；
[root@master1 ~]#kubectl get deployments.apps,rs,po
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deploy 4/4 4 4 8m2s
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deploy-fd46765d4 4 4 4 8m2s
NAME READY STATUS RESTARTS AGE
pod/nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 8m2s
pod/nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 8m2s
pod/nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 8m2s
pod/nginx-deploy-fd46765d4-tdkjv 1/1 Running 0 92s
[root@master1 ~]#
[root@master1 ~]#kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
[root@master1 ~]#
好了，接下来我们看一下deployment的滚动更新。
2.滚动更新
如果只是水平扩展/收缩这两个功能，就完全没必要设计 Deployment 这个资源对象了，Deployment 最突出的一个功能是支持滚动更新。
我们先查看下deployment的升级策略：
[root@master1 ~]#kubectl explain deploy.spec.strategy
KIND: Deployment
VERSION: apps/v1
RESOURCE: strategy <Object>
DESCRIPTION:
The deployment strategy to use to replace existing pods with new ones.
DeploymentStrategy describes how to replace existing pods with new ones.
FIELDS:
rollingUpdate <Object>
Rolling update config params. Present only if DeploymentStrategyType =
RollingUpdate.
type <string>
Type of deployment. Can be "Recreate" or "RollingUpdate". Default is
RollingUpdate.#升级策略默认是RollingUpdate(滚动升级)
[root@master1 ~]#
首先，我们先把默认的滚动升级策略改为recreate，并且把pod模板的image改为nginx:1.7.9看下效果：
[root@master1 ~]#vim nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
namespace: default
labels: #这个标签仅仅用于标记deployment本身这个资源对象
role: deploy
spec:
replicas: 4 #期望的Pod副本数量
strategy:
type: Recreate
selector: #label selector
matchLabels:
app: nginx
test: course
template: #Pod模板
metadata:
labels: #一定要和上面的selector 保持一致
app: nginx
test: course
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
再测试之前，我们先来再次看下当前的测试环境：
[root@master1 ~]#kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 9m8s
nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 9m8s
nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 9m8s
nginx-deploy-fd46765d4-tdkjv 1/1 Running 0 2m38s
[root@master1 ~]#
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deploy 4/4 4 4 3m15s
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deploy-fd46765d4 4 4 4 3m15s
[root@master1 ~]#kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
[root@master1 ~]#
此时再打开一个终端，用watch命令监控下pod的变化情况：
[root@master1 ~]#kubectl get po --watch
NAME READY STATUS RESTARTS AGE
nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 9m34s
nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 9m34s
nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 9m34s
nginx-deploy-fd46765d4-tdkjv 1/1 Running 0 3m4s
-- test Recreate----
更新一下资源配置清单：
[root@master1 ~]#kubectl apply -f nginx-deploy.yaml
deployment.apps/nginx-deploy configured
[root@master1 ~]#
此时观察下刚才那个watch pod的终端发生的变化：
我们会发现**Recreate表示全部重新创建**，即把旧的pod全部删除掉，然后再用新镜像创建新版本的pod；
[root@master1 ~]#kubectl get po --watch
NAME READY STATUS RESTARTS AGE
nginx-deploy-fd46765d4-8nzmp 1/1 Running 0 9m34s
nginx-deploy-fd46765d4-9rzqt 1/1 Running 0 9m34s
nginx-deploy-fd46765d4-ckdhw 1/1 Running 0 9m34s
nginx-deploy-fd46765d4-tdkjv 1/1 Running 0 3m4s
-- test Recreate----
nginx-deploy-fd46765d4-tdkjv 1/1 Terminating 0 3m25s
nginx-deploy-fd46765d4-8nzmp 1/1 Terminating 0 9m55s
nginx-deploy-fd46765d4-ckdhw 1/1 Terminating 0 9m55s
nginx-deploy-fd46765d4-9rzqt 1/1 Terminating 0 9m55s
nginx-deploy-fd46765d4-ckdhw 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-ckdhw 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-ckdhw 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-9rzqt 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-9rzqt 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-9rzqt 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-tdkjv 0/1 Terminating 0 3m26s
nginx-deploy-fd46765d4-tdkjv 0/1 Terminating 0 3m26s
nginx-deploy-fd46765d4-tdkjv 0/1 Terminating 0 3m26s
nginx-deploy-fd46765d4-8nzmp 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-8nzmp 0/1 Terminating 0 9m56s
nginx-deploy-fd46765d4-8nzmp 0/1 Terminating 0 9m56s #原来old pod被一起删除
nginx-deploy-6c5ff87cf-4f229 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-4f229 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-w2csq 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-p866j 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-w2csq 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-ttm2v 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-p866j 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-ttm2v 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-p866j 0/1 ContainerCreating 0 0s
nginx-deploy-6c5ff87cf-4f229 0/1 ContainerCreating 0 1s
nginx-deploy-6c5ff87cf-w2csq 0/1 ContainerCreating 0 2s
nginx-deploy-6c5ff87cf-ttm2v 0/1 ContainerCreating 0 2s
nginx-deploy-6c5ff87cf-ttm2v 1/1 Running 0 4s
nginx-deploy-6c5ff87cf-p866j 1/1 Running 0 17s
nginx-deploy-6c5ff87cf-w2csq 1/1 Running 0 19s
nginx-deploy-6c5ff87cf-4f229 1/1 Running 0 34s
[root@master1 ~]#kubectl get deploy,rs,po
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deploy 4/4 4 4 11m
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deploy-6c5ff87cf 4 4 4 91s #当前rs
replicaset.apps/nginx-deploy-fd46765d4 0 0 0 11m
NAME READY STATUS RESTARTS AGE
pod/nginx-deploy-6c5ff87cf-4f229 1/1 Running 0 91s
pod/nginx-deploy-6c5ff87cf-p866j 1/1 Running 0 91s
pod/nginx-deploy-6c5ff87cf-ttm2v 1/1 Running 0 91s
pod/nginx-deploy-6c5ff87cf-w2csq 1/1 Running 0 91s
[root@master1 ~]#
[root@master1 ~]#kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
2 <none> #当前rs
#我们可以在看下当前rs的revisio是不是2呢：
[root@master1 ~]#kubectl describe rs nginx-deploy-6c5ff87cf |grep revision
deployment.kubernetes.io/revision: 2
[root@master1 ~]#
#我们再看下nginx-deploy deploy的 event：
[root@master1 ~]#kubectl describe deployments.apps |tail -8
NewReplicaSet: nginx-deploy-6c5ff87cf (4/4 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deploy-fd46765d4 to 3
Normal ScalingReplicaSet 5m46s deployment-controller Scaled up replica set nginx-deploy-fd46765d4 to 4
Normal ScalingReplicaSet 2m21s deployment-controller Scaled down replica set nginx-deploy-fd46765d4 to 0
Normal ScalingReplicaSet 2m20s deployment-controller Scaled up replica set nginx-deploy-6c5ff87cf to 4
[root@master1 ~]#
上面Recreate升级策略验证完了，接下来我们验证下RollingUpdate滚动更新升级策略：
先来看下RollingUpdate可以配置的选项：
[root@master1 ~]#kubectl explain deploy.spec.strategy.rollingUpdate
KIND: Deployment
VERSION: apps/v1
RESOURCE: rollingUpdate <Object>
DESCRIPTION:
Rolling update config params. Present only if DeploymentStrategyType =
RollingUpdate.
Spec to control the desired behavior of rolling update.
FIELDS:
maxSurge <string>
The maximum(最大限度) number of pods that can be scheduled above(超过) the desired number
of pods. Value can be an absolute(绝对的) number (ex: 5) or a percentage(百分比) of desired
pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number
is calculated(计算) from percentage by rounding up(四舍五入). Defaults to 25%. Example:
when this is set to 30%, the new ReplicaSet can be scaled up immediately
when the rolling update starts, such that the total number of old and new
pods do not exceed(超过) 130% of desired pods. Once(一旦) old pods have been killed,
new ReplicaSet can be scaled up further(进一步), ensuring that total number of pods
running at any time during the update is at most 130% of desired pods.
maxUnavailable <string>
The maximum number of pods that can be unavailable during the update. Value
can be an absolute number (ex: 5) or a percentage of desired pods (ex:
10%). Absolute number is calculated from percentage by rounding down(舍入，去尾法). This
can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set
to 30%, the old ReplicaSet can be scaled down to 70% of desired pods
immediately when the rolling update starts. Once new pods are ready, old
ReplicaSet can be scaled down further, followed by scaling up the new
ReplicaSet, ensuring that the total number of pods available at all times
during the update is at least 70% of desired pods.
[root@master1 ~]#
现在我们修改本次的升级策略为RollingUpdate，当然默认的策略就是RollingUpdate。同时，本次nginx镜像tag修改为latest。
[root@master1 ~]#vim nginx-deploy.yaml
#RollingUpdate测试
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
namespace: default
labels: #这个标签仅仅用于标记deployment本身这个资源对象
role: deploy
spec:
replicas: 4 #期望的Pod副本数量
minReadySeconds: 5
strategy:
type: RollingUpdate #指定滚动更新策略，默认
rollingUpdate:
maxUnavailable: 1 #最大不可用的pod数量
maxSurge: 1
selector: #label selector
matchLabels:
app: nginx
test: course
template: #Pod模板
metadata:
labels: #一定要和上面的selector 保持一致
app: nginx
test: course
spec:
containers:
- name: nginx
image: nginx:latest #本次nginx镜像tag修改为latest
ports:
- containerPort: 80
后前面相比较，除了更改了镜像之外，我们还指定了更新策略：
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
minReadySeconds：表示 Kubernetes 在等待设置的时间后才进行升级，如果没有设置该值，Kubernetes 会假设该容器启动起来后就提供服务了，如果没有设置该值，在某些极端情况下可能会造成服务不正常运行，默认值就是0。
这里应该说的是新版本容器启动后需要等待的时间；
type=RollingUpdate：表示设置更新策略为滚动更新，可以设置为Recreate和RollingUpdate两个值，Recreate表示全部重新创建，默认值就是RollingUpdate。maxSurge：表示升级过程中最多可以比原先设置多出的 Pod 数量，例如：maxSurage=1，replicas=5，就表示Kubernetes 会先启动一个新的 Pod，然后才删掉一个旧的 Pod，整个升级过程中最多会有5+1个 Pod。maxUnavaible：表示升级过程中最多有多少个 Pod 处于无法提供服务的状态，当maxSurge不为0时，该值也不能为0，例如：maxUnavaible=1，则表示 Kubernetes 整个升级过程中最多会有1个 Pod 处于无法服务的状态。
本次测试前的实验话环境我们再次来确认下：
[root@master1 ~]#kubectl get deploy,rs,pod
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deploy 4/4 4 4 17m
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deploy-6c5ff87cf 4 4 4 4m50s
replicaset.apps/nginx-deploy-fd46765d4 0 0 0 17m
NAME READY STATUS RESTARTS AGE
nginx-deploy-6c5ff87cf-4f229 1/1 Running 0 3m14s
nginx-deploy-6c5ff87cf-p866j 1/1 Running 0 3m14s
nginx-deploy-6c5ff87cf-ttm2v 1/1 Running 0 3m14s
nginx-deploy-6c5ff87cf-w2csq 1/1 Running 0 3m14s
[root@master1 ~]#
[root@master1 ~]#kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
2 <none>
[root@master1 ~]#
[root@master1 ~]#kubectl describe rs nginx-deploy-6c5ff87cf|grep revision
deployment.kubernetes.io/revision: 2
[root@master1 ~]#
[root@master1 ~]#kubectl describe po nginx-deploy-6c5ff87cf-4f229 |grep Image
Image: nginx:1.7.9
Image ID: sha256:35d28df486f6150fa3174367499d1eb01f22f5a410afe4b9581ac0e0e58b3eaf
[root@master1 ~]#
这里和上面一样的方法，我们另外打开一个窗口用--watch来监视下pod的变化状态：
[root@master1 ~]#kubectl get po --watch
NAME READY STATUS RESTARTS AGE
nginx-deploy-6c5ff87cf-4f229 1/1 Running 0 4m17s
nginx-deploy-6c5ff87cf-p866j 1/1 Running 0 4m17s
nginx-deploy-6c5ff87cf-ttm2v 1/1 Running 0 4m17s
nginx-deploy-6c5ff87cf-w2csq 1/1 Running 0 4m17s
---- test Roollingupdate-----
现在我们来直接更新上面的 Deployment 资源对象：
[root@master1 ~]#kubectl apply -f nginx-deploy.yaml
deployment.apps/nginx-deploy configured
[root@master1 ~]#
record 参数
我们可以添加了一个额外的
--record参数来记录下我们的每次操作所执行的命令，以方便后面查看。
更新后，我们可以执行下面的 kubectl rollout status 命令来查看我们此次滚动更新的状态：
我们先来看下rollout命令的可以参数：
[root@master1 ~]#kubectl rollout --help
Manage the rollout of a resource.
Valid resource types include:
* deployments
* daemonsets
* statefulsets
Examples:
# Rollback to the previous deployment
kubectl rollout undo deployment/abc
# Check the rollout status of a daemonset
kubectl rollout status daemonset/foo
Available Commands:
history View rollout history
pause(暂停) Mark the provided resource as paused
restart Restart a resource
resume(恢复) Resume a paused resource
status Show the status of the rollout
undo(撤销，使恢复原状) Undo a previous rollout
Usage:
kubectl rollout SUBCOMMAND [options]
Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).
[root@master1 ~]#
从上面的信息可以看出我们的滚动更新已经有两个 Pod 已经更新完成了，在滚动更新过程中，我们还可以执行如下的命令来暂停更新：
[root@master1 ~]#kubectl rollout pause deployment/nginx-deploy
deployment.apps/nginx-deploy paused
[root@master1 ~]#
这个时候我们的滚动更新就暂停了，此时我们可以查看下 Deployment 的详细信息：
[root@master1 ~]#kubectl describe deployments.apps nginx-deploy
Name: nginx-deploy
Namespace: default
CreationTimestamp: Sat, 13 Nov 2021 10:41:09 +0800
Labels: role=deploy
Annotations: deployment.kubernetes.io/revision: 3
Selector: app=nginx,test=course
Replicas: 4 desired | 2 updated | 5 total | 5 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 5
RollingUpdateStrategy: 1 max unavailable, 1 max surge
Pod Template:
Labels: app=nginx
test=course
Containers:
nginx:
Image: nginx:latest
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing Unknown DeploymentPaused
OldReplicaSets: nginx-deploy-6c5ff87cf (3/3 replicas created)
NewReplicaSet: nginx-deploy-595b8954f7 (2/2 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 15m deployment-controller Scaled up replica set nginx-deploy-fd46765d4 to 3
Normal ScalingReplicaSet 9m8s deployment-controller Scaled up replica set nginx-deploy-fd46765d4 to 4
Normal ScalingReplicaSet 5m43s deployment-controller Scaled down replica set nginx-deploy-fd46765d4 to 0
Normal ScalingReplicaSet 5m42s deployment-controller Scaled up replica set nginx-deploy-6c5ff87cf to 4
Normal ScalingReplicaSet 41s deployment-controller Scaled up replica set nginx-deploy-595b8954f7 to 1
Normal ScalingReplicaSet 41s deployment-controller Scaled down replica set nginx-deploy-6c5ff87cf to 3
Normal ScalingReplicaSet 41s deployment-controller Scaled up replica set nginx-deploy-595b8954f7 to 2
[root@master1 ~]#
我们仔细观察 Events 事件区域的变化，上面我们用 kubectl scale 命令将 Pod 副本调整到了 4，现在我们更新的时候是不是声明又变成 3 了，所以 Deployment 控制器首先是将之前控制的 nginx-deploy-85ff79dd56 这个 RS 资源对象进行缩容操作，然后滚动更新开始了，可以发现 Deployment 为一个新的 nginx-deploy-5b7b9ccb95 RS 资源对象首先新建了一个新的 Pod，然后将之前的 RS 对象缩容到 2 了，再然后新的 RS 对象扩容到 2，后面由于我们暂停滚动升级了，所以没有后续的事件了，大家有看明白这个过程吧？这个过程就是滚动更新的过程，启动一个新的 Pod，杀掉一个旧的 Pod，然后再启动一个新的 Pod，这样滚动更新下去，直到全都变成新的 Pod，这个时候系统中应该存在 4 个 Pod，因为我们设置的策略maxSurge=1，所以在升级过程中是允许的，而且是两个新的 Pod，两个旧的 Pod：
[root@master1 ~]#kubectl get po -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-deploy-595b8954f7-sp5nj 1/1 Running 0 86s
nginx-deploy-595b8954f7-z6pn4 1/1 Running 0 86s
nginx-deploy-6c5ff87cf-p866j 1/1 Running 0 6m27s
nginx-deploy-6c5ff87cf-ttm2v 1/1 Running 0 6m27s
nginx-deploy-6c5ff87cf-w2csq 1/1 Running 0 6m27s
[root@master1 ~]#
查看 Deployment 的状态也可以看到当前的 Pod 状态：
[root@master1 ~]#kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 5/4 2 5 16m
[root@master1 ~]#
这个时候我们可以使用kubectl rollout resume来恢复我们的滚动更新：
[root@master1 ~]#kubectl rollout resume deployment nginx-deploy
deployment.apps/nginx-deploy resumed
[root@master1 ~]#
[root@master1 ~]#kubectl rollout status deployment nginx-deploy
deployment "nginx-deploy" successfully rolled out
[root@master1 ~]#
看到上面的信息证明我们的滚动更新已经成功了，同样可以查看下资源状态：
[root@master1 ~]#kubectl get po -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-deploy-595b8954f7-p2qht 1/1 Running 0 68s
nginx-deploy-595b8954f7-qw6gz 1/1 Running 0 68s
nginx-deploy-595b8954f7-sp5nj 1/1 Running 0 3m25s
nginx-deploy-595b8954f7-z6pn4 1/1 Running 0 3m25s
[root@master1 ~]#kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 4/4 4 4 18m
[root@master1 ~]#
这个时候我们查看 ReplicaSet 对象，可以发现会出现3个：
[root@master1 ~]#kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-595b8954f7 4 4 4 3m43s
nginx-deploy-6c5ff87cf 0 0 0 8m44s
nginx-deploy-fd46765d4 0 0 0 18m
[root@master1 ~]#
从上面可以看出滚动更新之前我们使用的 RS 资源对象的 Pod 副本数已经变成 0 了，而滚动更新后的 RS 资源对象变成了 4 个副本，我们可以导出之前的 RS 对象查看：
[root@master1 ~]#kubectl get rs nginx-deploy-6c5ff87cf -oyaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
annotations:
deployment.kubernetes.io/desired-replicas: "4"
deployment.kubernetes.io/max-replicas: "5"
deployment.kubernetes.io/revision: "2"
creationTimestamp: "2021-11-13T02:51:05Z"
generation: 4
labels:
app: nginx
pod-template-hash: 6c5ff87cf
test: course
name: nginx-deploy-6c5ff87cf
namespace: default
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: Deployment
name: nginx-deploy
uid: ac7c0147-2ed9-4e61-91fa-b4bfdf185564
resourceVersion: "319487"
uid: d3455813-e6eb-480d-b88b-d4761d16c131
spec:
replicas: 0
selector:
matchLabels:
app: nginx
pod-template-hash: 6c5ff87cf
test: course
template:
metadata:
creationTimestamp: null
labels:
app: nginx
pod-template-hash: 6c5ff87cf
test: course
spec:
containers:
- image: nginx:1.7.9
imagePullPolicy: Always
name: nginx
ports:
- containerPort: 80
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
status:
observedGeneration: 4
replicas: 0 #replicas为0
我们仔细观察这个资源对象里面的描述信息除了副本数变成了 replicas=0 之外，和更新之前没有什么区别吧？大家看到这里想到了什么？**有了这个 RS 的记录存在，是不是我们就可以回滚了啊？而且还可以回滚到前面的任意一个版本，**这个版本是如何定义的呢？我们可以通过命令 rollout history 来获取：
[root@master1 ~]#kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
[root@master1 ~]#
**其实 rollout history 中记录的 revision 是和 ReplicaSets 一一对应。**如果我们手动删除某个 ReplicaSet，对应的rollout history就会被删除，也就是说你无法回滚到这个revison了，同样我们还可以查看一个revison的详细信息：
[root@master1 ~]#kubectl rollout history deployment nginx-deploy --revision=2
deployment.apps/nginx-deploy with revision #2
Pod Template:
Labels: app=nginx
pod-template-hash=6c5ff87cf
test=course
Containers:
nginx:
Image: nginx:1.7.9
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
[root@master1 ~]#
我们先来看下当前的revision是几呢：
[root@master1 ~]#kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
[root@master1 ~]#kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-deploy-595b8954f7-p2qht 1/1 Running 0 5m51s
nginx-deploy-595b8954f7-qw6gz 1/1 Running 0 5m51s
nginx-deploy-595b8954f7-sp5nj 1/1 Running 0 8m8s
nginx-deploy-595b8954f7-z6pn4 1/1 Running 0 8m8s
[root@master1 ~]#kubectl describe rs nginx-deploy-595b8954f7 |grep revision
deployment.kubernetes.io/revision: 3 #可以看到强的revision是3
[root@master1 ~]#
假如现在要直接回退到当前版本的前一个版本，我们可以直接使用如下命令进行操作：
➜ ~ kubectl rollout undo deployment nginx-deploy
当然也可以回退到指定的revision版本：
➜ ~ kubectl rollout undo deployment nginx-deploy --to-revision=1
deployment "nginx-deploy" rolled back
本次假设我们回退到1版本：
[root@master1 ~]#kubectl rollout undo deployment nginx-deploy --to-revision=1
deployment.apps/nginx-deploy rolled back
回滚的过程中我们同样可以查看回滚状态：
[root@master1 ~]#kubectl rollout status deployment nginx-deploy
Waiting for deployment "nginx-deploy" rollout to finish: 2 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 2 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 2 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 2 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 3 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 3 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 3 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 3 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 3 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 3 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 3 out of 4 new replicas have been updated...
Waiting for deployment "nginx-deploy" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx-deploy" rollout to finish: 3 of 4 updated replicas are available...
Waiting for deployment "nginx-deploy" rollout to finish: 3 of 4 updated replicas are available...
deployment "nginx-deploy" successfully rolled out
[root@master1 ~]#
这个时候查看对应的 RS 资源对象可以看到 Pod 副本已经回到之前的 RS 里面去了。
[root@master1 ~]#kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-595b8954f7 0 0 0 18m
nginx-deploy-6c5ff87cf 0 0 0 23m
nginx-deploy-fd46765d4 4 4 4 33m
[root@master1 ~]#
不过需要注意的是回滚的操作滚动的revision始终是递增的：
[root@master1 ~]#kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
2 <none>
3 <none>
4 <none>
[root@master1 ~]#
保留旧版本
在很早之前的 Kubernetes 版本中，默认情况下会为我们暴露下所有滚动升级的历史记录，也就是 ReplicaSet 对象，但一般情况下没必要保留所有的版本，毕竟会存在 etcd 中，我们可以通过配置
spec.revisionHistoryLimit属性来设置保留的历史记录数量，不过新版本中该值默认为 10，如果希望多保存几个版本可以设置该字段。
我们来查看下watch监控的内容：
[root@master1 ~]#kubectl get po --watch
NAME READY STATUS RESTARTS AGE
nginx-deploy-6c5ff87cf-4f229 1/1 Running 0 4m17s
nginx-deploy-6c5ff87cf-p866j 1/1 Running 0 4m17s
nginx-deploy-6c5ff87cf-ttm2v 1/1 Running 0 4m17s
nginx-deploy-6c5ff87cf-w2csq 1/1 Running 0 4m17s
---- test Roollingupdate-----
nginx-deploy-595b8954f7-z6pn4 0/1 Pending 0 0s
nginx-deploy-595b8954f7-z6pn4 0/1 Pending 0 0s
nginx-deploy-6c5ff87cf-4f229 1/1 Terminating 0 5m1s
nginx-deploy-595b8954f7-z6pn4 0/1 ContainerCreating 0 0s
nginx-deploy-595b8954f7-sp5nj 0/1 Pending 0 0s
nginx-deploy-595b8954f7-sp5nj 0/1 Pending 0 0s
nginx-deploy-595b8954f7-sp5nj 0/1 ContainerCreating 0 0s
nginx-deploy-6c5ff87cf-4f229 0/1 Terminating 0 5m2s
nginx-deploy-6c5ff87cf-4f229 0/1 Terminating 0 5m2s
nginx-deploy-6c5ff87cf-4f229 0/1 Terminating 0 5m2s
nginx-deploy-595b8954f7-sp5nj 1/1 Running 0 2s
nginx-deploy-595b8954f7-z6pn4 1/1 Running 0 17s
nginx-deploy-6c5ff87cf-ttm2v 1/1 Terminating 0 7m18s
nginx-deploy-6c5ff87cf-w2csq 1/1 Terminating 0 7m18s
nginx-deploy-595b8954f7-qw6gz 0/1 Pending 0 0s
nginx-deploy-595b8954f7-qw6gz 0/1 Pending 0 0s
nginx-deploy-595b8954f7-p2qht 0/1 Pending 0 0s
nginx-deploy-595b8954f7-p2qht 0/1 Pending 0 0s
nginx-deploy-595b8954f7-qw6gz 0/1 ContainerCreating 0 0s
nginx-deploy-595b8954f7-p2qht 0/1 ContainerCreating 0 0s
nginx-deploy-6c5ff87cf-ttm2v 0/1 Terminating 0 7m19s
nginx-deploy-6c5ff87cf-ttm2v 0/1 Terminating 0 7m19s
nginx-deploy-6c5ff87cf-ttm2v 0/1 Terminating 0 7m19s
nginx-deploy-6c5ff87cf-w2csq 0/1 Terminating 0 7m19s
nginx-deploy-6c5ff87cf-w2csq 0/1 Terminating 0 7m19s
nginx-deploy-6c5ff87cf-w2csq 0/1 Terminating 0 7m19s
nginx-deploy-595b8954f7-p2qht 1/1 Running 0 16s
nginx-deploy-595b8954f7-qw6gz 1/1 Running 0 17s
nginx-deploy-6c5ff87cf-p866j 1/1 Terminating 0 7m40s
nginx-deploy-6c5ff87cf-p866j 0/1 Terminating 0 7m40s
nginx-deploy-6c5ff87cf-p866j 0/1 Terminating 0 7m40s
nginx-deploy-6c5ff87cf-p866j 0/1 Terminating 0 7m40s
我们用命令kubectl describle deploy nginx反而更清晰可以看到滚动升级的过程：
[root@master1 ~]#kubectl describe deployments.apps nginx-deploy
Name: nginx-deploy
Namespace: default
CreationTimestamp: Thu, 11 Nov 2021 22:04:31 +0800
Labels: role=deploy
Annotations: deployment.kubernetes.io/revision: 3
Selector: app=nginx,test=course
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 5
RollingUpdateStrategy: 1 max unavailable, 1 max surge
Pod Template:
Labels: app=nginx
test=course
Containers:
nginx:
Image: nginx:latest
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deploy-595b8954f7 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 23m deployment-controller Scaled down replica set nginx-deploy-6c5ff87cf to 3
Normal ScalingReplicaSet 23m deployment-controller Scaled up replica set nginx-deploy-595b8954f7 to 1
Normal ScalingReplicaSet 23m deployment-controller Scaled down replica set nginx-deploy-6c5ff87cf to 2
Normal ScalingReplicaSet 23m deployment-controller Scaled up replica set nginx-deploy-595b8954f7 to 2
Normal ScalingReplicaSet 22m deployment-controller Scaled down replica set nginx-deploy-6c5ff87cf to 0
Normal ScalingReplicaSet 22m deployment-controller Scaled up replica set nginx-deploy-595b8954f7 to 3 #最终的目的：就是deployment-controller将old rs的副本数设置为0，将new rs的副本数设置为desired数量
[root@master1 ~]#
[root@master1 ~]#kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-595b8954f7 3 3 3 25m
nginx-deploy-6c5ff87cf 0 0 0 9h
nginx-deploy-fd46765d4 0 0 0 9h
[root@master1 ~]#
注意事项
1.某个资源的status字段
注意：某个资源的status字段是系统默认帮我们生成并填充的一些信息；
[root@master1 ~]#kubectl explain deploy
KIND: Deployment
VERSION: apps/v1
DESCRIPTION:
Deployment enables declarative updates for Pods and ReplicaSets.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of the Deployment.
status <Object>
Most recently observed status of the Deployment.
[root@master1 ~]#
2.label之间的关系
label selector （selector）
&
label（pod模板）
# nginx-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
namespace: default
labels: #这个标签仅仅用于标记deployment本身这个资源对象
role: deploy
spec:
replicas: 3 #期望的Pod副本数量
selector: #(1)label selector
matchLabels: #这里也可以是matchExpressions
app: nginx
test: course
template: #Pod模板
metadata:
labels: #(2)这里的label一定要和上面的label selecto的标签保持一致
app: nginx
test: course
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
3.滚动升级的注意事项
阳明大佬：
如果我们强制做一个滚动更新的话，我们的应用如果现在还对外提供服务，那么就有可能正在接收流量，那如果我们做滚动升级的话，那就有可能也会造成业务的请求中断。
那么我们可以用什么样的方式来解决这个"中断"问题呢？
(1)–>就是我们前面所说的
preStaop钩子，就是我们在停止之前，可以做一个什么样的事情呢？比如nginx，可以做一个优雅退出。让它把我们现在的请求处理完成之后，就是不接受请求了，再停止pod。所以，对于我们线上的应用，基本上会加上这里的
优雅退出，在我们的preStop做这样一个事情。或者
(2)你直接在这个preStop里面直接sleep一下，就是让我们这里的请求/连接有足够的时间处理完成。所以，我用个preStop里面直接sleep也是可以的。
4.注意：特别注意下这个revisin，需要实验验证下
注意：默认是保留10个revision的，但是这里经过多次实验现象，只能保留3个，很奇怪
保留旧版本
在很早之前的 Kubernetes 版本中，默认情况下会为我们暴露下所有滚动升级的历史记录，也就是 ReplicaSet 对象，但一般情况下没必要保留所有的版本，毕竟会存在 etcd 中，我们可以通过配置
spec.revisionHistoryLimit属性来设置保留的历史记录数量，不过新版本中该值默认为 10，如果希望多保存几个版本可以设置该字段。
5.特别注意：这2个参数并没有主次之分，有可能先创建新的pod，也有可能先删除老的pod; 并且，他们的配置数量也可以大于1
6.注意：这个kubectl describe deploy nginx-deploy后面的event被被清理的吗？
自己的虚机做了快照之后，第二天这里的event就不见了，rs的event也是一样；
从实验结论看：这里的event会被定期清理的；
7.关于deploy-rs-pod名称
[root@master1 ~]#kubectl get deploy,rs,po
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deploy 3/3 3 3 8h
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deploy-595b8954f7 3 3 3 9m42s
replicaset.apps/nginx-deploy-6c5ff87cf 0 0 0 8h
replicaset.apps/nginx-deploy-fd46765d4 0 0 0 8h
NAME READY STATUS RESTARTS AGE
pod/nginx-deploy-595b8954f7-22w4q 1/1 Running 0 9m41s
pod/nginx-deploy-595b8954f7-ffrqc 1/1 Running 0 9m42s
pod/nginx-deploy-595b8954f7-jgnmw 1/1 Running 0 9m20s
[root@master1 ~]#
[root@master1 ~]#kubectl edit deployments.apps nginx-deploy
[root@master1 ~]#kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-595b8954f7 3 3 3 12m
nginx-deploy-6c5ff87cf 0 0 0 8h
nginx-deploy-fd46765d4 0 0 0 8h
[root@master1 ~]#kubectl edit rs nginx-deploy-595b8954f7
关于我
我的博客主旨：我希望每一个人拿着我的博客都可以做出实验现象，先把实验做出来，然后再结合理论知识更深层次去理解技术点，这样学习起来才有乐趣和动力。并且，我的博客内容步骤是很完整的，也分享源码和实验用到的软件，希望能和大家一起共同进步！
各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人免费帮您解决问题：
-
个人微信二维码：x2675263825 （舍得）， qq：2675263825。
-
个人博客地址：www.onlyonexl.cn
-
个人微信公众号：云原生架构师实战
-
个人csdn
https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421
最后
好了，关于Deployment讲解就到这里了，感谢大家阅读，最后贴上我女神的photo，祝大家生活快乐，每天都过的有意义哦，我们下期见！
1020
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
