deployment最突出的一个功能是支持滚动更新，比如我们需要吧应用容器更改为nginx:1.7.9版本，修改后的资源清单
[root@master1 ~]# cat nginx-strategy-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-strategy-deployment
namespace: default
spec:
replicas: 4
selector:
matchLabels:
app: nginx
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.8
ports:
- containerPort: 80
与水平伸缩相比，滚动rollout出了更新了镜像之外，我们还指定了更新策略
minReadySeconds:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavaliable: 1
minReadySeconds: 表示kubernetes在等待设置时间后才进行升级，如果没有设置该值kubernete会假设容器启动起来就提供服务了，如果没有设置该值，在某些极端情况下可能会造成服务不正常运行，默认值是0
type：RollingUpdate表示，设置更新策略为滚动更新，可以设置为recreate和RollingUpdate两个值，recreate表示全部重新创建，默认值就是RollingUpdate
maxSurge: 表示升级过程中最多可以比原先设置多出的pod数量，例如maxSurge=1,replicas:5 就表示kubennetes会先启动一个新的pod,然后删除掉一个就的pod，整个升级过程中最多会有5+1pod
maxUnavailable:表示升级过程中最多有多少个pod处于无法提供服务的状态，当manSurge不为0时，该值也不能为0，maxUnavailable =1 表示kubernetes整个升级过程中最多会有一个pod处于无法服务的状态
kubectl apply -f nginx-strategy-deployment.yaml
更新后，我们可以执行kubectl rollout status 来查看我们此次滚动的更新状态
kubectl rollout status deployment/nginx-strategy-deployment
从上面的信息可以看出我们的滚动更新已经有3个pod更新完成了，在滚动更新的过程中，我们还可以执行如下的命令来暂停更新
kubectl rollout pause deployment/nginx-strategy-deployment
这个时候我们的滚动更新就暂停了，此时我们可以查看下deployment的详细信息
kubectl describe deploy nginx-strategy-deployment
deployment.apps/nginx-strategy-deployment paused [root@master1 ~]# kubectl describe deploy nginx-strategy-deployment Name: nginx-strategy-deployment Namespace: default CreationTimestamp: Mon, 09 May 2022 23:45:26 -0400 Labels:Annotations: deployment.kubernetes.io/revision: 2 Selector: app=nginx Replicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 5 RollingUpdateStrategy: 1 max unavailable, 1 max surge Pod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.7.8 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes: Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing Unknown DeploymentPaused OldReplicaSets: NewReplicaSet: nginx-strategy-deployment-8f5cc57cf (4/4 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 17m deployment-controller Scaled up replica set nginx-strategy-deployment-5d59d67564 to 3 Normal ScalingReplicaSet 7m15s deployment-controller Scaled up replica set nginx-strategy-deployment-5d59d67564 to 4 Normal ScalingReplicaSet 3m27s deployment-controller Scaled up replica set nginx-strategy-deployment-8f5cc57cf to 1 Normal ScalingReplicaSet 3m27s deployment-controller Scaled down replica set nginx-strategy-deployment-5d59d67564 to 3 Normal ScalingReplicaSet 3m27s deployment-controller Scaled up replica set nginx-strategy-deployment-8f5cc57cf to 2 Normal ScalingReplicaSet 2m41s deployment-controller Scaled down replica set nginx-strategy-deployment-5d59d67564 to 2 Normal ScalingReplicaSet 2m41s deployment-controller Scaled up replica set nginx-strategy-deployment-8f5cc57cf to 3 Normal ScalingReplicaSet 2m30s deployment-controller Scaled down replica set nginx-strategy-deployment-5d59d67564 to 0 Normal ScalingReplicaSet 2m30s deployment-controller Scaled up replica set nginx-strategy-deployment-8f5cc57cf to 4
这个时候我们可以kubectl rollout resume 来恢复我们的滚动更新
kubectl get deployment
从上面可以看出滚动更新之前我们使用的RS资源对象的pod副本数已经变成0了，而滚动更新后RS资源对象变成了3个副本
可以查看rollout history来获取
其实rollout history中记录revison是和ReplicaSets 一一对应，，如果我们手动删除了某个ReplicaSet对应到rollout history 就会被删除，也就是说无法rollout到这revison，同样我们还可以查看一个revison的详细信息
kubectl get rs -l app=nginx
