介绍
用于部署无状态的服务,如Web服务、API服务等。它提供了应用程序的副本管理、自动扩展、滚动升级等功能。具体来说,Deployment通过ReplicaSet实现副本管理,确保指定数量的Pod副本正在运行,并处理Pod的创建、删除和更新。此外,Deployment还可以实现无缝迁移、自动扩容缩容、自动灾难恢复以及一键回滚等功能
Deployment 示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
progressDeadlineSeconds: 600 # 用于定义Deployment升级过程中的最大时间。具体来说,如果Deployment的升级过程超过了这个时间还没有完成,那么Kubernetes会判断该Deployment进程已经卡住,并可能会进行回滚或其他相应的操作
revisionHistoryLimit: 10 # 默认保留RS旧的revision的个数
strategy:
rollingUpdate:
maxSurge: 25% # 可以超过期望值的最大Pod数,可选字段,默认为25%,可以设置成数字或百分比,如果该值为0,那么maxUnavailable不能为0
maxUnavailable: 25% # 指定在回滚或更新时最大不可用的Pod的数量,可选字段,默认25%,可以设置成数字或百分比,如果该值为0,那么maxSurge就不能为0
type: RollingUpdate # 更新deployment的方式,默认是RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
yaml 关键字解释
- revisionHistoryLimit: 10 # 默认保留RS旧的revision的个数
- progressDeadlineSeconds: 600 # 用于定义Deployment升级过程中的最大时间。具体来说,如果Deployment的升级过程超过了这个时间还没有完成,那么Kubernetes会判断该Deployment进程已经卡住,并可能会进行回滚或其他相应的操作。
- maxSurge: 25% # 可以超过期望值的最大Pod数,可选字段,默认为25%,可以设置成数字或百分比,如果该值为0,那么maxUnavailable不能为0
- maxUnavailable: 25% # 指定在回滚或更新时最大不可用的Pod的数量,可选字段,默认25%,可以设置成数字或百分比,如果该值为0,那么maxSurge就不能为0
- type: RollingUpdate # 更新deployment的方式,默认是RollingUpdate
检查 Deployment 是否已创建
kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 0 0 1s
在检查集群中的 Deployment 时,所显示的字段有
- NAME 列出了名字空间中 Deployment 的名称。
- READY 显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。
- UP-TO-DATE 显示为了达到期望状态已经更新的副本数。
- AVAILABLE 显示应用可供用户使用的副本数。
- AGE 显示应用程序运行的时间。
要查看每个 Pod 自动生成的标签
kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897
- 注意:app=nginx 是yaml文件中定义好的 可以修改。pod-template-hash 这个标签是自动生成的最好不要修改此标签。
更新 Deployment
更新策略
RollingUpdate 滚动更新
这是Deployment的默认升级策略。在滚动更新过程中,控制器会逐步替换旧的Pod副本,确保应用程序的可用性。每次替换一个Pod副本,通过逐步增加新副本的数量和减少旧副本的数量,实现平滑的升级过程。这种方式可以维持服务的正常提供,避免服务运行中断。
示例:
# 展示的为部分yaml文件
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
Recreate 重建更新
重建更新指的是先全部删除已有的Pod对象,然后创建新版本的Pod对象。这种更新方式在更新过程中会导致运行的服务有一段时间的中断。同时,由于没有新、老版本的Pod共存并共同提供服务的阶段,这种方式避免了可能出现的版本冲突问题。然而,由于服务中断的缺点,重建更新在生产环境中很少使用。
示例:
# 展示的为部分yaml文件
strategy:
type: Recreate
更改deployment的镜像并记录
## “record 在未来版本弃用 但是目前还可以使用”
kubectl set image deploy nginx-deployment nginx=nginx:1.16.1 –-record
在这里,deploy 表明 Deployment 的名称,nginx 表明需要进行更新的容器, 而 nginx:1.16.1 则表示镜像的新版本以及它的标签, -record 表明记录此次更新过程。
查看更新过程
kubectl rollout status deployment nginx-deployment
## 输出如下
Waiting for deployment "nginx" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx" rollout to finish: 1 old replicas are pending termination...
deployment "nginx" successfully rolled out
查看更多详细信息
kubectl describe deployments nginx-deployment
输出如下:
Name: nginx-deployment
Namespace: default
CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=2
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.16.1
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3
Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1
Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2
Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2
Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
可以看到,当第一次创建 Deployment 时,它创建了一个 ReplicaSet(nginx-deployment-2035384211) 并将其直接扩容至 3 个副本。更新 Deployment 时,它创建了一个新的 ReplicaSet (nginx-deployment-1564180365),并将其扩容为 1,等待其就绪;然后将旧 ReplicaSet 缩容到 2, 将新的 ReplicaSet 扩容到 2 以便至少有 3 个 Pod 可用且最多创建 4 个 Pod。 然后,它使用相同的滚动更新策略继续对新的 ReplicaSet 扩容并对旧的 ReplicaSet 缩容。 最后,你将有 3 个可用的副本在新的 ReplicaSet 中,旧 ReplicaSet 将缩容到 0。
回滚 Deployment
例如,当 Deployment 不稳定时(例如进入反复崩溃状态)。 默认情况下,Deployment 的所有上线记录都保留在系统中,以便可以随时回滚 。
假设你在更新 Deployment 时犯了一个拼写错误,将镜像名称命名设置为 nginx:1.161 而不是 nginx:1.16.1
kubectl set image deployment nginx-deployment nginx=nginx:1.161
此上线进程会出现停滞。你可以通过检查上线状态来验证
kubectl rollout status deployment nginx-deployment
检查 Deployment 上线历史
资源修改历史默认最多保存10条,这个可以修改。
kubectl rollout history deployment nginx-deployment
输出如下:
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 <none>
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
- 注意:想要在执行 ‘ kubectl rollout history deployment nginx-deployment ’输出有更新历史版本的记录必须在命令结尾添加 --record (目前这个参数还可以使用,在K8S1.26.14版本,但是建议用下面参数添加记录。)
使用 kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause=“kubectl set image deployment/nginx-deployment nginx=nginx:1.161” 为 Deployment 添加注解。
操作步骤:在每次创建或者修改完任何资源的时候,将具体的操作命令添加到双引号里面
例如:
## 修改镜像版本
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
## 执行完上一条命令以后,执行如下命令(双引号里面的内容随便写)
kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1"
## 然后再次查看
[root@master01 ~]# kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
1 <none>
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
回滚到之前版本
回滚到上一个版本:
## 按照下面给出的步骤将 Deployment 从当前版本回滚到以前的版本(即版本 1)
kubectl rollout undo deployment nginx-deployment
或者,你也可以通过使用 --to-revision 来回滚到特定修订版本:
kubectl rollout undo deployment nginx-deployment --to-revision=3
查看指定版本的详细信息
kubectl rollout history deployment/nginx-deployment --revision=1
输出如下:
deployments "nginx-deployment" revision 1
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Containers:
nginx:
Image: nginx:1.16.1
Port: 80/TCP
QoS Tier:
cpu: BestEffort
memory: BestEffort
Environment Variables: <none>
No volumes.
暂停、恢复 Deployment 的上线过程
在你更新一个 Deployment 的时候,或者计划更新它的时候, 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 当你准备应用这些变更时,你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序,而不会触发不必要的上线操作。
暂停上线
kubectl rollout pause deployment nginx-deployment
接下来更新 Deployment 镜像
## 当然了 也可以修改其他资源
kubectl set image deployment nginx-deployment nginx=nginx:1.16.2
恢复 Deployment 上线
## 资源修改好以后恢复
kubectl rollout resume deployment nginx-deployment
扩容和缩容
扩容:
# 基本这样手动扩容是提前知道什么时候业务访问量比较大然后才进行的扩容
# 缩容 就是吧 --replicas=5 改小就可以了
kubectl scale deployment nginx-deployment --replicas=5