Deployment

最新推荐文章于 2024-08-22 22:11:15 发布

山隐的博客

最新推荐文章于 2024-08-22 22:11:15 发布

阅读量674

点赞数

分类专栏：微服务

微服务专栏收录该内容

6 篇文章 0 订阅

订阅专栏

Kubernetes Deployment：
Deployment为Pod和Replica Set（升级版的 Replication Controller）提供声明式更新。
只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。
可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

Deployment 对象中已经覆盖了所有的用例：
使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。
然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
扩容Deployment以满足更高的负载。
暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。
根据Deployment 的状态判断上线是否hang住了。
清除旧的不必要的 ReplicaSet。

创建 Deployment：
您必须在 Deployment 中的 selector 指定正确的 pod template label
Kubernetes 本身并不会阻止您任意指定 pod template label ，但是如果您真的这么做了，这些 controller 之间会相互打架，并可能导致不正确的行为。

Pod-template-hash label：
这个 label 不是用户指定的！
当 Deployment 创建或者接管 ReplicaSet 时，Deployment controller 会自动为 Pod 添加 pod-template-hash label。
防止 Deployment 的子ReplicaSet 的 pod 名字重复。
通过将 ReplicaSet 的 PodTemplate 进行哈希散列，使用生成的哈希值作为 label 的值，并添加到 ReplicaSet selector 里、 pod template label 和 ReplicaSet 管理中的 Pod 上。

更新Deployment：
Deployment 的 rollout 当且仅当 Deployment 的 pod template（例如.spec.template）中的label更新或者镜像更改时被触发。
其他更新，例如扩容Deployment不会触发 rollout。

Rollover（多个rollout并行）：
每当 Deployment controller 观测到有新的 deployment 被创建时，如果没有已存在的 ReplicaSet 来创建期望个数的 Pod 的话，就会创建出一个新的 ReplicaSet 来做这件事。
已存在的 ReplicaSet 控制 label 与.spec.selector匹配但是 template 跟.spec.template不匹配的 Pod 缩容。
新的 ReplicaSet 将会扩容出.spec.replicas指定数目的 Pod，旧的 ReplicaSet 会缩容到0。

Label selector 更新：
不鼓励更新 label selector，我们建议实现规划好您的 selector。
想要执行 label selector 的更新，请一定要谨慎并确认您已经预料到所有可能因此导致的后果。
增添 selector 需要同时在 Deployment 的 spec 中更新新的 label，否则将返回校验错误。
更新 selector，即更改 selector key 的当前值，将导致跟增添 selector 同样的后果。
删除 selector，即删除 Deployment selector 中的已有的 key，不需要对 Pod template label 做任何更改，现有的 ReplicaSet 也不会成为孤儿，删除的 label 仍然存在于现有的 Pod 和 ReplicaSet 中。

回退Deployment：
默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便您可以随时回退。

检查 Deployment 升级的历史记录：
首先，检查下 Deployment 的 revision
查看单个revision 的详细信息

回退到历史版本：
使用 --revision参数指定某个历史版本

清理 Policy：
通过设置.spec.revisonHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录。
默认的会保留所有的 revision

Deployment 扩容：
使用以下命令扩容 Deployment：
kubectl scale deployment nginx-deployment --replicas 10 deployment "nginx-deployment" scaled
集群中启用了horizontal pod autoscaling，您可以给 Deployment 设置一个 autoscaler，基于当前 Pod的 CPU 利用率选择最少和最多的 Pod 数。

比例扩容：
RollingUpdate Deployment 支持同时运行一个应用的多个版本。
Deployment controller 将会平衡已存在的活动中的 ReplicaSet（有 Pod 的 ReplicaSet）和新加入的 replica。这被称为比例扩容。

暂停和恢复Deployment：
发出一次或多次更新前暂停一个 Deployment，然后再恢复它。这样您就能多次暂停和恢复 Deployment，在此期间进行一些修复工作，而不会发出不必要的 rollout。
Deployment 暂停前的初始状态将继续它的功能，而不会对 Deployment 的更新产生任何影响，只要 Deployment是暂停的。
在恢复 Deployment 之前您无法回退一个已经暂停的 Deployment。

Deployment 状态：
Deployment 在生命周期中有多种状态。
在创建一个新的 ReplicaSet 的时候它可以是 progressing 状态， complete 状态，或者 fail to progress 状态。

进行中的 Deployment：
Kubernetes 将执行过下列任务之一的 Deployment 标记为 progressing 状态：
Deployment 正在创建新的ReplicaSet过程中。
Deployment 正在扩容一个已有的 ReplicaSet。
Deployment 正在缩容一个已有的 ReplicaSet。
有新的可用的 pod 出现。

完成的 Deployment：
Kubernetes 将包括以下特性的 Deployment 标记为 complete 状态：
Deployment 最小可用。最小可用意味着 Deployment 的可用 replica 个数等于或者超过 Deployment 策略中的期望个数。
所有与该 Deployment 相关的replica都被更新到了您指定版本，也就说更新完成。
该 Deployment 中没有旧的 Pod 存在。
您可以用kubectl rollout status命令查看 Deployment 是否完成。

