建设网站成本预算,玉器珠宝做网站,网络安全未来发展趋势,网站推广的基本方法为()文章目录1. Deployment 基础1.1 什么是 Deployment1.2 简单体验 Deployment1.3 Deployment 信息描述1.4 如何编写 Deployment2. Deployment 简单特性2.1 赋予 Pod 故障转移和自愈能力2.2 更新 Deployment2.3 回滚 Deployment2.4 暂停、恢复 Deployment 的上线过程2.5 Deploymen…
文章目录1. Deployment 基础1.1 什么是 Deployment1.2 简单体验 Deployment1.3 Deployment 信息描述1.4 如何编写 Deployment2. Deployment 简单特性2.1 赋予 Pod 故障转移和自愈能力2.2 更新 Deployment2.3 回滚 Deployment2.4 暂停、恢复 Deployment 的上线过程2.5 Deployment 规约描述官网参考地址 https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/ 1. Deployment 基础
1.1 什么是 Deployment
Deployment 属于 k8s 中的一种工作负载资源一个 Deployment 为 Pod 和 ReplicaSet 副本控制器提供声明式的更细能力
我们只需要描述 Deployment 中的目标状态Deployment 控制器以受控的速率不间断更改实际状态使其变成我们所描述的目标期望状态控制循环Deployment 使 Pod 有自愈能力我们部署应用一般不会直接写 Pod而是部署一个 Deployment
1.2 简单体验 Deployment
来自官网的一个示例文件
####deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: 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 资源
1.3 Deployment 信息描述
检查 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 1.4 如何编写 Deployment 官网参考https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/deployment-v1/ 老办法官网加命令参考如何编写一个资源 yaml 文件kubectl explain deploy
KIND: Deployment
VERSION: apps/v1DESCRIPTION:Deployment enables declarative updates for Pods and ReplicaSets.FIELDS:apiVersion stringAPIVersion defines the versioned schema of this representation of anobject. Servers should convert recognized schemas to the latest internalvalue, and may reject unrecognized values. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resourceskind stringKind is a string value representing the REST resource this objectrepresents. Servers may infer this from the endpoint the client submitsrequests to. Cannot be updated. In CamelCase. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kindsmetadata Object ## 标准的元数据信息Standard objects metadata. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec 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就绪后被视为可用的时间默认为0Minimum number of seconds for which a newly created pod should be readywithout 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 isconsidered to be failed. The deployment controller will continue to processfailed deployments and a condition with a ProgressDeadlineExceeded reasonwill be surfaced in the deployment status. Note that progress will not beestimated 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 explicitzero and not specified. Defaults to 1.revisionHistoryLimit integer ##保留允许回滚的旧 ReplicaSet 的数量。默认10The number of old ReplicaSets to retain to allow rollback. This is apointer to distinguish between explicit zero and not specified. Defaults to10.selector Object -required- ##指定要控制的pod的标签Label selector for pods. Existing ReplicaSets whose pods are selected bythis will be the ones affected by this deployment. It must match the podtemplates labels.strategy Object ## 更新策略The deployment strategy to use to replace existing pods with new ones.rollingUpdate Object ## 指定滚动更新策略maxSurge string ## 【最大增量】一次最多新建几个Pod。 百分比和数字都可以MaxUnavailable为0 的时候 maxSurge不能为0maxUnavailable ## 【最大不可用量】最大不可用的Pod数量,最多杀几个podtype 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-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.22. Deployment 简单特性
2.1 赋予 Pod 故障转移和自愈能力 Deployment 赋予了 Pod 故障转移和自愈能力 我们部署一个测试 yaml
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2尝试删除一些 Pod并在另一个控制台观察一下状态会自愈
kubectl get pod -owide -w我们直接将k8s-03关机看一下状态在特定的时间内会在其他节点启动故障的 Pod 2.2 更新 Deployment
什么时候才会触发更新 Deployment 呢仅当 Deployment Pod 模板即 .spec.template发生改变时例如模板的标签或容器镜像被更新 才会触发 Deployment 上线。其他更新如对 Deployment 执行扩缩容的操作不会触发上线动作
更新上线动作原理 创建新的 rs准备就绪后替换旧的 rs此时不会删除因为revisionHistoryLimit 指定了保留几个版本
更新 Pod 镜像
现在我们有一个示例文件在运行
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2我们先来更新一下 Pod 的镜像为nginx
##可以直接改yaml文件进行更新
##我有这么一个deployment
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: 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-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 2 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量7个maxUnavailable: 2 ##更新期间可能不可用的最大Pod数量2个template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2更新它
##deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 2 ### 更新期间任何时间运行的Pod总数最多为预期Pod数量7个maxUnavailable: 2 ##更新期间可能不可用的最大Pod数量2个template:metadata:labels:app: nginxspec:containers:- name: nginximage: 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 缩容到0Kubernetes 在计算 availableReplicas 数值时不考虑终止过程中的 Pod availableReplicas 的值一定介于 replicas - maxUnavailable 和 replicas maxSurge 之间。 因此你可能在上线期间看到 Pod 个数比预期的多Deployment 所消耗的总的资源也大于 replicas maxSurge 个 Pod 所用的资源直到被终止的 Pod 所设置的 terminationGracePeriodSeconds 到期为止。 比例缩放图示 2.3 回滚 Deployment
有时你可能想要回滚 Deployment例如当 Deployment 不稳定时例如进入反复崩溃状态。 默认情况下Deployment 的所有上线记录都保留在系统中以便可以随时回滚 你可以通过修改修订历史记录限制来更改这一约束。 Deployment 被触发上线时系统就会创建 Deployment 的新的修订版本。 这意味着仅当 Deployment 的 Pod 模板.spec.template发生更改时才会创建新修订版本 – 例如模板的标签或容器镜像发生变化。 其他更新如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。 这是为了方便同时执行手动缩放或自动缩放。 换言之当你回滚到较早的修订版本时只有 Deployment 的 Pod 模板部分会被回滚。 模拟一下错误滚动升级
准备一个测试 yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.16.1
模拟一下错误升级
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.1555查看一下状态 查看一下上线状态
kubectl rollout status deployment/nginx-deployment###上线处于一个停滞状态
[rootk8s-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-causeimage updated to 1.16.1 为 Deployment 添加注解。手动编辑资源的清单。 查看修订历史的详细信息kubectl rollout history deployment/nginx-deployment --revision2 回滚到之前的修订版本我们要回滚到版本1kubectl rollout undo deployment/nginx-deployment --to-revision1 撤消当前上线回滚到以前的修订版本 kubectl rollout undo deployment/nginx-deployment 2.4 暂停、恢复 Deployment 的上线过程 在你更新一个 Deployment 的时候或者计划更新它的时候 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 当你准备应用这些变更时你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序而不会触发不必要的上线操作。 一个测试
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.16.1修改 yaml 文件暂停上线
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: true ##true表示暂停上线默认falsereplicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.16.1修改 yaml 更新镜像
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: true ##true表示暂停上线默认falsereplicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx从可观测的状态来看这次更新并没有产生新的上线动作也不会产生新的 RS 我们再次修改更新一下镜像
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: true ##true表示暂停上线默认falsereplicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.21.6-alpine修改 .spec.paused 恢复上线
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:paused: false ##true表示暂停上线默认falsereplicas: 5 ## 5个副本selector:matchLabels:app: nginxstrategy: ## 更新策略type: RollingUpdaterollingUpdate: ## 指定滚动更新策略maxSurge: 1maxUnavailable: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.21.6-alpine看一下状态正常上线 不可以回滚处于暂停状态的 Deployment除非先恢复其执行状态。 2.5 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.typeRecreate在创建新 Pod 之前所有现有的 Pod 会被杀死。 滚动更新Deployment 会在 .spec.strategy.typeRollingUpdate时采取 滚动更新的方式更新 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 才被视为可用。默认值为 0Pod 在准备就绪后立即将被视为可用
修订历史版本限制
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 在创建时是默认不会处于暂停状态
