本文详细介绍如何使用kubernetes的deployment控制器高效地管理Pod的扩容和滚动更新。了解通过调整deployment配置中的副本数量来实现Pod的扩容和缩容。探索执行滚动更新以平稳过渡到新版本Pod的步骤，并验证过程以确保应用程序的可用性。了解在更新过程中通过RollingUpdateStrategy和maxUnavailable、maxSurge设置的重要性。发现确保Kubernetes集群高可用性和高效部署的最佳实践。
此部分内容是建立在下面这篇内容基础上，有需要的请点击查看
k8s之deployment控制器工作原理、滚动更新原理和编写yaml技巧详解
在上面内容基础之上，开始今天的容器扩容和缩容
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，风险很大
官方文章https://kubernetes.io/zh-cn/docs/tutorials/kubernetes-basics/update/update-intro/
