简介 本章节主要指导用户在CCE集群上使用bursting插件，快速帮助用户将负载通过插件从CCE集群弹性到CCI上。 CCE突发弹性引擎（对接 CCI）作为一种虚拟的kubelet用来连接Kubernetes集群和其他平台的API。Bursting的主要场景是将Kubernetes API扩展到无服务器的容器平台（如CCI）。 基于该插件，支持用户在短时高负载场景下，将部署在云容器引擎CCE上的无状态负载（Deployment）、有状态负载（StatefulSet）、普通任务（Job）、定时任务（CronJob）四种资源类型的容器实例（Pod），弹性创建到云容器实例CCI服务上，以减少集群扩容带来的消耗。

插件卸载 登录CCE控制台。 选择CCE集群，单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”，进入插件中心首页。 选择“CCE 突发弹性引擎 (对接 CCI)”插件，单击“卸载”。 表2 特殊场景说明 特殊场景描述 场景现象 场景说明 CCE集群无节点，卸载插件。 插件卸载失败。 bursting插件卸载时会在集群中启动Job用于清理资源，卸载插件时请保证集群中至少有一个可以调度的节点。 用户直接删除集群，未卸载插件。 用户在CCI侧的命名空间中有资源残留，如果命名空间有计费资源，会造成额外计费。 由于直接删除集群，没有执行插件的资源清理Job，造成资源残留。用户可以手动清除残留命名空间及其下的计费资源来避免额外计费。

约束与限制 仅支持VPC网络模式的CCE Standard集群和 CCE Turbo 集群。 CCE突发弹性引擎（对接 CCI）插件1.5.37及以下版本不支持Arm集群。如果集群中包含Arm节点，插件实例将不会部署至Arm节点。 集群所在子网不能与10.247.0.0/16重叠，否则会与CCI命名空间下的Service网段冲突，导致无法使用。 Volcano调度器1.17.10及以下版本暂不支持使用Volcano调度器将挂载 云存储 卷的容器实例（Pod）弹性到CCI。 使用CCE集群中的Bursting插件对接CCI 2.0服务，支持配置独享型ELB的Ingress和Service。Bursting插件1.5.5以下版本不支持配置ELB类型的Service。

安装插件 登录CCE控制台。 选择CCE集群，单击进入CCE集群总览页面。 在导航栏左侧单击“插件中心”，进入插件中心首页。 选择“CCE 突发弹性引擎 (对接 CCI)”插件，单击“安装”。 配置插件参数。 表1 插件参数说明 插件参数 说明 选择版本 插件的版本。 规格配置 用于配置插件负载的实例数及资源配额。 选择“系统预置规格”时，您可选择“单实例”或“高可用”规格。 选择“自定义规格”时，您可根据需求修改插件各个组件的副本数以及CPU/内存配置。 说明： CCE 突发弹性引擎 (对接 CCI) 插件在1.5.2及以上版本，将占用更多节点资源，请在升级CCE突发弹性引擎（对接 CCI）插件前预留空间配额。 单实例：需要预留一个节点，节点下至少需要有7个Pod空间配额。若开启网络互通，则需要有8个Pod空间配额。 高可用：需要预留两个节点，节点下至少需要有7个Pod空间配额，共计14个Pod空间配额。若开启网络互通，则需要有8个Pod空间配额，共计16个Pod空间配额。 弹性到CCI的业务量不同时，插件的资源占用也不相同。业务申请的POD、Secret、ConfigMap、PV、PVC会占用虚机资源。建议用户评估自己的业务使用量，按以下规格申请对应的虚机大小：1000pod+1000CM（300KB）推荐2U4G规格节点，2000pod+2000CM推荐4U8G规格节点，4000pod+4000CM推荐8U16G规格节点。 网络互通 开启后，支持CCE集群中的Pod与CCI集群中的Pod通过Kubernetes Service互通，并在插件安装时部署组件proxy。

工作负载下发 登录CCE控制台。 选择CCE集群，单击进入CCE集群总览页面。 在导航栏左侧单击“工作负载”，进入工作负载首页。 单击“创建工作负载”，具体操作步骤详情请参见创建工作负载。 填写基本信息。“CCI弹性承载”选择“强制调度策略”。 进行容器配置。 配置完成后，单击“创建工作负载”。 在工作负载页面，选择工作负载名称，单击进入工作负载管理界面。 工作负载所在节点为CCI集群，说明负载成功已调度到CCI。

问题一：用户负载无法调度到CCI，登录CCE节点执行kubectl get node发现virtual-kubelet节点状态为不可调度。 问题原因：CCI资源售罄导致弹性到CCI的资源调度失败，bursting节点会被锁定半小时（状态变为SchedulingDisabled），期间无法调度至CCI。 解决方案：用户可通过CCE集群控制台，使用kubectl工具查看bursting节点状态，如果节点被锁定，可手动解锁bursting节点。

