本文详细介绍如何使用kubernetes的deployment控制器高效地管理Pod的扩容和滚动更新。了解通过调整deployment配置中的副本数量来实现Pod的扩容和缩容。探索执行滚动更新以平稳过渡到新版本Pod的步骤，并验证过程以确保应用程序的可用性。了解在更新过程中通过RollingUpdateStrategy和maxUnavailable、maxSurge设置的重要性。发现确保Kubernetes集群高可用性和高效部署的最佳实践。
此部分内容是建立在下面这篇内容基础上，有需要的请点击查看
在上面内容基础之上，开始今天的容器扩容和缩容
deployment可以简写成deploy,后续内容使用deploy
创建pod
apiVersion: apps/v1 kind: Deployment metadata: name: myapp-v1 spec: replicas: 3 #pod副本数 selector: matchLabels: # matchLabels下定义的标签需要跟template.metadata.labels定义的标签一致 app: myapp version: v1 template: metadata: labels: app: myapp version: v1 spec: #定义容器的属性 containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 startupProbe: #容器启动探测 initialDelaySeconds: 6 periodSeconds: 10 timeoutSeconds: 10 failureThreshold: 3 httpGet: port: 80 path: / scheme: HTTP livenessProbe: #容器存活探测 initialDelaySeconds: 6 periodSeconds: 10 timeoutSeconds: 10 failureThreshold: 3 httpGet: port: 80 path: / scheme: HTTP readinessProbe: #容器就绪探测 initialDelaySeconds: 6 periodSeconds: 10 timeoutSeconds: 10 failureThreshold: 3 httpGet: port: 80 path: / scheme: HTTP
Deploy扩容
通过修改 Deployment 的 spec.replicas 字段来指定期望的副本数
查看当前deploy控制器创建的pod详细信息
kubectl get deploy
kubectl describe deploy myapp-v1
修改replicas(副本)数量
将deploy-demo.yaml副本数由3改成5 spec: replicas: 5 修改之后保存退出，执行
kubectl apply更新
注意：apply不同于create，apply可以执行多次；create执行一次，再执行就会报错复。
kubectl apply -f deploy-demo.yaml
再次查看deploy
Deploy缩容
同样地，通过修改 Deployment 的 spec.replicas 字段来指定期望的副本数
将deploy-demo.yaml副本数由5改成3 spec: replicas: 3 #修改之后保存退出，执行 kubectl apply -f deploy-demo.yaml
查看deploy控制器
滚动更新
滚动更新简介
滚动更新是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式，一次滚动发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义），例如第一批1台，第二批10%，第三批50%，第四批100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的
查看控制器策略
deploy更新方式：
支持两种更新，Recreate和RollingUpdate
- Recreate是重建式更新，删除一个更新一个
- RollingUpdate 滚动更新，定义滚动更新的更新方式的，也就是pod能多几个，少几个，控制更新力度的
RollingUpdate
查看滚动更新帮助文档
maxSurge（最大扩展的值）和maxUnavailable（最大不可用）用来控制滚动更新的策略
取值范围分为数值和百分比
1、先来看百分比
maxUnavailable: [0%, 100%] 向下取整，比如10个副本，5%的话==0.5个，但计算按照0个
maxSurge: [0%, 100%] 向上取整，比如10个副本，5%的话==0.5个，但计算按照1个
注意：两者不能同时为0
建议配置
maxUnavailable == 0
maxSurge == 1
这是我们生产环境提供给用户的默认配置。即“一上一下，先上后下”最平滑原则：
一个新版本pod ready（就绪readiness）后，才销毁旧版本pod。此配置适用场景是平滑更新、保证服务平稳，但也有缺点，就是“太慢”了。
2、再来看数值
maxUnavailable: [0, 副本数]
maxSurge: [0, 副本数]
注意：两者不能同时为0。
测试滚动更新
默认滚动更新策略是RollingUpdateStrategy: 25% max unavailable, 25% max surge
3*25%=0.75 —> maxSurge向上取整则为1，先增加一个pod;
3*25%=0.75 —> max unavailable向下取整为0，即先不删除pod
接下来验证这个
把image: nginx变成image: nginx:1.14.2 保存退出，执行 kubectl apply -f deploy-demo.yaml
另一个窗口监控
kubectl get pods -w #查看pod更新过程
pod更新过程过程说明
执行apply之后，先调度创建一个新pod，经过启动，存活，就绪三次探测，pod正常运行之后，停掉一个旧的pod，同时开始创建第二个新pod，一次类推，直到最后一个pod创建成功，并删除最后一个旧pod
总结：
maxUnavailable：和期望的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；
maxSurge：和期望的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。
自定义滚动更新策略
#修改更新策略：maxUnavailable=1，maxSurge=1 kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}' #查看myapp-v1这个控制器的详细信息 kubectl describe deployment myapp-v1 显示如下： RollingUpdateStrategy: 1 max unavailable, 1 max surge #上面可以看到RollingUpdateStrategy: 1 max unavailable, 1 max surge #这个rollingUpdate更新策略变成了刚才设定的，因为我们设定的pod副本数是3，1和1表示最少不能少于2个pod，最多不能超过4个pod #这个就是通过控制RollingUpdateStrategy这个字段来设置滚动更新策略的 Recreate
把pod更新策略变成Recreate
apiVersion: apps/v1 kind: Deployment metadata: name: myapp-v1 spec: replicas: 3 strategy: type: Recreate ...
kubectl apply -f deploy-demo1.yaml #另一个窗口实时监控 kubectl get pods -w
总结：recreate这种更新策略，会把之前的所有pod都删除，再创建新的pod，风险很大
官方文章