命令记不住

登陆

k8s 资源对象 deployment

  |   0 浏览

05.k8s资源对象deployment

1.简介

Pod 模板 template 中所述，这个 template 它其实包含了两部分内容：

  • 一部分是我们期望 Pod 的 metadata，其中包含了 labels，即跟 selector.matchLabels 相匹配的一个 Labels；
  • 第二部分是 template 包含的一个 Pod.spec。这里 Pod.spec 其实是 Deployment 最终创建出来 Pod 的时候，它所用的 Pod.spec，这里定义了一个 container.nginx，它的镜像版本是 nginx:1.7.9。

功能：

  • 定义一组Pod的期望数量，controller会维持Pod数量与期望数量一致
  • 配置Pod发布方式，controller会按照给定策略更新Pod,保证更新过程中不可用的pod数量在限定范围内
  • 如果发布有问题，支持一键回滚
1.更新镜像
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
kubectl edit deployment/nginx-deployment
2.快速回滚
kubectl  rollout undo  deployment nginx=nginx:1.9.1

.

2.spec字段解析

Deployment 中其他的 spec 字段：

  • MinReadySeconds
Deploymen会根据Pod read来看Pod是否可用，但是如果我们设置了MinReadySeconds之后，比如设置为30秒，那Deployment就一定会等到Pod ready超过30秒之后才认为Pod是available的。Pod available的前提条件是Pod ready，但是ready的Pod不一定是 available的，它一定要超过MinReadySeconds之后，才会判断为 available；
  • revisionHistoryLimit
保留历史revision即保留历史ReplicaSet的数量，默认值为10个。这里可以设置为1个或2个，如果回滚可能性比较大的话，可以设置数量超过 10；
  • paused
paused 是标识，Deployment 只做数量维持，不做新的发布，这里在 Debug 场景可能会用到；
  • progressDeadlineSeconds
前面提到当Deployment处于扩容或者发布状态时，它的condition会处于一个 processing 的状态，processing 可以设置一个超时时间。如果超过超时时间还处于 processing，那么 controller 将认为这个 Pod 会进入 failed 的状态。

升级策略字段解析

# Deployment 在 RollingUpdate 中主要提供了两个策略，一个是 MaxUnavailable，另一个是 MaxSurge。这两个字段解析的意思，可以看下图中详细的 comment，或者简单解释一下：

MaxUnavailable：滚动过程中最多有多少个 Pod 不可用；
MaxSurge：滚动过程中最多存在多少个 Pod 超过预期 replicas 数量。

.

3.DeploymeStatus

deploymentStatus 中描述的三个其实是它的 conversion 状态，也就是 Processing、Complete 以及 Failed

如果在处理过程中遇到一些问题：比如说拉镜像失败了，或者说 readiness probe 检查失败了，就会进入 failed 状态；如果在运行过程中即 complete 状态，中间运行时发生了一些 pod readiness probe 检查失败，这个时候 deployment 也会进入 failed 状态。进入 failed 状态之后，除非所有点 replicas 均变成 available，而且是 updated 最新版本，deployment 才会重新进入 complete 状态。

4.升级控制器

1个deployment

2个replicaSet

#kubectl get rs
NAME                DESIRED   CURRENT   READY   AGE
nginx-58f8c48d58    5         5         5       5d18h
nginx-6799fc88d8    0         0         0       7d4h
预期  当前  就绪

3.历史发布版本

kubectl rollout history deployment web

4.回滚版本

上一个版本

kubectl rollout undo deployment web

指定回滚版本

kubectl rollout undo deployment web  --to-revision=2

5.变更标记

kubectl set image deployment/web  nginx=nginx:1.9.1  --record=true

kubectl rollout history deployment web
deployment.apps/web-01 
REVISION  CHANGE-CAUSE
5         <none>
6         <none>
7         kubectl set image deployment/web nginx=nginx:1.16 --record=true

.

5.确认回滚历史版本

1.查询升级历史

#kubectl rollout history deployment web-01
deployment.apps/web-01 
REVISION  CHANGE-CAUSE
5         <none>
6         <none>
7         kubectl set image deployment/web-01 nginx=nginx:1.16 --record=true

2.查询rs版本记录

#kubectl get rs
NAME                DESIRED   CURRENT   READY   AGE
nginx-58f8c48d58    5         5         5       5d19h
nginx-6799fc88d8    0         0         0       7d5h
web-01-56d74f4bcb   10        10        10      133m
web-01-68b6ccfbfb   0         0         0       31m
web-01-68fd7dc6bf   0         0         0       64m
web-02-56f866c4bc   5         5         5       133m

3.查询rs升级记录

#kubectl describe rs web-01-68fd7dc6bf  |  grep rev
             deployment.kubernetes.io/revision: 5
             deployment.kubernetes.io/revision-history: 2
#kubectl describe rs web-01-68fd7dc6bf
Name:           web-01-68fd7dc6bf
Namespace:      default
Selector:       app=web-01,pod-template-hash=68fd7dc6bf
Labels:         app=web-01
             pod-template-hash=68fd7dc6bf
Annotations:    deployment.kubernetes.io/desired-replicas: 10
             deployment.kubernetes.io/max-replicas: 13
             deployment.kubernetes.io/revision: 5
             deployment.kubernetes.io/revision-history: 2
Controlled By:  Deployment/web-01

.

6.水平扩容

kubectl scale deployment web --replicas=10
kubectl scale deployment web --replicas=5

.

推荐阅读