失败的 Deployment：
您的 Deployment 在尝试部署新的 ReplicaSet 的时候可能卡住，用于也不会完成。
这可能是因为以下几个因素引起的：
无效的引用
不可读的 probe failure
镜像拉取错误
权限不够
范围限制
程序运行时配置错误
探测这种情况的一种方式是，在您的 Deployment spec 中指定spec.progressDeadlineSeconds。spec.progressDeadlineSeconds 表示 Deployment controller 等待多少秒才能确定（通过 Deployment status）Deployment进程是卡住的。
当超过截止时间后，Deployment controller 会在 Deployment 的 status.conditions中增加一条DeploymentCondition，它包括如下属性：
Type=Progressing
Status=False
Reason=ProgressDeadlineExceeded

kubernetes除了报告Reason=ProgressDeadlineExceeded状态信息外不会对卡住的 Deployment 做任何操作。
如果您暂停了一个 Deployment，在暂停的这段时间内kubernetnes不会检查您指定的 deadline。
您可能在使用 Deployment 的时候遇到一些短暂的错误，这些可能是由于您设置了太短的 timeout，也有可能是因为各种其他错误导致的短暂错误。

操作失败的 Deployment：
所有对完成的 Deployment 的操作都适用于失败的 Deployment。
您可以对它扩/缩容，回退到历史版本，您甚至可以多次暂停它来应用 Deployment pod template。

清理Policy：
设置 Deployment 中的 .spec.revisionHistoryLimit 项来指定保留多少旧的 ReplicaSet。

编写 Deployment Spec：
所有的 Kubernetes 配置中，Deployment 也需要apiVersion，kind和metadata这些配置项。

Pod Template：
.spec.template 是 .spec中唯一要求的字段。
.spec.template 是 pod template. 它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。
另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label和适当的重启策略。
.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。
Replicas：
.spec.replicas 是可以选字段，指定期望的pod数量，默认是1。
Selector：
.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。
策略：
.spec.strategy 指定新的Pod替换旧的Pod的策略。
.spec.strategy.type 可以是"Recreate"或者是 "RollingUpdate"。"RollingUpdate"是默认值。
Recreate Deployment：
.spec.strategy.type==Recreate时，在创建出新的Pod之前会先杀掉所有已存在的Pod。
Rolling Update Deployment：
.spec.strategy.type = RollingUpdate时，Deployment使用rolling update 的方式更新Pod
您可以指定maxUnavailable 和 maxSurge 来控制 rolling update 进程。
MAX UNAVAILABLE：
.spec.strategy.rollingUpdate.maxUnavailable 是可选配置项，用来指定在升级过程中不可用Pod的最大数量。
该值可以是一个绝对值（例如5），也可以是期望Pod数量的百分比（例如10%）。通过计算百分比的绝对值向下取整。
MAX SURGE：
.spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的Pod数量的最大个数。
该值可以是一个绝对值（例如5）或者是期望的Pod数量的百分比（例如10%）。
Progress Deadline Seconds：
.spec.progressDeadlineSeconds 是可选配置项，用来指定在系统报告Deployment的failed progressing
表现为resource的状态中type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded前可以等待的Deployment进行的秒数。
Deployment controller会继续重试该Deployment。
在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。
该值必须大于 .spec.minReadySeconds。
Min Ready Seconds：
.spec.minReadySeconds是一个可选配置项，用来指定没有任何容器crash的Pod并被认为是可用状态的最小秒数。
Rollback To：
.spec.rollbackTo 是一个可以选配置项，用来配置Deployment回退的配置。
设置该参数将触发回退操作，每次回退完成后，该值就会被清除。
Revision：
.spec.rollbackTo.revision是一个可选配置项，用来指定回退到的revision。
默认是0，意味着回退到历史中最老的revision。
Revision History Limit：
Deployment revision history存储在它控制的ReplicaSets中。
.spec.revisionHistoryLimit 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。
该理想值取决于心Deployment的频率和稳定性。
默认所有旧的Replicaset或会被保留，将资源存储在etcd中，是用kubectl get rs查看输出。
每个Deployment的该配置都保存在ReplicaSet中，然而，一旦您删除的旧的RepelicaSet，您的Deployment就无法再回退到那个revison了。
Paused：
.spec.paused是可以可选配置项，boolean值。
用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。

Deployment 的替代选择：
kubectl rolling update：
Kubectl rolling update 虽然使用类似的方式更新Pod和ReplicationController。
推荐使用Deployment，因为它是声明式的，客户端侧，具有附加特性，例如即使滚动升级结束后也可以回滚到任何历史版本。
---------------------
作者：ChenVast
来源：CSDN
原文：https://blog.csdn.net/chenvast/article/details/78601074
版权声明：本文为博主原创文章，转载请附上博文链接！