replace（/rɪˈpleɪs/）替换、取代；在本文中是修改后的yaml文件替换旧的yaml文件
rollout（/ɑː®/）记录；在本文中是记录历史的deploy副本版本
describe（/dɪˈskraɪb/）描述；在本文中是说记录过程
scale（/skeɪl/）缩放；在本文中是说缩放副本的个数
pause（/pɔːz/）暂停；在本文中是说暂停更新
resume（/rɪˈzjuːm/）恢复；在本文中是说从暂停恢复到正常状态
RC（Replication Controller）和RS（ReplicaSet）
（几乎弃用）RC是复制控制器，确保Pod数量达到期望值，保证副本始终处于可用的状态。
（不建议单独使用）RS是RC的下一代，支持标签集。
无状态服务Deployment意思就是无状态的。。。用于部署无状态的服务。
类似网页访问之类的请求就是无状态的，每次请求都包含了需要的所有信息，每次请求都和上次没有关系。
Deployment是最常用的控制器。一般用于管理维护企业内部的无状态的微服务，比如configserver、zuul、springboot。可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。
deployment的创建
可以通过命令创建一个Deployment：
?
1
kubectl create deployment nginx –image=nginx:1.20.2
可以将创建的副本生成yaml文件：
?
1
kubectl get deployment nginx -o yaml > nginx.yaml
然后可以修改yaml文件的参数，然后重新加载新的yaml文件：
?
1
kubectl replace -f nginx.yaml
也可以通过在线修改yaml文件，退出后直接生效：
?
1
kubectl edit deploy nginx
从yaml文件生成deployment：
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
apiVersion: v1
items:
– apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: “2”
creationTimestamp: “2022-02-08T07:52:05Z”
generation: 2
labels:
app: nginx
name: nginx
namespace: default
resourceVersion: “266395”
uid: d4a3dbe9-5156-42cf-aaf5-3dfefccf4753
spec:
progressDeadlineSeconds: 600
replicas: 1 # 副本数
revisionHistoryLimit: 10 # 保留历史的版本
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: nginx
spec:
containers:
– image: nginx:1.18.0
imagePullPolicy: Always
name: nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
status:
availableReplicas: 1
conditions:
– lastTransitionTime: “2022-02-08T07:52:10Z”
lastUpdateTime: “2022-02-08T07:52:10Z”
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: “True”
type: Available
– lastTransitionTime: “2022-02-08T07:52:05Z”
lastUpdateTime: “2022-02-08T07:55:54Z”
message: ReplicaSet “nginx-86dddd6686” is progressing.
reason: ReplicaSetUpdated
status: “True”
type: Progressing
observedGeneration: 2
readyReplicas: 1
replicas: 2
unavailableReplicas: 1
updatedReplicas: 1
kind: List
metadata:
resourceVersion: “”
selfLink: “”
deployment状态说明：
?
1
2
3
[root@k8s-master01 ~]# kubectl get deployments.apps -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
mynginx 1/1 1 1 4d5h mynginx nginx k8s-app=mynginx
NAME：Deployment名称
READY：Pod的状态，已经达到Ready的个数
UP-TO-DATE：已经达到期望状态的副本数
AVAILABLE：已经可以使用的个数
AGE：程序运行的时间
CONTAINERS：容器的自定义名称
IMAGES：容器镜像名称
SELECTOR：管理的Pod标签
deployment的升级
查看创建nginx的deploy中镜像的版本：可以看到是1.18.0
?
1
2
3
[root@k8s-master01 ~]# kubectl get deploy -o yaml | grep image
– image: nginx:1.18.0
imagePullPolicy: Always
我们可以使用set命令更新镜像的版本：这里的set是设置的意思。
?
1
2
3
4
5
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:1.20.2 –record
[root@k8s-master01 ~]# kubectl get deployments.apps nginx -o yaml | grep image
kubernetes.io/change-cause: kubectl set image deploy nginx nginx=1.18.1 –record=true
– image: nginx:1.20.2
imagePullPolicy: Always
可以使用下列命令查看升级过程：
?
1
2
[root@k8s-master01 ~]# kubectl rollout status deployment nginx
[root@k8s-master01 ~]# kubectl describe deployments.apps nginx
升级过程大概为：创建deploy时，系统也会同时创建depoly的RS，更新deploy时，系统会增加一个新的RS，旧的RS会相应减少1，直到替换完成。
deployment的回滚
deployment的回滚可以回滚到上个版本，也可以回滚到指定指定版本，历史版本的数量由下面这个参数控制：
查看历史版本：可以看到副本发生了几次变化
?
1
2
3
4
5
[root@k8s-master01 ~]# kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
8 kubectl set image deploy nginx nginx=1.18.1 –record=true
9 kubectl set image deploy nginx nginx=nginx:1.20.2 –record=true
回滚到上一个版本：undo是撤销的意思（我的理解是撤销现在的版本回到之前的版本）
?
1
2
[root@k8s-master01 ~]# kubectl rollout undo deployment nginx
deployment.apps/nginx rolled back
查看已经由1.20.2回到了1.18.0版本：
?
1
2
3
4
[root@k8s-master01 ~]# kubectl get deployments.apps nginx -o yaml | grep image
kubernetes.io/change-cause: kubectl set image deploy nginx nginx=1.18.1 –record=true
– image: nginx:1.18.0
imagePullPolicy: Always
如果多次发布，回滚到指定版本：
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[root@k8s-master01 ~]# kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
9 kubectl set image deploy nginx nginx=nginx:1.20.2 –record=true
10 kubectl set image deploy nginx nginx=1.18.1 –record=true
您在 /var/spool/mail/root 中有新邮件
[root@k8s-master01 ~]# kubectl rollout history deployment nginx –revision=9
deployment.apps/nginx with revision #9
Pod Template:
Labels: app=nginx
pod-template-hash=67d5b4548c
Annotations: kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.20.2 –record=true
Containers:
nginx:
Image: nginx:1.20.2
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
[root@k8s-master01 ~]# kubectl rollout undo deployment nginx –to-revision=9
deployment.apps/nginx rolled back
[root@k8s-master01 ~]# kubectl get deployments.apps nginx -o yaml | grep image
kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.20.2
– image: nginx:1.20.2
imagePullPolicy: Always
可以看到以上信息版本已经回滚到1.20.2版本；另外就算更新时候失败，新镜像拉取失败，旧的副本不会停止工作，会一直持续工作，直到升级成功。
deployment的扩容和缩容
使用命令扩容：将nginx副本由一个变成两个，注意扩容RS不会发生变化，因为Pod的本质没有发生改变。scale这个单词在这里是缩放的意思。
?
1
2
3
4
5
6
7
8
[root@k8s-master01 ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 17h
[root@k8s-master01 ~]# kubectl scale –replicas=2 deployment nginx
deployment.apps/nginx scaled
[root@k8s-master01 ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 2/2 2 2 17h
deployment的更新暂停及恢复
更新暂停：这条命令的作用是将更新暂停后，你使用kubectl set命令修改Pod的配置后不会立刻生效，即使多次修改也只是积累起来不会马上生效。
?
1
[root@k8s-master01 ~]# kubectl rollout pause deployment nginx
暂停恢复：解除之前的更新暂停功能，在暂停期间做过的修改将都会生效
?
1
[root@k8s-master01 ~]# kubectl rollout resume deployment nginx
deployment的注意项
.spec.revisionHistoryLimit: 10：设置保留RS的旧的版本的个数，为0的话不保存
.spec.minReadySeconds：可选，指定新创建的Pod在没有任何容器崩溃的情况下是为Ready的最小秒数，默认为0，就是一但创建就被视为可用
滚动更新的策略：就是创建一个新的Pod，然后删除一个旧的Pod，用新的替换旧的。
spec.strategy.type：更新deploy的方式，默认是RollingUpdate
RollingUpdate：滚动更新，可以指定maxSurge和maxUnavailable
maxUnavailable：指定在回滚或更新时最大不可用的Pod数量，默认25%，也可以设置数字；如果为0那么maxSurge就不能为0 。
maxSurge：可以超过期望值的的最大Pod数，可选，默认为25%。如果为0那maxUnavailable就不能为0 。
Recreate：重建，先删除旧的Pod，在创建新的Pod。
以上就是Deployment副本无状态服务及水平扩展的详细内容，更多关于Deployment无状态服务扩展的资料请关注服务器之家其它相关文章！
原文链接：https://yyang.blog.csdn.net/article/details/122818329
声明： 猿站网有关资源均来自网络搜集与网友提供，任何涉及商业盈利目的的均不得使用，否则产生的一切后果将由您自己承担！ 本平台资源仅供个人学习交流、测试使用 所有内容请在下载后24小时内删除，制止非法恶意传播，不对任何下载或转载者造成的危害负任何法律责任！也请大家支持、购置正版！ 。本站一律禁止以任何方式发布或转载任何违法的相关信息访客发现请向站长举报，会员发帖仅代表会员个人观点，并不代表本站赞同其观点和对其真实性负责。本网站的资源部分来源于网络，如有侵权烦请发送邮件至：2697268773@qq.com进行处理。