问题四：插件无法删除 问题场景：因为误修改swr_addr、swr_user导致的插件卸载失败。 问题原因：插件卸载依赖gc-job执行，镜像拉取失败场景gc-job无法运行成功，导致卸载失败。 解决方案：再次进行卸载操作，依次删除gc-job。 插件处于删除失败状态时，先登录至CCE集群配置有kubectl的节点后，再次单击“卸载”。 在210秒内执行以下命令： 删除resource-gc-jobs。 kubectl get job -nkube-system | grep "virtual-kubelet-.*-resource-gc-jobs" kubectl delete job -nkube-system xxx 删除namespace-gc-jobs。 kubectl get job -nkube-system | grep "virtual-kubelet-.*-namespace-gc-jobs" kubectl delete job -nkube-system yyy 其余异常场景请提交工单协助处理。

问题三：插件由1.5.18及以上版本回退至低于1.5.18后，Pod通过Service访问出现异常 问题原因：插件升级到1.5.18及以上版本之后，新弹性到CCI的Pod中的sidecar无法兼容1.5.18以下版本的插件，因此插件回退版本后会导致这些Pod中的Service访问异常。插件在低于1.5.18版本时弹性到CCI的Pod不受影响。 解决方案： 方案一：将插件再升级到1.5.18及以上版本。 方案二：将Service访问异常的Pod删除重建，重建后弹性到CCI的Pod Service访问将恢复正常。

负载Hostpath配置方式 操作场景 在使用CCE或者其他K8s集群时，用户使用HostPath类型存储。但CCI是共享集群，不开放HostPath能力，因此使用HostPath的Pod通过bursting弹到CCI时，会被拦截。如无法改变Pod spec.volumes中配置的HostPath，可通过配置Annotation的形式，允许让使用HostPath的Pod弹性到CCI上，bursting在校验时需要去掉Pod中的HostPath或者将HostPath替换为emptyDir。 约束与限制 EmptyDir的sizeLimit需为1Gi的整数倍，且不能大于Pod CPU核数的10倍。 LocalDir和flexVolume当前暂不支持。 操作步骤 通过在Pod.Annotations中加入注解可以做到hostPath转emptydir。 单个hostPath替换为emptyDir配置方式： "coordinator.cci.io/hostpath-replacement": '[{"name":"source-hostpath-volume-3","policyType":"replaceByEmptyDir","emptyDir":{"sizeLimit":"10Gi"}}]' 单个hostPath忽略： "coordinator.cci.io/hostpath-replacement": '[{"name":"source-hostpath-volume-1","policyType":"remove"}]' 全部HostPath都忽略： "coordinator.cci.io/hostpath-replacement": '[{"name":"*","policyType":"remove"}]' 多个HostPath差异化替换策略： "coordinator.cci.io/hostpath-replacement": '[{"name":"source-hostpath-volume-1","policyType":"remove"},{"name":"source-hostpath-volume-3","policyType":"replaceByEmptyDir","emptyDir":{"sizeLimit":"10Gi"}}]' 对于path为/etc/localtime的HostPath存储，会被单个HostPath替换的策略（策略name为具体的volume name）替换，不会被全部HostPath替换的策略（策略name为"*"）替换。 参考deployment yaml示例： apiVersion: apps/v1 kind: Deployment metadata: annotations: description: '' labels: virtual-kubelet.io/burst-to-cci: enforce appgroup: '' version: v1 name: test namespace: default spec: replicas: 2 selector: matchLabels: app: test version: v1 template: metadata: labels: app: test version: v1 annotations: coordinator.cci.io/hostpath-replacement: '[{"name": "test-log2", "policyType": "remove"}, {"name": "test-log", "policyType": "replaceByEmptyDir", "emptyDir":{"sizeLimit":"10Gi"}}, {"name": "test-log1", "policyType": "remove" }]' spec: containers: - name: container-1 image: nginx imagePullPolicy: IfNotPresent resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi volumeMounts: - name: test-log mountPath: /tmp/log - name: test-log1 mountPath: /tmp/log1 - name: test-log2 mountPath: /tmp/log2 volumes: - hostPath: path: /var/paas/sys/log/virtual-kubelet type: "" name: test-log - hostPath: path: /var/paas/sys/log type: "" name: test-log1 - hostPath: path: /var/paas/sys/log2 type: "" name: test-log2

约束与限制 调度到CCI的实例的存储类型支持ConfigMap、Secret、EmptyDir、DownwardAPI、Projected、PersistentVolumeClaims几种Volume类型，其中Projected和DownwardAPI类型仅bursting 1.3.25版本及以上支持。 EmptyDir：不支持子路径。 PersistentVolumeClaims：只支持SFS、SFS Turbo云存储类型，且只支持使用 CS I类型的StorageClass。1.17.10及以下版本的Volcano调度器不支持调度所有云存储类型。 Projected：如配置了serviceAccountToken类型的source，那么弹性到CCI后挂载的会是对应service-account-token secret中的token，该token为长期有效的token且没有预期受众，即expirationSeconds和audience两项配置不会生效。

