Pod的编排与调度-华为云

云容器引擎 CCE-无状态负载（Deployment）:回滚

回滚回滚也称为回退，即当发现升级出现问题时，让应用回到老的版本。Deployment可以非常方便的回滚到老版本。例如上面升级的新版镜像有问题，可以执行kubectl rollout undo命令进行回滚。 $ kubectl rollout undo deployment nginx deployment.apps/nginx rolled back Deployment之所以能如此容易的做到回滚，是因为Deployment是通过ReplicaSet控制Pod的，升级后之前ReplicaSet都一直存在，Deployment回滚做的就是使用之前的ReplicaSet再次把Pod创建出来。Deployment中保存ReplicaSet的数量可以使用revisionHistoryLimit参数限制，默认值为10。

云容器引擎 CCE Pod的编排与调度

云容器引擎 CCE-无状态负载（Deployment）:升级

升级在实际应用中，升级是一个常见的场景，Deployment能够很方便的支撑应用升级。 Deployment可以设置不同的升级策略，有如下两种。 RollingUpdate：滚动升级，即逐步创建新Pod再删除旧Pod，为默认策略。 Recreate：替换升级，即先把当前Pod删掉再重新创建Pod。 Deployment的升级可以是声明式的，也就是说只需要修改Deployment的YAML定义即可，比如使用kubectl edit命令将上面Deployment中的镜像修改为nginx:alpine。修改完成后再查询ReplicaSet和Pod，发现创建了一个新的ReplicaSet，Pod也重新创建了。 $ kubectl edit deploy nginx $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-6f9f58dffd 2 2 2 1m nginx-7f98958cdf 0 0 0 48m $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m nginx-6f9f58dffd-tesqr 1/1 Running 0 1m Deployment可以通过maxSurge和maxUnavailable两个参数控制升级过程中同时重新创建Pod的比例，这在很多时候是非常有用，配置如下所示。 spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate maxSurge：与Deployment中spec.replicas相比，可以有多少个Pod存在，默认值是25%，比如spec.replicas为 4，那升级过程中就不能超过5个Pod存在，即按1个的步伐升级，实际升级过程中会换算成数字，且换算会向上取整。这个值也可以直接设置成数字。 maxUnavailable：与Deployment中spec.replicas相比，可以有多少个Pod失效，也就是删除的比例，默认值是25%，比如spec.replicas为4，那升级过程中就至少有3个Pod存在，即删除Pod的步伐是1。同样这个值也可以设置成数字。在前面的例子中，由于spec.replicas是2，如果maxSurge和maxUnavailable都为默认值25%，那实际升级过程中，maxSurge允许最多3个Pod存在（向上取整，2*1.25=2.5，取整为3），而maxUnavailable则不允许有Pod Unavailable（向上取整，2*0.75=1.5，取整为2），也就是说在升级过程中，一直会有2个Pod处于运行状态，每次新建一个Pod，等这个Pod创建成功后再删掉一个旧Pod，直至Pod全部为新Pod。

云容器引擎 CCE Pod的编排与调度

云容器引擎 CCE-无状态负载（Deployment）:Deployment如何控制Pod

