怎么样免费做网站,蘑菇街网站怎么做,湛江低价网站建设,外链seo招聘Pod 升级可能面临的问题当集群中的某个服务需要升级时#xff0c;我们需要停止目前与该服务相关的所有 Pod#xff0c;然后下载新版本镜像并创建新的 Pod。但是当集群规模比较庞大时#xff0c;那么这个工作就会变成一个挑战#xff0c;而且先全部停止然后再逐步升级的方式…Pod 升级可能面临的问题当集群中的某个服务需要升级时我们需要停止目前与该服务相关的所有 Pod然后下载新版本镜像并创建新的 Pod。但是当集群规模比较庞大时那么这个工作就会变成一个挑战而且先全部停止然后再逐步升级的方式会导致较长一段时间内服务的不可用性。针对这种情况k8s 提供了滚动升级方式来解决该问题。Deployment 升级Pod 对象通常由 Deployment 对象创建管理接下来我们通过 Deployment 创建的 Pod 对象升级部署操作来展开叙述。Deployment 创建示例以 Nginx 的 Deployment 对象 yaml 定义为例其中创建了一个 ReplicaSet负责启动三个 nginx Podnginx-deployment.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.2ports:- containerPort: 801. 创建 nginx-deployment.yaml 文件定义的 Deployment 对象kubectl create -f nginx-deployment.yaml1. 查看创建的 Deployment 对象kubectl get deployments如果 Deployment 对象成功创建则输出如下信息NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s在检查集群中的 Deployment 时所显示的字段有• NAME列出了名字空间中 Deployment 的名称。• READY显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。• UP-TO-DATE显示为了达到期望状态已经更新的副本数。• AVAILABLE显示应用可供用户使用的副本数。• AGE显示应用程序运行的时间。从上面 Deployment 对象输出的信息中可以看到 READY 值为 0/3说明 Deployment 对象还未创建就绪因为创建 Deployment 对象是有时间间断的这时我们可以通过查看 Deployment 上线状态进一步来了解创建信息。1. 要查看 Deployment 上线状态kubectl rollout status deployment/nginx-deployment输出类似信息Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment nginx-deployment successfully rolled out遇到上述情况我们再等待一段时间再次查看 Deployment 对象是否创建成功。1. 再次查看 Deployment 对象kubectl get deployments输出如下信息NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s此时 Deployment 已创建全部三个副本并且所有副本都是最新的它们包含最新的 Pod 模板 并且可用。1. 查看 Deployment 对象创建的 ReplicaSetkubectl get rs如果 RS 对象创建成功输出如下信息NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18sReplicaSet 输出中包含以下字段• NAME列出名字空间中 ReplicaSet 的名称• DESIRED显示应用的期望副本个数即在创建 Deployment 时所定义的值。此为期望状态• CURRENT显示当前运行状态中的副本个数• READY显示应用中有多少副本可以为用户提供服务• AGE显示应用已经运行的时间长度。说明创建的 ReplicaSet 确保总是存在三个 nginx Pod。注意ReplicaSet 的名称始终被格式化为[Deployment名称]-[随机字符串]。其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。查看 Deployment 对象操作 ReplicaSet 创建的 Pod并显示生成的标签kubectl get pods --show-labels输出如下信息NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s appnginx,pod-template-hash3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s appnginx,pod-template-hash3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s appnginx,pod-template-hash3123191453注意Pod 的名称和 ReplicaSet 的名称类似被格式化为[ReplicaSet名称]-[随机字符串]。上面就是创建一个 Deployment 对象的完整过程Deployment 对象创建过程中的调用链如下kubectl Deployment ReplicaSet Pod Container接下来我们来看下 Deployment 更新升级操作。Deployment 更新示例基于上面创建的 Deployment 对象现在需要将 Pod 的镜像更新到 nginx:1.23.1 可以通过下面两种方式更新操作• 方式一kubectl set image deployment/nginx-deployment nginxnginx:1.23.1
deployment nginx-deployment image updated• 方式二kubectl edit deployment/nginx-deployment
deployment nginx-deployment edited修改 Deployment 配置信息将 spec.template.spec.containers[0].image 的值从 nginx:1.14.2 更改为 nginx:1.23.1一旦镜像名或 Pod 定义发生了修改则触发 k8s 系统完成 Deployment 所有运行 Pod 的滚动升级操作。查看 Deployment 的上线状态即更新过程kubectl rollout staus deployment/nginx-deployment输出如下信息Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 old replicas are pending termination...
Waiting for rollout to finish: 2 old replicas are pending termination...
Waiting for rollout to finish: 1 old replicas are pending termination...
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment nginx-deployment successfully rolled out查看已更新的 Deployment 的更多信息• 在 Deployment 上线成功后查看 Deployment 的信息kubectl get deployments输出如下信息NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 36s• 查看 Deployment 通过创建新的 ReplicaSet 并将其扩容到 3 个副本将旧 ReplicaSet 缩容到 0 个副本完成了 Pod 的更新操作kubectl get rs输出 新/旧 RS 的如下信息NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 6s
nginx-deployment-75675f5897 0 0 0 36s• 查看当前运行的 Pod发现名称已经更新了如下信息kubectl get pods输出如下信息NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s• 查看 Deployment 的更多详细信息kubectl describe deployments输出如下信息Name: nginx-deployment
Namespace: default
CreationTimestamp: Thu, 06 Sept 2022 10:56:25 0000
Labels: appnginx
Annotations: deployment.kubernetes.io/revision2
Selector: appnginx
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: appnginxContainers:nginx:Image: nginx:1.23.1Port: 80/TCPEnvironment: noneMounts: noneVolumes: noneConditions:Type Status Reason---- ------ ------Available True MinimumReplicasAvailableProgressing True NewReplicaSetAvailableOldReplicaSets: noneNewReplicaSet: 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 3Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0从上面的创建和更新示例中可以看出通过 Deployment 对象创建的 Pod要更新升级 Pod只需再次更新 Deployment Pod 模板即可。Deployment 操作 Pod 的更新原理仔细看 Deployment kubectl describe deployments 的详细信息25% max unavailable, 25% max surgeDeployment 可确保在更新时仅关闭一定数量的 Pod。默认情况下它确保至少所需 Pod 的 75% 处于运行状态25% max unavailable最大不可用比例为 25%。Deployment 还确保仅所创建 Pod 数量只可能比期望 Pod 副本数量高一点点。默认情况下它可确保启动的 Pod 个数比期望个数最多多出 125%25% max surge最大峰值 25%。Deployment 控制器调整ReplicaSetreplicas 数量时严格通过以下公式来控制发布节奏。(目标副本数-maxUnavailable) 线上 Pod 实际 Ready 副本数 (目标副本数maxSurge)在这个升级过程中Deployment 就能够保证服务不间断的情况下并且副本数量始终维持在用户期望的数量。生产环境中大规模化的应用更新即可平滑地升级不影响业务服务的正常提供。Deployment 是如何完成 Pod 更新的呢仔细观察上面 Deployment 对象创建 更新的过程Pod 的滚动更新如下所示Pod滚动更新在初始创建 Deployment 时系统创建了一个 ReplicaSet (nginx-deployment-75675f5897)并按照用户需求Pod 副本期望数创建了 3 个 Pod 副本。当更新 Deployment 时系统创建了一个新的 ReplicaSet (nginx-deployment-1564180365)并将其 Pod 副本数扩展到 1 然后将旧的 ReplicaSet 缩减为 2。然后系统继续按照相同的更新策略对新旧两个 RS 进行逐个调整。最后新的 RS 运行 3 个新版本的 Pod 副本旧的 RS 的 Pod 副本数量则缩减为 0。Deployment 更新策略在 Deployment 的定义中可以通过 spec.strategy 指定 Pod 的更新策略目前支持两种更新策略• Recreate重建设置 spec.strategy.typeRecreate表示 Deployment 在更新 Pod 时会先杀掉所有正在运行的 Pod然后创建新的 Pod。• RollingUpdate滚动更新设置 spec.strategy.typeRollingUpdate表示 Deployment 会以滚动更新的方式来逐个更新 Pod。同时可以通过设置 spec.strategy.rollingUpdate 下的两个参数maxUnavailable 和 maxSurge来控制滚动更新的过程。下面对 RollingUpdate滚动更新 时的两个主要参数的说明如下• spec.strategy.rollingUpdate.maxUnavailable用于指定 DepIoyment 在更新过程中不可用状态的 Pod 数量的上限。该 maxUnavailable 的数值可以是整数绝对值例如5或 Pod 期望的副本数的百分比例如10%如果被设置为百分比那么系统会先以 向下取整的方式计算出绝对值整数。而当另一个参数 maxSurge 被设置为 0 时maxUnavailable 则必须被设置为绝对数值大于 0 的整数从 Kubernetes v1.6 开始maxUnavailable 的默认值从 1 改为 25%。举例来说当 maxUnavailable 被设置为 30% 时旧的 ReplicaSet 可以在滚动更新开始时立即将副本数缩小到所需副本总数的70%。一旦新的 Pod 创建并准备好旧的 ReplicaSet 会进一步缩容新的 ReplicaSet 又继续扩容整个过程中系统在任意时刻都可以确保可用状态的 Pod 总数至少占 Pod 期望副本总数的 70%。• spec.strategy.rollingUpdate.maxSurge用于指定在 Deployment 更新 Pod 的过程中 Pod 总数超过 Pod期望副本数部分的最大值。该 maxSurge 的数值可以是绝对值例如5或 Pod 期望副本数的百分比例如10%。如果设置为百分比那么系统会先按照 向上取整的方式计算出绝对数值整数从 Kubernetes v1.6 开始maxSurge 的默认值从 1 改为 25%。举例来说当 maxSurge 的值被设置为 30% 时新的 ReplicaSet 可以在滚动更新开始时立即进行副本数扩容只需要保证新旧ReplicaSet 的 Pod 副本数之和不超过期望副本数的 130% 即可。一旦旧的 Pod 被杀掉新的 ReplicaSet 就会进一步扩容。在整个过程中系统在任意时刻都能确保新旧 ReplicaSet 的 Pod 副本总数之和不超过所需副本数的 130%。Deployment 更新注意事项1. 需要注意 多重更新Rollover 的情况。如果 Deployment 的上一次更新正在进行此时用户再次发起 Deployment 的更新操作那么 Deployment 会为每一次更新都创建一个 ReplicaSet而每次在新的 ReplicaSet 创建成功后会逐个增加 Pod 副本数同时将之前正在扩容的 ReolicaSet 停止扩容更新并将其加入旧版本 ReplicaSet 列表中然后开始缩容至 0 的操作。【举例说明】假设我们创建一个 Deployment这个 Deployment 开始创建 5 个 nginx:1.14.2 的 Pod 副本在这个创建 Pod 动作尚未完成时我们又将 Deployment 进行更新在副本数不变的情况下将Pod 模板中的镜像修改为 nginx:1.23.1又假设此时 Deployment 已经创建了 3 个 nginx:1.14.2 的Pod 副本则 Deployment 会立即杀掉已创建的 3 个 nginx:1.14.2 的 Pod并开始创建 nginx:1.23.1 的 PodDenlovment 不会在等待 nginx:1.14.2 的 Pod 创建到 5 个之后再进行更新操作。1. 还需要注意更新 Doployment 的 标签选择器Label Selector 的情况。通常来说不鼓励更新 Doployment 的标签选择器因为这样会导致 Deployment 选择的 Pod 列表发生变化也可能与其他控制器产生冲突。如果一定要更新标签选择器那么请务必谨慎确保不会出现其他问题。Doployment 的标签选择器Label Selector更新注意事项当 Doployment 标签选择器Label Selector更新时需要注意以下几种情况1. 添加选择器标签时。2. 更新标签选择器时。3. 删除标签选择器时。• 1》添加选择器标签时必须同步修改 Deployment 配置的 Pod 的标签为 Pod 添加新的标签否则 Deployment 的更新会报验证错误而失败deployments nainx-deplovment was not valid:
* spec.template.metadata.labels:Invalid value: {app:nginx} : Selector does not match template labels添加标签选择器是无法向后兼容的这意味着新的标签选择器不会匹配和使用旧选择器创建的ReplicaSets 和 Pod因此添加选择器将会导致所有旧版本的 ReplicaSets 和由旧 ReplicaSets 创建的 Pod 处于孤立状态不会被系统自动删除也不受新的 ReplicaSet 控制。通过命令操作为标签选择器和 Pod 模板添加新的标签kubectl edit deployment查看修改后的 ReplicaSet 信息kubectl get rs输出如下信息NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 3s
nginx-deployment-70656f5973 3 3 3 1m
nginx-deployment-73675f8579 0 0 0 53s查看新 RSnginx-deployment-75675f5897 创建的 3 个 Podkubectl get pods• 2》更新标签选择器即更改选择器中标签的键或者值也会产生与添加选择器标签类似的效果。• 3》删除标签选择器即从 Deployment 的标签选择器中删除一个或者多个标签该 Deployment 的 RS 和 Pod 不会受到任何影响。但需要注意被删除的标签仍然会存在现有的 Pod 和 RS 上此时现有的 RS 和 Pod 就会处于孤立状态不会被系统自动删除也不受新的 ReplicaSet 控制。Deployment 回滚有时候我们可能需要将 Deployment 回滚到旧版本比如新的 Deployment 不稳定时。在默认情况下所有 Deployment 的发布记录都被保留在系统中以便于我们随时进行回滚可配置历史记录数据。Deployment 回滚示例举例比如在更新 Deployment 镜像时将镜像名称或版本设置错误一个不存在的镜像。此处我们依然以 Nginx 为例假设 Nginx 的镜像设置成 nginx:1.231正确写法nginx:1.23.1kubectl set image deployment/nginx-deployment nginxnginx:1.231
deployment nginx-deployment image updated则这时 Deployment 的部署过程会卡qia住查看 Deployment 的上线状态更新过程kubectl rollout staus deployment/nginx-deployment输出如下信息Waiting for rollout to finish: 1 out of 3 new replicas have been updated...卡住的原因是设置的 nginx 镜像根本不存在因此需要执行 CtrlC 命令来终止查看更新过程的命令。还可以进一步查看 RS 的状态kubectl get rs在依据上面 RS 的信息具体查看 RS 创建的 Podkubectl get pods输出的信息中会有 STATUS 值为 ImagePullBackOff 的记录此时说明由 RS 创建的该 Pod 被卡在镜像拉取的过程中。为了解决上面描述的问题这时我们就需要回滚到之前稳定版本的 Deployment回滚操作如下1. 查看这个 Deployment 部署的历史记录kubectl rollout history deployment/nginx-deployment输出如下信息deployments nginx-deployment
REVISION CHANGE-CAUSE
1 kubectl create --filenamenginx-deployment.yaml --recordtrue
2 kubectl set image deployment/nginx-deployment nginxnginx:1.23.1
3 kubectl set image deployment/nginx-deployment nginxnginx:1.231说明在创建 Deployment 时使用 --record 参数就可以在 CHANGE-CAUSE 列看到每个版本使用的命令了。另外Deployment 的更新操作是在 Deployment 进行部署Rollout时被触发的这意味着当且仅当 Deployment 的 Pod模板即 spec.template被更改时才会创建新的修订版本例如更新模板标签或容器镜像。其他更新操作如扩展副本数将不会触发 Deployment 的更新操作这也意味着我们将 Deployment 回滚到之前的版本时只有 Deployment 的 Pod 模板部分会被修改。指定版本号 --versionN 参数查看特定版本信息kubectl rollout history deployment/nginx-deployment --version3输出如下信息deployments nginx-deployment with revision #3
Pod Template:Labels: appnginxpod-template-hash3660254250Annotations: kubernetes.io/change-causekubectl set image deployment/nginx-deployment nginxnginx:1.231Containers:nginx: Image: nginx:1.231Port: 80/TCPEnvironment: noneMounts: noneVolumes: none通过上面的详细信息我们可以看到 Image 镜像版本为 nginx:1.231但真实情况是该镜像不存在因此我们撤销本次发布并回滚到上一个部署的版本命令操作如下kubecti rollout undo deployment/nginx-deployment
deployment nginx-deployment rolled back还可以使用 --to-revision 参数指定要回滚的部署版本号kubeetl rollout undo deployment/nginx-deployment --to-revision2
deployment nginx-deployment rolled back通过上面的操作此时 Deployment 就回滚到之前稳定的版本了我们可以从 Deployment 的事件信息中查看回滚版本 2 的操作过程kubectl describe deployment/nginx-deployment这里详细信息就不在展示可自行实践查看 Deployment 的事件回滚信息。Deployment 操作 Pod 的回滚原理通过 Deployment 对象创建的 Pod回滚版本其实和滚动更新是类似的刚好是滚动更新升级的反向过程如下图所示Pod 回滚更新暂停和恢复 Deployment 的部署操作以完成复杂的修改对于复杂的 Deployment 配置修改为了避免频繁触发 Deployment 的更新操作可以先暂停 Deployment 的更新操作然后进行配置修改在恢复 Deployment 一次性触发完整的更新操作就可以避免不必要的 Deployment 更新操作了。暂停 Deployment 的部署操作通过执行如下命令暂停 Deployment 的更新操作kubectl rollout pause deployment/nginx-deployment nginxnginx:1.231
deployment nginx-deployment paused为了验证上面的操作是否有触发新的 Deployment 部署操作我们查看 Deployment 的历史记录kubectl rollout history deployment/nginx-deployment输出如下信息deployments nginx-deployment
REVISION CHANGE-CAUSE
1 kubectl create --filenamenginx-deployment.yaml --recordtrue通过查看历史记录信息并没有发现有触发新的 Deployment 部署操作。在暂停 Deployment 部署之后可以根据需要进行任意次数的配置更新。例如再次配置更新容器的资源限制kubectl set resources deployment nginx-deployment -cnginx --limitscpu200m,memory512Mi
deployment nginx-deployment resource requirements updated除了上面命令行的方式配置更新容器的资源限制也可以通过编辑 Deployment 的 yaml 文件配置k8s 系统中没有刻意强调只能使用其中一种方式依据个人喜好选择对应的操作方式最终达到目的即可。生产环境中我个人更喜欢修改 yaml 配置文件方式操作部署。恢复 Deployment 的部署操作执行如下命令恢复 Deployment 的部署操作kubectl rollout resume deploy nginx-deployment
deployment nginx-deployment resumed再次查看 ReplicaSet 创建信息kubectl get rs输出如下信息NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f6987 3 3 3 6s
nginx-deployment-57675f9876 0 0 0 42s查看 Deployment 更多信息kubectl describe deployment/nginx-deployment注意在恢复暂停的 Deployment 之前无法回滚该 Deployment。对于 ReplicationController简称RC 的滚动更新k8s 提供了一个 kubectl rolling-update 命令进行实现。RC 与 RS/Deployment 相比RC 不具有 Deployment 在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能在 k8s 版本迭代的演进过程中RC 逐渐被 RS 和 Deployment 所取代目前新版本的 k8s 中RC 已经淘汰替代者是 RSk8s 官方推荐优先使用 Deployment 完成 Pod 的部署和升级操作。Pod 其他管理对象的更新策略Kubernetes 从1.6版本开始,对 DaemonSet和 StatefulSet的更新策略也引入类似于Deployment的滚动升级,通过不同的策略自动完成应用的版本升级。DaemonSet 更新策略目前DaemonSet的升级策略包括两种OnDelete 和 RollingUpdate。1. OnDeleteDaemonSet 的默认升级策略与 1.6 及以前版本的 Kubernetes 保持一致。当使用OnDelete 作为升级策略时在创建好新的 DaemonSet 配置之后新的 Pod 并不会被自动创建直到用户手动删除旧版本的 Pod才触发新建操作。2. RollingUndate从 Kubernetes v1.6 版本开始引入。当使用 RollingUpdate 作为升级策略对 DaemonSet 进行更新时旧版本的 Pod 将被自动杀掉然后自动创建新版本的 DaemonSet Pod整个过程与普通 Deployment 的滚动升级一样是可控的。不过有两点不同于普通 Pod 的滚动升级• 一是目前的 Kubernetes 还不支持查看和管理 DaemonSet 的更新历史记录• 二是 DaemonSet 的回滚Rollback并不能如同 Deployment 一样直接通过 kubectl rollback 命令来实现必须通过再次提交就版本配置的方式实现。推荐参考文章• 《对 DaemonSet 执行滚动更新》https://kubernetes.io/zh-cn/docs/tasks/manage-daemon/update-daemon-set/• 《对 DaemonSet 执行回滚》https://kubernetes.io/zh-cn/docs/tasks/manage-daemon/rollback-daemon-set/StatefulSet 更新策略Kubernetes v1.6 版本开始针对 StatefulSet 的更新策略逐渐向 Deployment 和 DaemonSet 的更新策略看齐也将实现 RollingUpdateParitioned 和 OnDelete 这几种策略以保证 StatefulSet 中各 Pod 有序地、逐个更新并且能够保留更新历史也能回滚到某个历史版本。推荐参考文章• 《StatefulSet 更新策略》https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/#update-strategies