支持的存储类型 用户在配置负载存储类型时，CCE的console有如下选项。 弹性CCI的负载对存储类型的支持情况如下： volume类型 是否支持 特殊场景说明 HostPath 否 CCI是共享集群，不直接开放HostPath能力。 1.5.9及以上版本可支持配置path为/etc/localtime的HostPath存储，配置后CCI侧容器中挂载的时区将会与CCE节点的时区一致。 ConfigMap 是 - Secret 是 - EmptyDir 是 挂载EmptyDir不支持子路径。 EmptyDir的sizeLimit需为1Gi的整数倍，且不能大于Pod CPU核数的10倍。 DownwardAPI 是 - Projected 是 如配置了serviceAccountToken类型的source，弹性到CCI后会挂载对应service-account-token secret中的token，该token为长期有效，且token没有预期受众，即expirationSeconds和audience两项配置不会生效。 PersistentVolumeClaims 是 只支持SFS、SFS Turbo云存储类型，且只支持使用CSI类型的StorageClass。

创建CronJob 相比Job，CronJob就是一个加了定时的Job，CronJob执行时是在指定的时间创建出Job，然后由Job创建出Pod。 apiVersion: batch/v1beta1 kind: CronJob metadata: name: cronjob-example namespace: cci-namespace-test1 spec: schedule: "0,15,30,45 * * * *" # 定时相关配置 jobTemplate: # Job的定义 spec: template: spec: restartPolicy: OnFailure containers: - name: main image: pi cron的格式从前到后就是： Minute Hour Day of month Month Day of week 如 "0,15,30,45 * * * * " ，前面逗号隔开的是分钟，后面第一个* 表示每小时，第二个 * 表示每个月的哪天，第三个表示每月，第四个表示每周的哪天。 如果你想要每个月的第一天里面每半个小时执行一次，那就可以设置为" 0,30 * 1 * * " 如果你想每个星期天的3am执行一次任务，那就可以设置为 "0 3 * * 0"。

创建Job 以下是一个Job配置，其计算π到2000位并打印输出。Job结束需要运行50个Pod，这个示例中就是打印π 50次，并行运行5个Pod，Pod如果失败最多重试5次。 apiVersion: batch/v1 kind: Job metadata: name: pi-with-timeout namespace: cci-namespace-test1 spec: completions: 50 # 运行的次数，即Job结束需要成功运行的Pod个数 parallelism: 5 # 并行运行Pod的数量，默认为1 backoffLimit: 5 # 表示失败Pod的重试最大次数，超过这个次数不会继续重试。 activeDeadlineSeconds: 10 # 表示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同时处理工作队列

查询Pod详情 Pod创建完成后，可以使用kubectl get pods命令查询Pod的状态，如下所示。 $ kubectl get pods -n $namespace_name NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 40s 可以看到此处nginx这个Pod的状态为Running，表示正在运行；READY为1/1，表示这个Pod中有1个容器，其中1个容器的状态为Ready。 可以使用kubectl get命令查询具体Pod的配置信息，如下所示，-o yaml表示以YAML格式返回，还可以使用 -o json，以JSON格式返回。 $ kubectl get pod nginx -o yaml -n $namespace_name 您还可以使用kubectl describe命令查看Pod的详情。 $ kubectl describe pod nginx -n $namespace_name

创建Pod kubernetes资源可以使用YAML描述（如果您对YAML格式不了解，可以参考YAML语法），也可以使用JSON，如下示例描述了一个名为nginx的Pod，这个Pod中包含一个名为container-0的容器，使用nginx:alpine镜像，使用的资源为0.5核CPU、1024M内存。 apiVersion: v1 # Kubernetes的API Version kind: Pod # Kubernetes的资源类型 metadata: name: nginx # Pod的名称 spec: # Pod的具体规格（specification） containers: - image: nginx:alpine # 使用的镜像为 nginx:alpine name: container-0 # 容器的名称 resources: # 申请容器所需的资源，云容器实例中limits与requests的值必须相同 limits: cpu: 500m # 0.5核 memory: 1024Mi requests: cpu: 500m # 0.5核 memory: 1024Mi imagePullSecrets: # 拉取镜像使用的证书，必须为imagepull-secret - name: imagepull-secret 如上面YAML的注释，YAML描述文件主要为如下部分： metadata：一些名称/标签/namespace等信息 spec：Pod实际的配置信息，包括使用什么镜像，volume等 如果去查询Kubernetes的资源，您会看到还有一个status字段，status描述kubernetes资源的实际状态，创建时不需要配置。这个示例是一个最小集，其他参数定义后面会逐步介绍。 Pod定义好后就可以使用kubectl创建，如果上面YAML文件名称为nginx.yaml，则创建命令如下所示，-f 表示使用文件方式创建。 $ kubectl create -f nginx.yaml -n $namespace_name pod/nginx created