Deployment如何控制Pod 继续查询Pod，如下所示。 $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-7f98958cdf-tdmqk 1/1 Running 0 13s nginx-7f98958cdf-txckx 1/1 Running 0 13s 如果删掉一个Pod，您会发现立马会有一个新的Pod被创建出来，如下所示，这就是前面所说的Deployment会确保有2个Pod在运行，如果删掉一个，Deployment会重新创建一个，如果某个Pod故障或有其他问题，Deployment会自动拉起这个Pod。 $ kubectl delete pod nginx-7f98958cdf-txckx $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-7f98958cdf-tdmqk 1/1 Running 0 21s nginx-7f98958cdf-tesqr 1/1 Running 0 1s 看到有如下两个名为nginx-7f98958cdf-tdmqk和nginx-7f98958cdf-tesqr的Pod，其中nginx是直接使用Deployment的名称，-7f98958cdf-tdmqk和-7f98958cdf-tesqr是kubernetes随机生成的后缀。您也许会发现这两个后缀中前面一部分是相同的，都是7f98958cdf，这是因为Deployment不是直接控制Pod的，Deployment是通过一种名为ReplicaSet的控制器控制Pod，通过如下命令可以查询ReplicaSet，其中rs是ReplicaSet的缩写。 $ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-7f98958cdf 2 2 2 1m 这个ReplicaSet的名称为nginx-7f98958cdf，后缀-7f98958cdf也是随机生成的。 Deployment控制Pod的方式如图2所示，Deployment控制ReplicaSet，ReplicaSet控制Pod。图2 Deployment通过ReplicaSet控制Pod 如果使用kubectl describe命令查看Deployment的详情，您就可以看到ReplicaSet，如下所示，可以看到有一行NewReplicaSet: nginx-7f98958cdf (2/2 replicas created)，而且Events里面事件确是把ReplicaSet的实例扩容到2个。在实际使用中您也许不会直接操作ReplicaSet，但了解Deployment通过控制ReplicaSet来控制Pod会有助于您定位问题。 $ kubectl describe deploy nginx Name: nginx Namespace: default CreationTimestamp: Sun, 16 Dec 2018 19:21:58 +0800 Labels: app=nginx ... NewReplicaSet: nginx-7f98958cdf (2/2 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 5m deployment-controller Scaled up replica set nginx-7f98958cdf to 2

云容器引擎 CCE Pod的编排与调度

云容器引擎 CCE-无状态负载（Deployment）:创建Deployment

创建Deployment 以下示例为创建一个名为nginx的Deployment负载，使用nginx:latest镜像创建两个Pod，每个Pod占用100m CPU、200Mi内存。 apiVersion: apps/v1 # 注意这里与Pod的区别，Deployment是apps/v1而不是v1 kind: Deployment # 资源类型为Deployment metadata: name: nginx # Deployment的名称 spec: replicas: 2 # Pod的数量，Deployment会确保一直有2个Pod运行 selector: # Label Selector matchLabels: app: nginx template: # Pod的定义，用于创建Pod，也称为Pod template metadata: labels: app: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets: - name: default-secret 从这个定义中可以看到Deployment的名称为nginx，spec.replicas定义了Pod的数量，即这个Deployment控制2个Pod；spec.selector是Label Selector（标签选择器），表示这个Deployment会选择Label为app=nginx的Pod；spec.template是Pod的定义，内容与Pod中的定义完全一致。将上面Deployment的定义保存到deployment.yaml文件中，使用kubectl创建这个Deployment。使用kubectl get查看Deployment和Pod，可以看到READY值为2/2，前一个2表示当前有2个Pod运行，后一个2表示期望有2个Pod，AVAILABLE为2表示有2个Pod是可用的。 $ kubectl create -f deployment.yaml deployment.apps/nginx created $ kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx 2/2 2 2 4m5s

云容器引擎 CCE Pod的编排与调度

云容器引擎 CCE-无状态负载（Deployment）:无状态负载（Deployment）

无状态负载（Deployment） Pod是Kubernetes创建或部署的最小单位，但是Pod是被设计为相对短暂的一次性实体，Pod可以被驱逐（当节点资源不足时）、随着集群的节点崩溃而消失。Kubernetes提供了Controller（控制器）来管理Pod，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力，其中最为常用的就是Deployment。图1 Deployment 一个Deployment可以包含一个或多个Pod副本，每个Pod副本的角色相同，所以系统会自动为Deployment的多个Pod副本分发请求。 Deployment集成了上线部署、滚动升级、创建副本、恢复上线的功能，在某种程度上，Deployment实现无人值守的上线，大大降低了上线过程的复杂性和操作风险。

云容器引擎 CCE Pod的编排与调度

云容器引擎 CCE-普通任务（Job）和定时任务（CronJob）:创建Job

创建Job 以下是一个Job配置，其计算π到2000位并打印输出。Job结束需要运行50个Pod，这个示例中就是打印π 50次，并行运行5个Pod，Pod如果失败最多重试5次。 apiVersion: batch/v1 kind: Job metadata: name: pi-with-timeout spec: completions: 50 # 运行的次数，即Job结束需要成功运行的Pod个数 parallelism: 5 # 并行运行Pod的数量，默认为1 backoffLimit: 5 # 表示失败Pod的重试最大次数，超过这个次数不会继续重试。 activeDeadlineSeconds: 100 # 表示Pod超期时间，一旦达到这个时间，Job及其所有的Pod都会停止。 template: # Pod定义 spec: containers: - name: pi image: perl command: - perl - "-Mbignum=bpi" - "-wle" - print bpi(2000) restartPolicy: Never 根据completions和parallelism的设置，可以将Job划分为以下几种类型。表1 任务类型 Job类型说明使用示例一次性Job 创建一个Pod直至其成功结束数据库迁移固定结束次数的Job 依次创建一个Pod运行直至completions个成功结束处理工作队列的Pod 固定结束次数的并行Job 依次创建多个Pod运行直至completions个成功结束多个Pod同时处理工作队列并行Job 创建一个或多个Pod直至有一个成功结束多个Pod同时处理工作队列

云容器引擎 CCE Pod的编排与调度

云容器引擎 CCE-普通任务（Job）和定时任务（CronJob）:普通任务（Job）和定时任务（CronJob）

普通任务（Job）和定时任务（CronJob） Job和CronJob是负责批量处理短暂的一次性任务（short lived one-off tasks），即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。 Job：是Kubernetes用来控制批处理型任务的资源对象。批处理业务与长期伺服业务（Deployment、StatefulSet）的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出（Pod自动删除）。 CronJob：是基于时间的Job，就类似于Linux系统的crontab文件中的一行，在指定的时间周期运行指定的Job。任务负载的这种用完即停止的特性特别适合一次性任务，比如持续集成。

云容器引擎 CCE Pod的编排与调度

云容器引擎 CCE-普通任务（Job）和定时任务（CronJob）:创建CronJob

创建CronJob 相比Job，CronJob就是一个加了定时的Job，CronJob执行时是在指定的时间创建出Job，然后由Job创建出Pod。 apiVersion: batch/v1 kind: CronJob metadata: name: cronjob-example spec: schedule: "0,15,30,45 * * * *" # 定时相关配置 jobTemplate: # Job的定义 spec: template: spec: restartPolicy: OnFailure containers: - name: pi image: perl command: - perl - "-Mbignum=bpi" - "-wle" - print bpi(2000) CronJob的格式从前到后就是： Minute Hour Day of month Month Day of week 如 "0,15,30,45 * * * * " ，前面逗号隔开的是分钟，后面第一个* 表示每小时，第二个 * 表示每个月的哪天，第三个表示每月，第四个表示每周的哪天。如果您想要每个月的第一天里面每半个小时执行一次，那就可以设置为" 0,30 * 1 * * " 如果您想每个星期天的3am执行一次任务，那就可以设置为 "0 3 * * 0"。更详细的CronJob格式说明请参见https://zh.wikipedia.org/wiki/Cron。

云容器引擎 CCE Pod的编排与调度

云服务器内容精选

Pod的编排与调度

7*24

备案

专业服务

退订

建议反馈

售前咨询热线