kubernetes deployment控制器可以保证在升级时只有一定数量的pod是down的。默认的，它会确保至少有比期望的pod数量少一个是up状态（最多一个不可用）。
deployment控制器同时可以确保只创建出超过期望阈值的一定数量的pod。默认的，它会确保最多比期望的pod数量多一个的pod是up的（最多一个surge）
在未来的kubernetes版本中，将从1-1到25%-25%。
在kubernetes最新版v1.29.2中，默认值已经变成25%和25% 。
查看当前kubernetes deployment的更新策略：
kubectl get deployment -n $namespace_name -o yaml
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
这个版本确认改变的版本是v1.16。
通过apps/v1接口组创建的deployment控制器都是25%和25%，这个默认值。如果通过extensions/v1beta1版的接口创建的，都是1和1。
查看deployment的自动更新策略：
kubectl explain deploy.spec.strategy.type
类型分成：Recreate重建和RollingUpdate滚动更新
Recreate就是重新创建，删除掉旧的创建新的。
RollingUpdate滚动更新，就是逐个或者逐步去更新配置。
为了确保客户对应用可以持续性访问，应该使用滚动更新的方式进行升级。
RollingUpdate滚动更新的参数：
①：maxSurge: 指定超出副本数有几个，两种方式：1.指定数量2.指定百分比，比如默认值是25% 。
②：maxUnavailable: 最多有几个不可用
在不同的版本切换的时候，为了增加用户的体验性，一定要保证用户是可以访问业务的，最好使用滚动更新的方式。
金丝雀发布：
金丝雀部署的名字灵感来源于17世纪英国矿井工人使用金丝雀作为瓦斯检测指标的传统方法。金丝雀对瓦斯这种气体十分敏感，空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱。而当瓦斯含量超过一定的限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。在采矿设备相对简陋的条件下，工人们每次下矿井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
金丝雀部署的核心思想是在实际运行环境中的一小部分用户或者流量上测试新版本的软件，而大部分用户或者流量仍然使用旧版本。通过对新版本进行有限范围的实时测试和监控，可以及早发现潜在问题，并减少对整个系统的冲击。
用较小的代价，可以探测出来当前的危险。这就是金丝雀部署的理念。
金丝雀部署：
假如创建一个 deployment控制器，它会先创建一个replicaset RS的控制器。接着replicaset RS控制器会按照定义的副本数量创建出多个副本数量的pod。如果想把deployment控制器的镜像进行升级，比如从v1.0 升级到v2.0。那么deployment控制器会新建一个以v2.0 镜像为基础的ReplicaSet RS控制器。如果在新的ReplicaSet RS控制器中创建出来了一个pod，那么加上旧的ReplicaSet RS控制器中已经提供服务的pod，提供服务的pod就多了，那么就会有一部分用户访问到新版镜像创建出来的pod，剩下的用户会访问到旧版本镜像创建的pod。一部分用户就相当于新镜像版本的测试人员，用更大的用户量级去测试当前代码的可靠性。当这些新版本的代码没问题之后，再继续升级版本。如果代码经过大量用户测试之后发现代码存在bug，那么可以回滚。
完全迭代的方式更新代码，如果代码存在问题，那么出现问题就会波及100%的用户和业务。
金丝雀部署只会用很小的一部分新代码做测试，危害到的范围很小，这种理念就是金丝雀部署。用极小的版本数量去测试当前代码的稳定性，进行部署动作，这种就叫金丝雀部署，也叫灰度部署。
金丝雀部署一定是使用少量的新版本数量才有意义。
删除所有的deployment创建的资源对象：
kubectl delete deployment --all
基于deployment的资源清单文件创建pod：
kubectl apply -f deployment.yaml
查询pod详细信息：
kubectl get pod -n $namespace_name
输出deployment的资源清单：
kubectl get deployment $deployment_name -o yaml
更改deployment的滚动更新幅度：
kubectl patch deployment $deployment_name -n $namespace_name -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":"1", "maxUnavailable":0}}}}'
使用打补丁的方式，更改滚动更新的允许超过最大值的数量是1，并且最多不可用的值是0。
输出deployment的资源清单：
kubectl get deployment $deployment_name -n $namespace_name -o yaml
可以查看到滚动更新的幅度已经改变。
对当前的资源对象做最小部分的修改，使用kubectl patch命令极为合适。
查看pod的详细信息：
kubectl get pod -n $namespace_name -o yaml
写循环：
while true;do curl $pod_ip;done
使用打补丁的方法更新镜像版本：
kubectl patch deployment $deployment_name -n $namespace_name --patch '{"spec":{"template":{"spec":{"containers":{{"name":"deployment-demo-container", "image":"xxx/myapp:v2.0"}}}}}}' && kubectl rollout pause deployment $deployment_name -n $namespace_name
修改镜像版本也可以用：
kubectl set image deployment/nginx-deployment nginx-deployment-container=xxx/nginx:v2
kubectl rollout管理部署的更新版本。kubectl rollout patch 把deployment的部署过程暂停，这时候会出现一个新的版本pod和多个蛮族期望值的pod，也就是比deployment资源清单文件中replicas定义的pod副本数量多一个。
查看pod的信息：
kubectl get pod -n $namespace_name
计数pod个数：
kubectl get pod -n $namespace_name | grep $pod_name | wc -l
使用最新镜像版本的pod是最新事件创建的pod。
kube-proxy基于iptables实现，它有一点粘连的特性，kube-proxy也可以基于ipvs实现。
恢复当前的滚动更新：
kubectl rollout resume deployment $deployment_name -n $namespace_name
查看deployment控制器中pod个数：
kubectl get pod -n $namespace_name | grep $deployment_name | wc -l
控制滚动更新的幅度：
通过允许多的和少的数量去控制。
设置滚动更新的幅度越大，那么滚动更新的速度也越快。需要合理控制一下，设置滚动更新的幅度一般不建议超过25% 。
如果一次性把一半的pod都给干掉的话，那么在大规模的业务环境下，可能会造成大量用户的连接中断。
Deployment回滚：
kubectl rollout undo deployment/deployment-demo -n $namespace_name
查看ReplicaSet控制器：
kubectl get rs -n $nanespace_name
Deployment通过控制不同的replicaset RS当前的期望值去实现在不同版本之间的迭代或者回滚。
查看deployment的回滚状态：
kubectl rollout status deployment $deployment_name
举例：
kubectl rollout status deployment deployment-demo
Deployment回滚：
kubectl rollout undo deployment /$deployment_name -n $namespace_name
举例：
kubectl rollout undo deployment/deployment-demo -n default
查看deployment的回滚状态：
kubectl rollout status deployment $deployment_name -n $namespace_name
kubectl rollout status deployment deployment-demo
再次执行rollout回滚操作：
kubectl rollout undo deployment/depkoyment-demo -n $namespace_name && kubectl rollout status deployment deployment-demo
可以实时打印回滚的状态，可以很好地监控当前的滚动更新和回滚的信息，以此确认回滚的进程和步骤。
执行echo $? 可以查看到执行结果的返回码是0。
如果执行回滚的动作是成功的，我们可以通过执行命令的返回码确认是否有效果。
查看回滚的历史记录：
kubectl rollout history deployment/deployment-demo -n $namespace_name
鼓励的话语：最牛B的成功，来自最傻B的坚持！