【CKA考试笔记】八、deployment控制器
文章目录
- 实验环境
- 一、deployment的介绍
- 二、创建deploy及yaml的介绍
- 三、deployment创建的pod的特性
- 四、伸缩deploy的副本数
- 五、HPA
- 六、变更deploy所用的镜像
- 七、滚动更新
实验环境
完成初始化集群的环境：
（vms21）192.168.26.21——master1
（vms22）192.168.26.22——worker1
（vms23）192.168.26.23——worker2
一、deployment的介绍
在实际工作中，其实我们是很少有机会去单独创建一个一个的pod的，很多时候，我们都是通过控制器来自动帮我们创建pod，那么之前学习pod相关知识，主要目的是学习定义pod的模板，从而学会修改控制器里的pod模板，而pod的创建则交给控制器
deployment是一个控制器，控制器里有pod的模板，控制器可以理解为一个机器人，我们作为管理员，需要做的就是告诉这个机器人，我们需要几个pod，机器人就会根据pod的模板创建几个pod，并且会实时监控这些pod，若某个pod挂掉了，那么机器人就会重新去创建这个pod来补齐，来维持环境里一定数量的pod
又如这种情况：有3个worker，worker1、worker2、worker3，每个worker中都有运行一个pod副本，这时候，worker3的网卡出现问题了，deployment检查不到worker3上的pod副本了，此时有效的pod副本数就只有2个了，那么deployment就会在其他worker节点上重新创建一个这个pod，以维持pod副本数，过了一会，worker3恢复了，这时环境中这个pod的副本数有4了，那么deployment此时也会删除一个pod，以确保环境中pod的副本数为3个
二、创建deploy及yaml的介绍
通过命令行生成yaml模板
kubectl create deploy [deploy名] --image=[镜像名] --dry-run=client -o yaml > xxx.yaml
例：
kubectl create deploy web1 --image=nginx --dry-run=client -o yaml > web1.yamlvim web1.yaml
yaml的结构如下：
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: web1name: web1
spec:replicas: 1selector:matchLabels:app: web1strategy: {}template:metadata:creationTimestamp: nulllabels:app: web1spec:containers:- image: nginxname: c1resources: {}
status: {}
spec.template——定义pod的模板
spec.template.spec.containers——定义pod中容器的属性
spec.selector.matchLabels（deployment属性下定义的选择器匹配的标签）与spec.template.metadata.labels（pod模板中定义的pod标签）——这两个标签要匹配，因为deployment会监控pod，而deployment就是根据这个标签的匹配来知道要监控哪些pod，pod模板中可以定义多个pod标签，而deployment选择器中的标签只要满足pod标签中的其中一个就可以匹配上，若不匹配，则会出问题，就等于deployment一创建了这些个pod，这些pod就不归deployment管理了
spec.replicas定义创建的pod副本数
修改这个yaml，将pod的宽限期设置为0，镜像的下载策略设为IfNotPresent，pod的副本数设为2
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: web1name: web1
spec:replicas: 2selector:matchLabels:app: web1strategy: {}template:metadata:creationTimestamp: nulllabels:app: web1spec:terminationGracePeriodSeconds: 0containers:- image: nginxname: c1imagePullPolicy: IfNotPresentresources: {}
status: {}
创建这个deployment
kubectl apply -f web1.yaml
查看pod，可以看到两个pod创建出来了
kubectl get pods -owide#输出：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web1-667b8f7dd8-cf6l8 1/1 Running 0 70s 10.244.70.94 vms23.rhce.cc <none> <none>
web1-667b8f7dd8-jmxwb 1/1 Running 0 70s 10.244.70.95 vms23.rhce.cc <none> <none>
查看deployment
kubectl get deploy -owide#输出：
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
web1 2/2 2 2 7s c1 nginx app=web1
测试删除某个pod，我们删除web1-667b8f7dd8-jmxwb这个pod
kubectl delete pod web1-667b8f7dd8-jmxwb
再次查看pod，可以看到，pod又被重新创建出来了（名字变了），维持为2个数量的pod副本
kubectl get pods
#输出：
NAME READY STATUS RESTARTS AGE
web1-667b8f7dd8-cf6l8 1/1 Running 0 10m
web1-667b8f7dd8-m9x4g 1/1 Running 0 6s
同理，对某个节点进行drain操作（驱逐节点内的pod），驱逐后，deployment也会在其他节点上重新创建pod
如这里两个pod都是运行在vms23上，我们对vms23进行drain操作
kubectl drain vms23.rhce.cc --ignore-daemonsets
再次查看pod，可以看到这两个pod被重新创建在了vms22上
kubectl get pods -owide#输出：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web1-667b8f7dd8-c9wkq 1/1 Running 0 114s 10.244.7.2 vms22.rhce.cc <none> <none>
web1-667b8f7dd8-fxp8b 1/1 Running 0 2s 10.244.7.3 vms22.rhce.cc <none> <none>
恢复vms23节点就绪状态
kubectl uncordon vms23.rhce.cc
所以，除非删除这个deployment，否则这些pod无法关闭
删除deployment语法：kubectl delete deploy [deployment名]
根据以上例子，现假设我们自己单独创建一个pod，标签也设置为app=web1，那么这个deployment会不会接管这个pod呢？
——不会，因为deployment除了标签来匹配外，在创建pod时，还会给每个pod设置一个哈希值
我们查看pod，可以看到deployment创建的pod的标签里，除了yaml文件里定义的标签外，还有一个哈希值pod-template-hash
kubectl get pods --show-labels#输出：
NAME READY STATUS RESTARTS AGE LABELS
web1-667b8f7dd8-cf6l8 1/1 Running 0 7m11s app=web1,pod-template-hash=667b8f7dd8
web1-667b8f7dd8-jmxwb 1/1 Running 0 7m11s app=web1,pod-template-hash=667b8f7dd8
三、deployment创建的pod的特性
deployment部署的pod，是无状态的pod
stateless（无状态）：
（1）所有pod的特性没有任何不同
（2）pod的名字随机生成
（3）不存储数据
（4）即使存储数据，那么所有的pod也是共享数据
（5）健壮性，除非删除deployment，否则pod无法被关闭，pod被删除了也会被重新创建出来以补齐数量
四、伸缩deploy的副本数
修改副本数
deploy的在线修改不同于pod的在线修改，pod在线修改时很多属性都不能修改，而deploy可以，因为本质上修改deploy后，deploy会删除pod，然后重新创建pod
方式一：通过命令行直接在线修改
执行完后便会立即生效
kubectl scale deployment [deploy名] --replicas=[pod副本数量]
scale（伸缩）
伸缩副本数的通用语法
kubectl scale [控制器类型] [控制器名字] --replicas=[pod副本数量]
例：
将前面创建的web1这个deployment的副本数改为10个
#例：
kubectl scale deploy web1 --replicas=10
查看pod
kubectl get pods -owide#输出：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web1-667b8f7dd8-5ltmt 1/1 Running 0 4s 10.244.70.69 vms23.rhce.cc <none> <none>
web1-667b8f7dd8-6qbhg 1/1 Running 0 4s 10.244.7.6 vms22.rhce.cc <none> <none>
web1-667b8f7dd8-7fv7v 1/1 Running 0 4s 10.244.70.66 vms23.rhce.cc <none> <none>
web1-667b8f7dd8-9hgf6 1/1 Running 0 4s 10.244.70.67 vms23.rhce.cc <none> <none>
web1-667b8f7dd8-b54zv 1/1 Running 0 4s 10.244.70.70 vms23.rhce.cc <none> <none>
web1-667b8f7dd8-c9wkq 1/1 Running 0 153m 10.244.7.2 vms22.rhce.cc <none> <none>
web1-667b8f7dd8-fxp8b 1/1 Running 0 151m 10.244.7.3 vms22.rhce.cc <none> <none>
web1-667b8f7dd8-h7xll 1/1 Running 0 4s 10.244.70.68 vms23.rhce.cc <none> <none>
web1-667b8f7dd8-l8s7d 1/1 Running 0 4s 10.244.7.5 vms22.rhce.cc <none> <none>
web1-667b8f7dd8-pg5xm 1/1 Running 0 4s 10.244.7.4 vms22.rhce.cc <none> <none>
方式二：通过edit在线修改配置
保存配置后立即生效
kubectl edit deployment nginx
例：
修改副本数属性 replicas 为8
kubectl edit deployment web1#配置文件内容：
apiVersion: apps/v1
kind: Deployment
metadata:annotations:deployment.kubernetes.io/revision: "1"kubectl.kubernetes.io/last-applied-configuration: |creationTimestamp: "2022-07-06T09:49:13Z"generation: 3labels:app: web1name: web1namespace: defaultresourceVersion: "14417"uid: 49ae5810-8c2a-4df2-8b9b-64247a8a1794
spec:progressDeadlineSeconds: 600replicas: 8revisionHistoryLimit: 10selector:matchLabels:app: web1strategy:rollingUpdate:maxSurge: 25%maxUnavailable: 25%type: RollingUpdatetemplate:metadata:creationTimestamp: nulllabels:app: web1spec:containers:- image: nginximagePullPolicy: IfNotPresentname: c1resources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: AlwaysschedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 0
status:availableReplicas: 8conditions:- lastTransitionTime: "2022-07-06T09:49:13Z"lastUpdateTime: "2022-07-06T09:49:43Z"message: ReplicaSet "web1-667b8f7dd8" has successfully progressed.reason: NewReplicaSetAvailablestatus: "True"type: Progressing- lastTransitionTime: "2022-07-06T12:22:18Z"lastUpdateTime: "2022-07-06T12:22:18Z"message: Deployment has minimum availability.reason: MinimumReplicasAvailablestatus: "True"type: AvailableobservedGeneration: 3readyReplicas: 8replicas: 8updatedReplicas: 8
方式三：修改yaml文件，然后重新创建deployment
修改好后，删除deploy，重新kubectl apply -f xxx.yaml
以上的方式都属于手动修改pod副本数，那么是否可以自动修改呢？
——这就是HPA的内容
五、HPA
HPA（horizontal pod autoscalers）水平自动伸缩
通过监测pod CPU的负载，解决deployment里某pod负载太重，动态伸缩pod的副本数来达到负载均衡
一个pod就能工作了，为什么要有那么多的pod副本数？
如下图，若只有一个pod，那么svc接收用户请求后，将请求都转发给这个pod，若某个时候并发量特别大，10000个请求同时转发给pod，那么这个pod所在的节点的负载就很高
因此创建多个pod副本，运行在不同的节点上，当并发量很大的时候，就可以将请求分发到各个节点上的pod，以达到负载均衡
在k8s之前，我们若要去实现负载均衡，如下图：
我们需要手动去配置如haproxy、lvs来搭建负载均衡，在所有的服务器上搭建应用，并同步应用的配置文件，然后再配置一个后端存储，从而实现流量分流
有了容器之后，带来的最大的优点就是，实现了应用程序和服务器之间的解耦
现在我们在k8s环境中，假设某电商平台，平时并发量不大，因此pod的副本数并不是很多，到了双十一等节日，并发量就特别大了，需要管理员手动伸缩pod副本数，但是管理员因某些事情耽搁了，没有去手动伸缩副本数，那么此时的pod的负载就很重
——因此，手动伸缩副本的始终是不太靠谱，我们使用HPA水平自动伸缩
HPA会去实时监控最初始的这个pod，一旦这个pod负载很重了，超过了一定的阈值，它就会去通知deployment控制器，让控制器去扩展该pod的副本数，对于扩展出来的这些pod，负载情况也会被HPA监控，到了后期，若监控到这些pod的负载都变得很低了，也就不需要那么多的pod了，HPA就会通知deployment去收缩pod副本数
HPA可以监测CPU、内存、IPO（并发量）等，默认监测的是CPU的负载
HPA需要定义一个阈值，超过了这个阈值，则认为资源消耗太高
查看节点负载、pod负载（确保环境里安装了metric server）
#节点负载
kubectl top nodes
#输出：
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
vms21.rhce.cc 96m 4% 1312Mi 34%
vms22.rhce.cc 46m 2% 685Mi 17%
vms23.rhce.cc 44m 2% 675Mi 17% #pod负载
kubectl top pods
#输出：
NAME CPU(cores) MEMORY(bytes)
web1-667b8f7dd8-5ltmt 0m 1Mi
web1-667b8f7dd8-6qbhg 0m 1Mi
web1-667b8f7dd8-7fv7v 0m 1Mi
web1-667b8f7dd8-9hgf6 0m 4Mi
web1-667b8f7dd8-c9wkq 0m 1Mi
web1-667b8f7dd8-fxp8b 0m 1Mi
web1-667b8f7dd8-h7xll 0m 1Mi
web1-667b8f7dd8-l8s7d 0m 4Mi
现在我们删除之前例子中的web1这个deployment，然后编辑web1.yaml
修改副本数replicas为1，pod的资源需求resources.requests为cpu400m
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: web1name: web1
spec:replicas: 1selector:matchLabels:app: web1strategy: {}template:metadata:creationTimestamp: nulllabels:app: web1spec:terminationGracePeriodSeconds: 0containers:- image: nginxname: c1imagePullPolicy: IfNotPresentresources:requests:cpu: 400m
status: {}
然后重新创建这个deployment
kubectl apply -f web1.yaml
创建好后，可以看到创建了一个pod，运行在vms23上
kubectl get pods -owide#输出：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web1-7546d6f86f-fmhlc 1/1 Running 0 13s 10.244.70.78 vms23.rhce.cc <none> <none>
创建HPA
kubectl autoscale deployment [deploy名字] --min [最小副本数] --max [最大副本数] --cpu-percent [cpu阈值百分比]
–cpu-percent定义的值为80，则表示cpu的阈值为80%，注意，这里的cpu指的是定义pod的属性里对资源需求resources.requests中定义的cpu大小，如web1这个例子中就是400m的80%，即320m，cpu负载超过了320m这个阈值，就会扩展pod副本
例：
我们对web1这个deployment创建一个HPA，最小副本数为1，最大副本数为5，cpu阈值为80%
kubectl autoscale deployment web1 --min 1 --max 5 --cpu-percent 80
查看HPA
kubectl get hpa
我们可以看到刚刚创建的web1的这个hpa，TARGETS中的数值即当前资源占用率及资源阈值
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web1 Deployment/web1 0%/80% 1 5 1 2m25s
实验：
在当前环境中，我们在master上创建一个web1的svc，然后模拟对svc发送大量请求，由于web1这个deployment中目前只有一个pod，因此大量请求都会转发到这个pod上，使得pod负载量剧增，目的是来测试HAP的动态伸缩功能
（1）master创建一个web1的svc，端口设置为80
kubectl expose --name=svc1 deploy web1 --port=80
（2）查看svc，查看IP地址
kubectl get svc
#输出：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc1 ClusterIP 10.108.212.227 <none> 80/TCP 5s
（3）master上安装一个apach的压测工具
yum install httpd-tools -y
（4）打开一个新的控制台，进行压力测试，模拟发送100万个请求
# -n 在测试回话中所执行的请求个数，默认为仅执行一个请求
# -c 一次产生的请求个数，默认是一次一个
# -t 测试所进行的最大秒数
ab -t 600 -n 1000000 -c 1000 http://10.108.212.227/index.html
（5）执行发送请求后，在请求发送的过程中，我们可以观察pod的负载情况、hpa的情况、pod副本数量的变化
#发送请求后过了一会：
kubectl top pods
#输出：
NAME CPU(cores) MEMORY(bytes)
web1-7546d6f86f-fmhlc 911m 2Mi kubectl get hpa
#输出：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web1 Deployment/web1 227%/80% 1 5 4 3m26skubectl get pods
#输出：
NAME READY STATUS RESTARTS AGE
web1-7546d6f86f-68m4q 1/1 Running 0 24s
web1-7546d6f86f-dlpb2 1/1 Running 0 24s
web1-7546d6f86f-fmhlc 1/1 Running 0 4m32s
web1-7546d6f86f-tw5qq 1/1 Running 0 9s#又过了一会：
kubectl top pods
#输出：
NAME CPU(cores) MEMORY(bytes)
web1-7546d6f86f-68m4q 221m 2Mi
web1-7546d6f86f-dlpb2 139m 2Mi
web1-7546d6f86f-fmhlc 199m 2Mi
web1-7546d6f86f-tcll8 235m 2Mi
web1-7546d6f86f-tw5qq 174m 2Mi kubectl get hpa
#输出：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web1 Deployment/web1 76%/80% 1 5 5 5m12skubectl get pods
#输出：
NAME READY STATUS RESTARTS AGE
web1-7546d6f86f-68m4q 1/1 Running 0 2m34s
web1-7546d6f86f-dlpb2 1/1 Running 0 2m34s
web1-7546d6f86f-fmhlc 1/1 Running 0 6m42s
web1-7546d6f86f-tcll8 1/1 Running 0 78s
web1-7546d6f86f-tw5qq 1/1 Running 0 2m19s
可以看到随着请求量剧增、pod的负载超出阈值，自动帮我们扩展了pod副本数，变成了5个（创建HPA时定义的最大副本数为5）
压测停止后，随着请求量变少，pod的负载变小至0，但是此时，并不会立即去收缩副本数，它会有一个期限，这个期限默认是5分钟（为了防止请求量突然又变大）
5分钟后，pod负载一直没有升高，就自动帮我们收缩了pod副本数，又变回了一个（创建HPA时定义的最小副本数为1）
kubectl top pods
#输出：
NAME CPU(cores) MEMORY(bytes)
web1-7546d6f86f-fmhlc 0m 2Mi kubectl get hpa
#输出：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
web1 Deployment/web1 0%/80% 1 5 1 14mkubectl get pods
#输出：
NAME READY STATUS RESTARTS AGE
web1-7546d6f86f-fmhlc 1/1 Running 0 16m
注：使用metrics-server并不是实时地去监测，而是每隔15秒监测一次
可以在metrics-server的配置文件components.yaml中配置这个间隔时间（–metric-resolution=15s）
...
apiVersion: apps/v1
kind: Deployment
metadata:labels:k8s-app: metrics-servername: metrics-servernamespace: kube-system
spec:selector:matchLabels:k8s-app: metrics-serverstrategy:rollingUpdate:maxUnavailable: 0template:metadata:labels:k8s-app: metrics-serverspec:containers:- args:- --cert-dir=/tmp- --secure-port=4443- --kubelet-insecure-tls- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname- --kubelet-use-node-status-port- --metric-resolution=15simage: k8s.gcr.io/metrics-server/metrics-server:v0.6.1imagePullPolicy: IfNotPresent
...
六、变更deploy所用的镜像
在有容器之前，我们在多个服务器上部署一个应用，若这个应用要升级，那么我们就需要在每个服务器上都将应用升级
现在有了容器，我们只需要将新的应用打包为镜像，然后在depolyment里pod模板中应用新的镜像即可
变更镜像通用语法
kubectl set image [控制器类型] [控制器名] [pod内容器名]=[新镜像名]# --record 增加变更时的记录，这样查看变更记录时可以看到镜像变更的详情
kubectl set image [控制器类型] [控制器名] [pod内容器名]=[新镜像名] --record
查看镜像变更记录通用语法
kubectl rollout history [控制器类型] [控制器名]
回滚镜像版本为上一个镜像版本
kubectl rollout undo [控制器类型] [控制器名]
将镜像版本切换到变更记录中的某个版本
kubectl rollout undo [控制器类型] [控制器名] --to-revision [变更编号]
实验：
在web1这个deploy中，应用的镜像为nginx，我们现在将镜像替换为nginx:1.7.9
kubectl get deploy -o wide
#输出：
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
web1 1/1 1 1 54m c1 nginx app=web1
（1）在所有worker节点上拉取nginx:1.7.9
nerdctl pull nginx:1.7.9
（2）将web1的副本数扩展为5个
kubectl scale deploy web1 --replicas 5kubectl get deploy -o wide
#输出：
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
web1 5/5 5 5 60m c1 nginx app=web1
（3）替换web1控制的pod内容器的镜像为nginx:1.7.9
kubectl set image deploy web1 c1=nginx:1.7.9
（4）查看pod，可以看到，deplo会先重新创建镜像为nginx:1.7.9的pod，然后将原先的pod删除（AGE为4、5s）
kubectl get pods
#输出：
NAME READY STATUS RESTARTS AGE
web1-5d4dff97f8-bgjvp 1/1 Running 0 4s
web1-5d4dff97f8-cxwc9 1/1 Running 0 5s
web1-5d4dff97f8-d8psx 1/1 Running 0 5s
web1-5d4dff97f8-w7x46 1/1 Running 0 5s
web1-5d4dff97f8-z2bz8 1/1 Running 0 5skubectl get deploy -o wide
#输出：
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
web1 5/5 5 5 71m c1 nginx:1.7.9 app=web1
（5）查看变更记录
kubectl rollout history deploy web1#输出：
REVISION CHANGE-CAUSE
5 <none>
6 <none>
但是这样并看不出来什么信息，因此我们在变更镜像时可以加上–record
我们将镜像变回nginx，再变为nginx:1.7.9，加上–record
kubectl set image deploy web1 c1=nginx --record
kubectl set image deploy web1 c1=nginx:1.7.9 --recordkubectl rollout history deploy web1
#输出：
REVISION CHANGE-CAUSE
7 kubectl set image deploy web1 c1=nginx --record=true
8 kubectl set image deploy web1 c1=nginx:1.7.9 --record=true
（6）将镜像回滚为上一个版本
kubectl rollout undo deploy web1kubectl rollout history deploy web1
#输出：
REVISION CHANGE-CAUSE
8 kubectl set image deploy web1 c1=nginx:1.7.9 --record=true
9 kubectl set image deploy web1 c1=nginx --record=true
（7）将镜像版本切换为变更记录中变更编号为8的这个镜像版本
kubectl rollout undo deploy web1 --to-revision 8kubectl rollout history deploy web1
#输出：
REVISION CHANGE-CAUSE
9 kubectl set image deploy web1 c1=nginx --record=true
10 kubectl set image deploy web1 c1=nginx:1.7.9 --record=true
但是这样有个问题：
假设此时有5个pod副本，运行在不同的节点上，现在要更新所有pod，它会先以新镜像创建pod，然后删除原来旧的的pod
那么它是否会将这5个pod全部都一次性更新了呢？——不会，因为若全部一起更新，那么这段时间就无法对外提供服务了
因此，就需要滚动更新
七、滚动更新
滚动更新：更新多个pod副本时，不一次性全部更新，而是比如先更新5个pod，更新好了再更新5个pod…这样分批次地更新
实验：
（继续使用web1这个deployment演示）
为了便于实验，我们编辑web1的配置，将pod的宽限期设置为10秒，并将容器启动后的主进程改为修改1天
将pod的副本数改为5个
kubectl edit deploy web1
修改如下：
replicas: 5
command: [“sh”,“-c”,“sleep 1d”]
terminationGracePeriodSeconds: 10
...
spec:progressDeadlineSeconds: 600replicas: 5
...
template:metadata:creationTimestamp: nulllabels:app: web1spec:containers:- image: nginxcommand: ["sh","-c","sleep 1d"]imagePullPolicy: IfNotPresentname: c1resources:requests:cpu: 400mterminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: AlwaysschedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 10
...
修改好后，现在我们来看deploy配置中涉及到滚动更新的配置项spec.strategy.rollingUpdate
...
spec:progressDeadlineSeconds: 600replicas: 5revisionHistoryLimit: 10selector:matchLabels:app: web1strategy:rollingUpdate:maxSurge: 25%maxUnavailable: 25%type: RollingUpdatetemplate:
...
在编辑deployment的yaml文件时，strategy若不写（strategy: {}），则会设置为默认值：maxSurge 为25%，maxUnavailable 为25%
maxSurge: 25%——表示更新pod时，一次性最多更新的pod数为总副本数的25%，若设为100%，则一次性更新全部
maxUnavailable: 25%——表示更新pod时，一次性最多删除的旧的pod数为总副本数的25%，若设为100%，则一次性删除全部
值也可以是具体的pod个数，如：
maxSurge: 1
maxUnavailable: 1
现在我们kubectl edit deploy web1将maxSurge、maxUnavailable都设置为1，进行实验
保存退出后，进行切换镜像kubectl set image deploy web1 c1=nginx:1.7.9 --record
在更新的过程中，我们可以kubectl get pods来观察pod的STATUS
NAME READY STATUS RESTARTS AGE
web1-656bdfd78b-27qdb 1/1 Running 0 63s
web1-656bdfd78b-5gzbt 1/1 Terminating 0 21s
web1-656bdfd78b-5sxq7 1/1 Running 0 21s
web1-656bdfd78b-flh7t 1/1 Terminating 0 21s
web1-656bdfd78b-z7tfc 1/1 Running 0 21s
web1-657d4c485-fsf6z 0/1 Pending 0 0s
web1-657d4c485-lsbkj 0/1 ContainerCreating 0 1s
web1-657d4c485-qr6rp 1/1 Running 0 1sNAME READY STATUS RESTARTS AGE
web1-656bdfd78b-27qdb 1/1 Terminating 0 70s
web1-656bdfd78b-5gzbt 1/1 Terminating 0 28s
web1-656bdfd78b-5sxq7 1/1 Terminating 0 28s
web1-656bdfd78b-flh7t 1/1 Terminating 0 28s
web1-656bdfd78b-z7tfc 1/1 Running 0 28s
web1-657d4c485-4stm2 0/1 Pending 0 7s
web1-657d4c485-94t8x 0/1 Pending 0 6s
web1-657d4c485-fsf6z 1/1 Running 0 7s
web1-657d4c485-lsbkj 1/1 Running 0 8s
web1-657d4c485-qr6rp 1/1 Running 0 8sNAME READY STATUS RESTARTS AGE
web1-656bdfd78b-27qdb 0/1 Terminating 0 75s
web1-656bdfd78b-z7tfc 1/1 Terminating 0 33s
web1-657d4c485-4stm2 1/1 Running 0 12s
web1-657d4c485-94t8x 0/1 ContainerCreating 0 11s
web1-657d4c485-fsf6z 1/1 Running 0 12s
web1-657d4c485-lsbkj 1/1 Running 0 13s
web1-657d4c485-qr6rp 1/1 Running 0 13sNAME READY STATUS RESTARTS AGE
web1-656bdfd78b-z7tfc 1/1 Terminating 0 39s
web1-657d4c485-4stm2 1/1 Running 0 18s
web1-657d4c485-94t8x 1/1 Running 0 17s
web1-657d4c485-fsf6z 1/1 Running 0 18s
web1-657d4c485-lsbkj 1/1 Running 0 19s
web1-657d4c485-qr6rp 1/1 Running 0 19sNAME READY STATUS RESTARTS AGE
web1-657d4c485-4stm2 1/1 Running 0 22s
web1-657d4c485-94t8x 1/1 Running 0 21s
web1-657d4c485-fsf6z 1/1 Running 0 22s
web1-657d4c485-lsbkj 1/1 Running 0 23s
web1-657d4c485-qr6rp 1/1 Running 0 23s
若滚动更新过程中出现了问题，可以暂停更新
kubectl rollout pause deploy [deploy名]
【CKA考试笔记】八、deployment控制器相关推荐
- Kubernetes 管理员认证(CKA)考试笔记(一)
写在前面 嗯,准备考 cka证书,博客是听课后整理的笔记,适合温习. 博文内容涉及 docker ,k8s: 写的有点多了,因为粘贴了代码,所以只能分开发布 本部分内容涉及docker相关复习,k8s ...
- Kubernetes 管理员认证(CKA)考试笔记(四)
写在前面 嗯,准备考 cka证书,博客是听课后整理的笔记,适合温习. 博客内容涉及: Helm的基本概念及安装,Helm源配置 chart包的安装部署 私有Helm源的搭建及chart包的push和p ...
- 【CKA考试笔记】十五、安全管理：验证与授权
文章目录 实验环境 一.验证 概述 token 认证方式 kubeconfig 认证方式 oauth2 认证方式 二.授权(鉴权) 三.k8s中的权限.角色.用户 查看角色 查看集群角色 查看角色有哪 ...
- CKA考试笔记，仅做个人学习使用
1. RBAC #创建角色 kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployment, ...
- 【CKA考试笔记】三、kubernetes集群管理
文章目录 实验环境 一.查看集群配置信息 二.查看各节点所使用的runtime是什么 三.集群缩容 四.集群扩容 五.恢复出厂设置reset.重新初始化集群 实验:删除集群中所有节点,并重新初始化集群 ...
- 【CKA考试笔记】十三、k8s中的网络
文章目录 实验环境 一.calico通信的过程 ipip模式: bgp模式 实验:在非k8s环境里,准备两台机器,通过calico实现容器跨主机通信 二.网络策略 创建网络策略 查看网络策略 实验:流 ...
- 【CKA考试笔记】二十、升级k8s
文章目录 实验环境 一.概述 二.实验 一:更新master (1)更新kubeadm工具 (2)更新kubelet.kubectl (3)重启kubelet (4)恢复此节点 (5)若有多个mast ...
- 计算机考试高网络技术,全国计算机等级考试三级笔记八(网络技术展望)
第八章 网络技术展望 人们每次发送的报文分为较小的数据块,既报文分组,每个报文分组单独传送,达到目的地后再重新组装成报文,这就是分组交换技术. 信元交换技术是一种快速分组交换技术,它结合了电路交换技术 ...
- k8s学习-CKA考试必过宝典
目录 CKA考纲 集群架构,安装和配置:25% 工作负载和调度:15% 服务和网络:20% 存储:10% 故障排除:30% 报名(中国网站) 黑色星期五 预约流程(国外网站) 注册账号 注册考试(购买 ...
最新文章
- vt Hypervisor Framework
- 关于IP、子网掩码、网关、和DNS相关理解
- linux solusos 软件包管理工具 eopkg 简介
- Java基础学习网站收藏
- 洛谷 P1309 瑞士轮 解题报告
- 和硕看重物联网大势 程建中：从擅长领域出发
- 【转】3.3(译)构建Async同步基元，Part 3 AsyncCountdownEvent
- 如何使用COMPUTER VISION将LEPRECHAUN-HATS放入您的网站
- （一）flask-sqlalchemy的安装和配置
- Golang 项目布局浅析
- （转）Arcgis for JS之对象捕捉
- 当FORM的ENCTYPE=quot;multipart/form-dataquot; 时request.getParameter()获取不到
- 收购小蓝单车部分资产、与ofo蜜月期结束，滴滴重构共享单车布局
- AI技术宅：女神说什么，听我的！
- 利用Dockerfile构建一个nginx容器
- s2sh框架搭建mysql_S2SH项目框架搭建（完全注解）
- python判断字符串包含中文_查询字符串中是否包含中文字符（Python实现）
- 泊松分布的特征与应用（概统2.应用）
- python等比例压缩图片_python使用pil进行图像处理(等比例压缩、裁剪)实例代码
- matlab实现幂法迭代求特征值和特征向量