ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合,通常用来保证给定数量的、完全相同的 Pod 的可用性。
Deployment
是一个可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pod 滚动更新的对象。 尽管 ReplicaSet 可以独立使用,目前它们的主要用途是提供给 Deployment 作为编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时,不必关心如何管理它所创建的 ReplicaSet,Deployment 拥有并管理其 ReplicaSet。 因此,建议在需要 ReplicaSet 时使用 Deployment。
作用: Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。
负责启动3个nginx Pod的 Deployment用例
nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
创建deployment
kubectl apply -f ./nginx-deployment.yaml
查看状态
kubectl get deployments |grep nginx-deployment
NAME
列出了名字空间中 Deployment 的名称。READY
显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。UP-TO-DATE
显示为了达到期望状态已经更新的副本数。AVAILABLE
显示应用可供用户使用的副本数。AGE
显示应用程序运行的时间。查看deployment的上线状态
kubectl rollout status deployment/nginx-deployment
查看Deployment创建的ReplicaSet
kubectl get rs
查看创建的pod
kubectl get pods
查看deployment启动日志,pod启动日志
kubectl describe deployment <deployment-name>
kubectl describe pod <pod-name>
修改镜像版本
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
检查Deployment 上线历史
kubectl rollout history deployment/nginx-deployment
输出类似于
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
CHANGE-CAUSE
的内容是从 Deployment 的 kubernetes.io/change-cause
注解复制过来的。 复制动作发生在修订版本创建时。可以通过以下方式设置 CHANGE-CAUSE
消息:
kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"
为 Deployment 添加注解。要查看修订历史的详细信息
kubectl rollout history deployment/nginx-deployment --revision=2
回滚到上一个修改的版本
kubectl rollout undo deployment/nginx-deployment
回滚到指定版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2
缩放指定大小
kubectl scale deployment/nginx-deployment --replicas=10
自动缩放
kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
Deployment 设置自动缩放器,并基于现有 Pod 的 CPU 利用率选择要运行的 Pod 个数下限和上限。
kubectl rollout pause deployment/nginx-deployment
此时可以更新deployment
恢复deployment
kubectl rollout resume deployment/nginx-deployment
不可以回滚处于暂停状态的 Deployment,除非先恢复其执行状态
执行下面的任务期间,Kubernetes 标记 Deployment 为进行中(Progressing):
当上线过程进入“Progressing”状态时,Deployment 控制器会向 Deployment 的 .status.conditions
中添加包含下面属性的状况条目:
type: Progressing
status: "True"
reason: NewReplicaSetCreated
| reason: FoundNewReplicaSet
| reason: ReplicaSetUpdated
可以使用 kubectl rollout status
监视 Deployment 的进度。
当 Deployment 具有以下特征时,Kubernetes 将其标记为完成(Complete);
当上线过程进入“Complete”状态时,Deployment 控制器会向 Deployment 的 .status.conditions
中添加包含下面属性的状况条目:
type: Progressing
status: "True"
reason: NewReplicaSetAvailable
这一 Progressing
状况的状态值会持续为 "True"
,直至新的上线动作被触发。 即使副本的可用状态发生变化(进而影响 Available
状况),Progressing
状况的值也不会变化。
可以使用 kubectl rollout status
检查 Deployment 是否已完成。 如果上线成功完成,kubectl rollout status
返回退出代码 0。
Deployment 可能会在尝试部署其最新的 ReplicaSet 受挫,一直处于未完成状态。 造成此情况一些可能因素如下:
检测此状况的一种方法是在 Deployment 规约中指定截止时间参数: (.spec.progressDeadlineSeconds
)。 .spec.progressDeadlineSeconds
给出的是一个秒数值,Deployment 控制器在(通过 Deployment 状态) 标示 Deployment 进展停滞之前,需要等待所给的时长。
以下 kubectl
命令设置规约中的 progressDeadlineSeconds
,从而告知控制器 在 10 分钟后报告 Deployment 的上线没有进展:
kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
输出类似于:
deployment.apps/nginx-deployment patched
超过截止时间后,Deployment 控制器将添加具有以下属性的 Deployment 状况到 Deployment 的 .status.conditions
中:
type: Progressing
status: "False"
reason: ProgressDeadlineExceeded
这一状况也可能会比较早地失败,因而其状态值被设置为 "False"
, 其原因为 ReplicaSetCreateError
。 一旦 Deployment 上线完成,就不再考虑其期限。
可以在 Deployment 中设置 .spec.revisionHistoryLimit
字段以指定保留此 Deployment 的多少个旧的ReplicaSet。其余的 ReplicaSet 将在后台被垃圾回收。 默认情况下,此值为 10。
说明:
显式将此字段设置为 0 将导致 Deployment 的所有历史记录被清空,因此 Deployment 将无法回滚。