官网参考地址:
https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/
Deployment
属于 k8s
中的一种工作负载资源,一个 Deployment
为 Pod
和 ReplicaSet
(副本控制器)提供声明式的更细能力:
Deployment
中的目标状态Deployment
控制器以受控的速率(不间断)更改实际状态,使其变成我们所描述的目标期望状态(控制循环)Deployment
使 Pod
有自愈能力Pod
,而是部署一个 Deployment
来自官网的一个示例文件
####deploy-demo.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
我们尝试启动一下:kubectl apply -f deploy-demo.yaml
创建了一个名字为 nginx-deployment 的 Deployment
,这个名称成为后续创建 ReplicaSet 和 Pod 的命名基础
Deployment
创建了一个 ReplicaSet
,由它创建了三个 Pod
副本
.spec.selector
字段定义所创建的 ReplicaSet
如何查找要管理的 Pod
。 在这里,选择在 Pod
模板中定义的标签(app: nginx
),建议就保持一致即可
template
字段里面其实就是一个 Pod
的模板,和之前学习 Pod
写法是一样的
一次 Deployment
,产生了如下资源
Deployment
资源ReplicaSet
资源Pod
资源检查 Deployment 信息
kubectl get deploy
NAME
列出了名字空间中 Deployment 的名称READY
显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”UP-TO-DATE
显示为了达到期望状态已经更新的副本数AVAILABLE
显示应用可供用户使用的副本数AGE
显示应用程序运行的时间检查 Deployment 上线状态
kubectl rollout status deploy nginx-deployment
检查 Deployment 创建出来的 ReplicaSet 信息
kubectl get replicaset
NAME
列出名字空间中 ReplicaSet 的名称DESIRED
显示应用的期望副本个数,即在创建 Deployment 时所定义的值。 此为期望状态CURRENT
显示当前运行状态中的副本个数READY
显示应用中有多少副本可以为用户提供服务AGE
显示应用已经运行的时间长度检查 Pod 自动生成的标签信息
kubectl get pod --show-labels
官网参考:https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/deployment-v1/
yaml
文件:kubectl explain deploy
KIND: Deployment
VERSION: apps/v1
DESCRIPTION:
Deployment enables declarative updates for Pods and ReplicaSets.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata <Object> ## 标准的元数据信息
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <Object> ## 需要我们手动描述的行为规约
Specification of the desired behavior of the Deployment.
status <Object> ## 最近观测到的状态,k8s自动更新,不需要我们描述
Most recently observed status of the Deployment.
spec
规约如何描述:kubectl explain deploy.spec
FIELDS:
minReadySeconds <integer> ##Pod就绪后被视为可用的时间,默认为0
Minimum number of seconds for which a newly created pod should be ready
without any of its container crashing, for it to be considered available.
Defaults to 0 (pod will be considered available as soon as it is ready)
paused <boolean> ## 暂停部署
Indicates that the deployment is paused.
progressDeadlineSeconds <integer> ## deployment部署的最大秒数,默认600s,超过就报错误了
The maximum time in seconds for a deployment to make progress before it is
considered to be failed. The deployment controller will continue to process
failed deployments and a condition with a ProgressDeadlineExceeded reason
will be surfaced in the deployment status. Note that progress will not be
estimated during the time a deployment is paused. Defaults to 600s.
replicas <integer> ##pod数量(副本数),默认是1 `RS`控制器实现的
Number of desired pods. This is a pointer to distinguish between explicit
zero and not specified. Defaults to 1.
revisionHistoryLimit <integer> ##保留允许回滚的旧 ReplicaSet 的数量。默认10
The number of old ReplicaSets to retain to allow rollback. This is a
pointer to distinguish between explicit zero and not specified. Defaults to
10.
selector <Object> -required- ##指定要控制的pod的标签
Label selector for pods. Existing ReplicaSets whose pods are selected by
this will be the ones affected by this deployment. It must match the pod
template's labels.
strategy <Object> ## 更新策略
The deployment strategy to use to replace existing pods with new ones.
rollingUpdate <Object> ## 指定滚动更新策略
maxSurge <string> ## 【最大增量】一次最多新建几个Pod。 百分比和数字都可以
MaxUnavailable:为0 的时候, maxSurge不能为0
maxUnavailable ## 【最大不可用量】最大不可用的Pod数量,最多杀几个pod
type <string>: Recreate/RollingUpdate(默认)
template <Object> -required- ## 必须描述项,描述将要创建的Pod,这个里面的写法就是我们之前学过的pod的写法
Template describes the pods that will be created.
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
Deployment
赋予了Pod
故障转移和自愈能力
yaml
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
Pod
,并在另一个控制台观察一下状态:会自愈kubectl get pod -owide -w
k8s-03
关机,看一下状态:在特定的时间内,会在其他节点启动故障的 Pod
什么时候才会触发更新 Deployment
呢?仅当 Deployment Pod
模板(即 .spec.template
)发生改变时,例如模板的标签或容器镜像被更新, 才会触发 Deployment
上线。其他更新(如对 Deployment
执行扩缩容的操作)不会触发上线动作
更新上线动作原理: 创建新的 rs,准备就绪后,替换旧的 rs(此时不会删除,因为revisionHistoryLimit
指定了保留几个版本)
更新 Pod
镜像
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
Pod
的镜像为:nginx##可以直接改yaml文件进行更新
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx ##修改镜像
kubectl apply -f deploy-demo.yaml
kubectl rollout status deploy nginx-deployment
ReplicaSet
的信息:kubectl get rs
通过创建新的 ReplicaSet 并将其扩容到 3 个副本并将旧 ReplicaSet 缩容到 0 个副本完成了 Pod 的更新操作
- 更新时会关闭一定数量的
Pod
,默认情况下确保至少所需Pod
的75%处于运行状态(最大比例为25%)- 还确保仅所创建
Pod
数量只可能比期望Pod
数高一点点。 默认情况下,它可确保启动的Pod
个数比期望个数最多多出 125%(最大峰值 25%)。
再观测一下更新状态
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 2 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量7个
maxUnavailable: 2 ##更新期间可能不可用的最大Pod数量2个
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 2 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量7个
maxUnavailable: 2 ##更新期间可能不可用的最大Pod数量2个
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21.6-alpine
停止2个,启动4个
最终更新到一个期待状态
Deployment
的信息kubectl describe deploy nginx-deployment
最开始创建的时候,`Deployment`创建了 `RS`并将直接扩容到5个副本
更新的时候,创建一个新的 `RS`,并将其扩容为2,等待其就绪
旧的 `RS` 缩容到3
新的 `RS` 扩容到4
继续对 `RS` 扩缩容
最终5个可用的副本在新的 `RS` 中
旧的 `RS` 缩容为0
加深一下这个地方的理解
maxSurge: 3 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量8个
maxUnavailable: 4 ##更新期间可能不可用的最大Pod数量4个
创建了一个新的 `RS`扩容到3,就绪准备
旧的 `RS` 缩容到1,以便最大不可用数量有4个
将新的 `RS` 扩容到5
将旧的 `RS` 缩容到0
Kubernetes 在计算
availableReplicas
数值时不考虑终止过程中的 Pod,availableReplicas
的值一定介于replicas - maxUnavailable
和replicas + maxSurge
之间。 因此,你可能在上线期间看到 Pod 个数比预期的多,Deployment 所消耗的总的资源也大于replicas + maxSurge
个 Pod 所用的资源,直到被终止的 Pod 所设置的terminationGracePeriodSeconds
到期为止。
比例缩放图示
有时,你可能想要回滚 Deployment;例如,当 Deployment 不稳定时(例如进入反复崩溃状态)。 默认情况下,Deployment 的所有上线记录都保留在系统中,以便可以随时回滚 (你可以通过修改修订历史记录限制来更改这一约束)。
Deployment 被触发上线时,系统就会创建 Deployment 的新的修订版本。 这意味着仅当 Deployment 的 Pod 模板(
.spec.template
)发生更改时,才会创建新修订版本 – 例如,模板的标签或容器镜像发生变化。 其他更新,如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。 这是为了方便同时执行手动缩放或自动缩放。 换言之,当你回滚到较早的修订版本时,只有 Deployment 的 Pod 模板部分会被回滚。
模拟一下错误滚动升级
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16.1
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.1555
kubectl rollout status deployment/nginx-deployment
###上线处于一个停滞状态
[root@k8s-01 k8s-yaml]# kubectl rollout status deployment/nginx-deployment
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 5 new replicas have been updated...
Deployment 控制器自动停止有问题的上线过程,并停止对新的 ReplicaSet 扩容。 这行为取决于所指定的 rollingUpdate 参数(具体为
maxUnavailable
)。 默认情况下,Kubernetes 将此值设置为 25%。
回滚操作
Deployment
修订历史:kubectl rollout history deployment/nginx-deployment
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 --to-revision=1
撤消当前上线回滚到以前的修订版本:
kubectl rollout undo deployment/nginx-deployment
在你更新一个 Deployment 的时候,或者计划更新它的时候, 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 当你准备应用这些变更时,你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序,而不会触发不必要的上线操作。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16.1
yaml
文件暂停上线apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
paused: true ##true表示暂停上线,默认false
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16.1
yaml
更新镜像apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
paused: true ##true表示暂停上线,默认false
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
从可观测的状态来看,这次更新并没有产生新的上线动作,也不会产生新的 RS
我们再次修改更新一下镜像
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
paused: true ##true表示暂停上线,默认false
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21.6-alpine
.spec.paused
,恢复上线apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
paused: false ##true表示暂停上线,默认false
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
strategy: ## 更新策略
type: RollingUpdate
rollingUpdate: ## 指定滚动更新策略
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21.6-alpine
不可以回滚处于暂停状态的 Deployment,除非先恢复其执行状态。
Pod 模板
.spec.template
是一个 Pod 模板。 它和 Pod 的语法规则完全相同。 只是这里它是嵌套的,因此不需要 apiVersion
或 kind
副本数
.spec.replicas
是指定所需 Pod 的可选字段。它的默认值是1。
选择算符
.spec.selector
是指定本 Deployment 的 Pod 标签选择算符的必需字段。
策略
.spec.strategy
策略指定用于用新 Pod 替换旧 Pod 的策略。 .spec.strategy.type
可以是 “Recreate” 或 “RollingUpdate”。“RollingUpdate” 是默认值
重新创建:如果 .spec.strategy.type==Recreate
,在创建新 Pod 之前,所有现有的 Pod 会被杀死。
滚动更新:Deployment 会在 .spec.strategy.type==RollingUpdate
时,采取 滚动更新的方式更新 Pod。你可以指定 maxUnavailable
和 maxSurge
来控制滚动更新 过程。
最大不可用
.spec.strategy.rollingUpdate.maxUnavailable
是一个可选字段,用来指定更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字(例如,5),也可以是所需 Pod 的百分比(例如,10%)。百分比值会转换成绝对数并去除小数部分。 如果 .spec.strategy.rollingUpdate.maxSurge
为 0,则此值不能为 0。 默认值为 25%。
例如,当此值设置为 30% 时,滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的70%。 新 Pod 准备就绪后,可以继续缩容旧有的 ReplicaSet,然后对新的 ReplicaSet 扩容, 确保在更新期间可用的 Pod 总数在任何时候都至少为所需的 Pod 个数的 70%。
最大峰值
.spec.strategy.rollingUpdate.maxSurge
是一个可选字段,用来指定可以创建的超出期望 Pod 个数的 Pod 数量。此值可以是绝对数(例如,5)或所需 Pod 的百分比(例如,10%)。 如果 MaxUnavailable
为 0,则此值不能为 0。百分比值会通过向上取整转换为绝对数。 此字段的默认值为 25%。
例如,当此值为 30% 时,启动滚动更新后,会立即对新的 ReplicaSet 扩容,同时保证新旧 Pod 的总数不超过所需 Pod 总数的 130%。一旦旧 Pod 被杀死,新的 ReplicaSet 可以进一步扩容, 同时确保更新期间的任何时候运行中的 Pod 总数最多为所需 Pod 总数的 130%。
进度期限秒数
.spec.progressDeadlineSeconds
是一个可选字段,用于指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 type: Progressing
、status: False
、 reason: ProgressDeadlineExceeded
。Deployment 控制器将在默认 600 毫秒内持续重试 Deployment。 将来,一旦实现了自动回滚,Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。
如果指定,则此字段值需要大于 .spec.minReadySeconds
取值。
最短就绪时间
.spec.minReadySeconds
是一个可选字段,用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间, 只有超出这个时间 Pod 才被视为可用。默认值为 0(Pod 在准备就绪后立即将被视为可用)
修订历史版本限制
Deployment 的修订历史记录存储在它所控制的 ReplicaSets 中。
.spec.revisionHistoryLimit
是一个可选字段,用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源,并占用 kubectl get rs
的输出。 每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中;因此,一旦删除了旧的 ReplicaSet, 将失去回滚到 Deployment 的对应修订版本的能力。 默认情况下,系统保留 10 个旧 ReplicaSet,但其理想值取决于新 Deployment 的频率和稳定性。
更具体地说,将此字段设置为 0 意味着将清理所有具有 0 个副本的旧 ReplicaSet。 在这种情况下,无法撤消新的 Deployment 上线,因为它的修订历史被清除了。
暂停
.spec.paused
是用于暂停和恢复 Deployment 的可选布尔字段。 暂停的 Deployment 和未暂停的 Deployment 的唯一区别是,Deployment 处于暂停状态时, PodTemplateSpec 的任何修改都不会触发新的上线。 Deployment 在创建时是默认不会处于暂停状态