华为云用户手册

资源监控指标 表1 资源监控指标 监控指标 指标含义 CPU分配率 分配给工作负载使用的CPU占比。 内存分配率 分配给工作负载使用的内存占比。 CPU使用率 CPU使用率。 内存使用率 内存使用率。 磁盘使用率 磁盘使用率。 下行速率 一般指从网络下载数据到节点的速度，单位KB/s。 上行速率 一般指从节点上传网络的速度，单位KB/s。 磁盘读取速率 每秒从磁盘读出的数据量，单位KB/s。 磁盘写入速率 每秒写入磁盘的数据量，单位KB/s。

查看节点监控数据 除了在集群监控界面查看节点监控数据外，您还可以在节点控制台查看节点监控数据，在节点所在行单击“监控”即可查看。 节点控制台还展示了节点可分配资源的数据。可分配资源按照实例请求值（Request）计算，表示实例在该节点上可请求的资源上限，不代表节点实际可用资源。 计算公式为： 可分配CPU = CPU总量 - 所有实例的CPU请求值 - 其他资源CPU预留值 可分配内存 = 内存总量 - 所有实例的内存请求值 - 其他资源内存预留值

配置含义 在CPU配额和内存配额设置中，申请与限制的含义如下： 勾选“申请”表示启动该配置，系统根据申请值调度该实例到满足条件的节点去部署工作负载。 不勾选“申请”表示系统调度实例到随机的一个节点去部署工作负载。 勾选“限制”表示启动该配置，根据设定的值，限制工作负载使用的资源。 不勾选“限制”表示实例使用的资源不做限制，但若实例使用的内存资源超过节点可分配内存时，可能会导致工作负载不可用或者节点不可用。 创建工作负载时，建议设置CPU和内存的资源上下限。同一个节点上部署的工作负载，对于未设置资源上下限的工作负载，如果其异常资源泄露会导致其它工作负载分配不到资源而异常。未设置资源上下限的工作负载，工作负载监控信息也会不准确。

使用示例 以集群包含一个资源为4Core 8GB的节点为例，已经部署一个包含两个实例的工作负载到该集群上，并设置两个实例（实例1，实例2）的资源为{CPU申请，CPU限制，内存申请，内存限制}={1Core，2Core，2GB，2GB}。 那么节点上CPU和内存的资源使用情况如下： 节点CPU可分配量=4Core-（实例1申请的1Core+实例2申请的1Core）=2Core 节点内存可分配量=8GB-（实例1申请的2GB+实例2申请的2GB）=4GB 因此节点还剩余2Core 4GB的资源可供下一个新增的实例使用。

约束与限制 创建节点过程中会使用域名方式从OBS下载软件包，需要能够使用云上内网DNS解析OBS域名，否则会导致创建不成功。为此，节点所在子网需要配置为内网 DNS地址 ，从而使得节点使用内网DNS。在创建子网时DNS默认配置为内网DNS，如果您修改过子网的DNS，请务必确保子网下的DNS服务器可以解析OBS服务域名，否则需要将DNS改成内网DNS。 单Region下单用户可创建的集群总数限制为50个，如果配额不满足业务需求，请到“我的配额”提交申请。 目前鲲鹏集群暂时不支持obsfs，无法挂载并行文件系统。

相关操作 通过命令行工具连接集群：请参见通过kubectl连接集群。 添加节点：集群创建完成后，若您需要为集群添加更多节点，请参见购买节点。 登录节点：请参见登录节点。 创建命名空间：同个集群内可创建多个命名空间，形成逻辑上的不同分组，便于不同的分组在共享使用集群资源时还能被分别管理。若您需要为集群创建命名空间，请参见命名空间。 创建工作负载：集群创建完成后，您可以使用镜像创建一个可公网访问的应用，请参见创建无状态负载(Deployment)或创建有状态负载(StatefulSet)。 单击已成功创建的集群名称，进入“集群详情”页可查看集群详情。 表2 已创建的集群详情 页签类别 说明 集群详情 可查看该集群的详情及运行状态等。 监控 可查看集群下全部节点的CPU和内存分配率（即分配量的最大值），以及控制节点的CPU和内存使用率、控制节点规格等信息。 事件 可以直接在“事件”页签下查看集群的事件。 可以设置查询条件，比如设置事件产生的时间段或搜索事件名称，查看相关事件。 说明： 由于版本更新演进，旧版Console不再支持查看新集群的事件，请前往新版Console使用。 弹性扩容 您可以根据实际业务需要对集群的工作节点进行扩容和缩容，详情请参见集群弹性扩容。 v1.17版本的集群不再支持 AOM 提供的弹性伸缩机制，请使用节点池功能进行弹性伸缩，详情请参见节点池概述。 kubectl 若您需要从客户端计算机连接到kubernetes集群，请使用kubernetes命令行客户端kubectl，详情请参见通过kubectl连接集群。 资源标签 通过为资源添加标签，可以对资源进行自定义标记，实现资源的分类。 您可以在TMS中创建“预定义标签”，预定义标签对所有支持标签功能的服务资源可见，通过使用预定义标签可以提升标签创建和迁移效率。具体请参见创建预定义标签。 CCE服务会自动帮您创建CCE-Dynamic-Provisioning-Node=节点id的标签，允许增加5个标签。 Istioctl 在集群开启istio服务网格功能后，您使用Istio命令行工具Istioctl配置多种路由策略，从而管理服务流量，包括流量转移、故障注入、限流熔断等。详情请参见启用istio。

操作场景 普通任务是一次性运行的短任务，部署完成后即可执行。正常退出（exit 0）后，任务即执行完成。 普通任务是用来控制批处理型任务的资源对象。批处理业务与长期伺服业务（Deployment、Statefulset）的主要区别是： 批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同，即： 单Pod型任务有一个Pod成功就标志完成。 定数成功型任务保证有N个任务全部成功。 工作队列型任务根据应用确认的全局成功而标志成功。

使用kubectl创建Job Job的配置参数如下所示。 spec.template格式与Pod相同。 RestartPolicy仅支持Never或OnFailure。 单个Pod时，默认Pod成功运行后Job即结束。 .spec.completions表示Job结束需要成功运行的Pod个数，默认为1。 .spec.parallelism表示并行运行的Pod的个数，默认为1。 spec.backoffLimit表示失败Pod的重试最大次数，超过这个次数不会继续重试。 .spec.activeDeadlineSeconds表示Pod运行时间，一旦达到这个时间，Job即其所有的Pod都会停止。且activeDeadlineSeconds优先级高于backoffLimit，即到达activeDeadlineSeconds的Job会忽略backoffLimit的设置。 根据.spec.completions和.spec.Parallelism的设置，可以将Job划分为以下几种类型。 表4 任务类型 Job类型 说明 使用示例 一次性Job 创建一个Pod直至其成功结束 数据库迁移 固定结束次数的Job 依次创建一个Pod运行直至completions个成功结束 处理工作队列的Pod 固定结束次数的并行Job 依次创建多个Pod运行直至completions个成功结束 多个Pod同时处理工作队列 并行Job 创建一个或多个Pod直至有一个成功结束 多个Pod同时处理工作队列 以下是一个Job配置示例，保存在myjob.yaml中，其计算π到2000位并打印输出。 apiVersion: batch/v1kind: Jobmetadata: name: myjobspec: completions: 50 # Job结束需要运行50个Pod，这个示例中就是打印π 50次 parallelism: 5 # 并行5个Pod backoffLimit: 5 # 最多重试5次 template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never 说明： apiVersion: batch/v1 是当前job的Version kind: Job：指定当前资源的类型时Job restartPolicy: Never：是指当前的重启策略。对于Job，只能设置为Never或者OnFailure。对于其他controller（比如Deployment）可以设置为Always。 运行该任务，如下： 启动这个job。 [root@k8s-master k8s]# kubectl apply -f myjob.yamljob.batch/myjob created 查看这个job。 kubectl get job [root@k8s-master k8s]# kubectl get jobNAME COMPLETIONS DURATION AGEmyjob 50/50 23s 3m45s completions为 50/50 表示成功运行了这个job。 查看pod的状态。 kubectl get pod [root@k8s-master k8s]# kubectl get podNAME READY STATUS RESTARTS AGEmyjob-29qlw 0/1 Completed 0 4m5s... 状态为Completed表示这个job已经运行完成。 查看这个pod的日志。 kubectl logs # kubectl logs myjob-29qlw3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901

操作场景 配置项（ConfigMap）是一种用于存储工作负载所需配置信息的资源类型，内容由用户决定。配置项创建完成后，可在容器工作负载中作为文件或者环境变量使用。 配置项允许您将配置文件从容器镜像中解耦，从而增强容器工作负载的可移植性。 配置项价值如下： 使用配置项功能可以帮您管理不同环境、不同业务的配置。 方便您部署相同工作负载的不同环境，配置文件支持多版本，方便您进行更新和回滚工作负载。 方便您快速将您的配置以文件的形式导入到容器中。

使用kubectl创建配置项 请参见通过kubectl连接集群配置kubectl命令。 创建并编辑cce-configmap.yaml文件。 vi cce-configmap.yaml apiVersion: v1kind: ConfigMapmetadata: name: cce-configmapdata: SPECIAL_LEVEL: Hello SPECIAL_TYPE: CCE 创建配置项。 kubectl create -f cce-configmap.yaml kubectl get cm NAME DATA AGEcce-configmap 3 3hcce-configmap1 3 7m

Secret资源文件配置说明 本章节主要介绍Secret类型的资源描述文件的配置示例。 例如现在有一个工作负载需要获取帐号密码，可以通过Secret来实现： yaml文件格式 定义的Secret文件secret.yaml内容如下。其中Value需要用Base64，Base64编码方法请参见如何进行Base64编码。 apiVersion: v1kind: Secretmetadata: name: mysecret # secret的名称 namespace: default #命名空间，默认为defaultdata: username: ****** #需要用Base64编码 password: ****** #需要用Base64编码type: Opaque # type建议不要做修改

使用kubectl创建密钥 请参见通过kubectl连接集群配置kubectl命令。 通过Base64编码，创建并编辑cce-secret.yaml文件。 # echo -n "待编码内容" | base64****** vi cce-secret.yaml apiVersion: v1kind: Secretmetadata: name: mysecrettype: Opaquedata: username: ****** password: ****** 创建密钥。 kubectl create -f cce-secret.yaml 创建完成后可以查询到密钥。 kubectl get secret

相关操作 密钥创建完成后，您还可以执行表2中的操作。 密钥列表中包含系统密钥资源，系统密钥资源不可更新，也不能删除，只能查看。 表2 其他操作 操作 说明 查看YAML 单击密钥名称后的“查看YAML”，可查看到当前密钥的YAML文件。 更新密钥 选择需要更新的密钥名称，单击“更新”。 根据表1更改信息。 单击“更新”。 删除密钥 选择要删除的密钥，单击“删除”。 根据系统提示删除密钥。 批量删除密钥 勾选需要删除的密钥名称。 单击页面左上角的“删除”，删除选中的密钥。 根据系统提示删除密钥。

工作负载创建时设置 您可以在创建工作负载时通过控制台设置Service访问方式，本节以nginx为例进行说明。 参考创建无状态负载(Deployment)、创建有状态负载(StatefulSet)或创建守护进程集(DaemonSet)，在“工作负载访问设置”步骤，单击“添加服务”。 访问类型：选择“节点访问 ( NodePort )”。 如果需要使用弹性IP通过公网访问该服务，请提前在集群的节点上绑定弹性IP。 Service名称：自定义服务名称，可与工作负载名称保持一致。 服务亲和：详情请参见externalTrafficPolicy（服务亲和）。 集群级别：集群下所有节点的IP+访问端口均可以访问到此服务关联的负载，服务访问会因路由跳转导致一定性能损失，且无法获取到客户端源IP。 节点级别：只有通过负载所在节点的IP+访问端口才可以访问此服务关联的负载，服务访问没有因路由跳转导致的性能损失，且可以获取到客户端源IP。 IPv6：默认不开启，开启后服务的集群内IP地址（ClusterIP）变为IPv6地址，具体请参见如何通过CCE搭建IPv4/IPv6双栈集群？。该功能仅在1.15及以上版本的集群创建时开启了IPv6功能才会显示。 端口配置： 协议：请根据业务的协议类型选择。 容器端口：容器镜像中工作负载实际监听的端口，取值范围为1-65535。 访问端口：容器端口映射到节点私有IP上的端口，建议选择“自动生成”。 自动生成：系统会自动分配端口号。 指定端口：指定固定的节点端口，默认取值范围为30000-32767。若指定端口时，请确保同个集群内的端口唯一性。 完成配置后，单击“确定”。 单击“下一步：高级设置”进入高级设置页面，直接单击“创建”。 单击“查看工作负载详情”，在访问方式页签下获取访问地址，例如“192.168.0.160:30358”。

约束与限制 “节点访问 ( NodePort )”默认为VPC内网访问，如果需要使用弹性IP通过公网访问该服务，请提前在集群的节点上绑定弹性IP。 创建service后，如果服务亲和从集群级别切换为节点级别，连接跟踪表将不会被清理，建议用户创建service后不要修改服务亲和属性，如需修改请重新创建service。 通过控制台创建的NodePort类型Service，Service端口与设置的容器端口一致。 CCE Turbo 集群仅支持集群级别服务亲和。

externalTrafficPolicy（服务亲和） NodePort类型的Service接收请求时先从访问到节点，然后转到Service，再由Service选择一个Pod转发到该Pod，选择的Pod不一定在接收请求的节点上。默认情况下，从任意节点IP+服务端口都能访问到后端工作负载，当Pod不在接收请求的节点上时，请求会在跳转到Pod所在的节点，带来一定性能损失。 Service有一个配置参数externalTrafficPolicy，如下所示。 apiVersion: v1kind: Servicemetadata: name: nginx-nodeportspec: externalTrafficPolicy: local ports: - name: service nodePort: 30000 port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: NodePort 当externalTrafficPolicy取值为local时，通过节点IP:服务端口的请求只会转发给本节点上的Pod，如果节点没有Pod的话请求会挂起。 externalTrafficPolicy还有一个取值是cluster，也是默认取值，就是前面说的请求会在集群内转发。 在CCE 控制台创建NodePort类型Service时也可以配置该参数。 总结externalTrafficPolicy两个取值。 cluster（集群级别）：集群下所有节点的IP+访问端口均可以访问到此服务关联的负载，服务访问会因路由跳转导致一定性能损失，且无法获取到客户端源IP。 local（节点级别）：只有通过负载所在节点的IP+访问端口才可以访问此服务关联的负载，服务访问没有因路由跳转导致的性能损失，且可以获取到客户端源IP。

部署命令 rolling-update* rolling-update是一个非常重要的命令，对于已经部署并且正在运行的业务，rolling-update提供了不中断业务的更新方式。rolling-update每次起一个新的pod，等新pod完全起来后删除一个旧的pod，然后再起一个新的pod替换旧的pod，直到替换掉所有的pod。rolling-update需要确保新的版本有不同的name，Version和label，否则会报错 。 kubectl rolling-update poname -f newfilenamekubectl rolling-update poname -image=image:v2 如果在升级过程中，发现有问题可以中途停止update，并回滚到前面版本。 kubectl rolling-update poname -rollback rollout 管理资源的发布。 例如： 查看指定资源的部署状态： kubectl rollout status deployment/deployname 查看指定资源的发布历史： kubectl rollout history deployment/deployname 回滚指定资源，默认回滚至上一个版本： kubectl rollout undo deployment/test-nginx scale scale用于程序在负载加重或缩小时将副本进行扩容或缩小。 kubectl scale deployment deployname --replicas=newnumber autoscale autoscale命令提供了自动根据pod负载对其副本进行扩缩的功能。autoscale命令会给一个rc指定一个副本数的范围，在实际运行中根据pod中运行的程序的负载自动在指定的范围内对pod进行扩容或缩容。 kubectl autoscale deployment deployname --min=minnumber --max=maxnumber

集群管理命令 cordon、drain、uncordon* 有时候会遇到这样一个场景，一个node需要升级，但是在该node上又有许多运行的pod，或者该node已经瘫痪，需要保证功能的完善，则需要使用这组命令，使用步骤如下： 使用cordon命令将一个node标记为不可调度。这意味着新的pod将不会被调度到该node上。 kubectl cordon nodename 备注：CCE中nodename为节点私网IP。 使用drain命令，将运行在该node上运行的pod平滑的搬迁到其他节点上。 kubectl drain nodename --ignore-daemonsets --ignore-emptydir 备注：ignore-emptydir为用户挂载空目录的数据。 对该节点进行一些节点维护的操作，如升级内核、升级Docker等。 节点维护完后，使用uncordon命令解锁该node，使其重新变得可调度。 kubectl uncordon nodename cluster-info 查看在集群中运行的插件： kubectl cluster-info 查看详细信息： kubectl cluster-info dump top* 显示资源（CPU/Memory/Storage）使用。需要Heapster运行。 taint* 修改一个或多个节点上的taint。 certificate* 修改证书资源。

高级命令 replace replace命令用于对已有资源进行更新、替换。当需要更新resource的一些属性的时候，如果修改副本数量，增加、修改label，更改image版本，修改端口等。都可以直接修改原yaml文件，然后执行replace命令。 kubectl replace -f filename 名字不能被更新。 apply* apply命令提供了比patch，edit等更严格的更新resource的方式。通过apply，用户可以将resource的configuration使用source control的方式维护在版本库中。每次有更新时，将配置文件推送到server，然后使用kubectl apply将更新应用到resource。kubernetes会在引用更新前将当前配置文件中的配置同已经应用的配置做比较，并只更新更改的部分，而不会主动更改任何用户未指定的部分。apply命令的使用方式同replace相同，不同的是，apply不会删除原有resource，然后创建新的。apply直接在原有resource的基础上进行更新。同时kubectl apply还会在resource中添加一条注释，标记当前的apply，类似于git操作。 kubectl apply -f patch 如果一个容器已经在运行，这时需要对一些容器属性进行修改，又不想删除容器，或不方便通过replace的方式进行更新。kubernetes还提供了一种在容器运行时，直接对容器进行修改的方式，就是patch命令。 例如已存在一个pod的label为app=nginx1，如果需要在运行过程中，将其修改为app=nginx2。 kubectl patch pod podname -p '{"metadata":{"labels":{"app":"nginx2"}}}' convent* 不同的api版本之间转换配置文件。

使用Kubernetes官方模板包 访问https://artifacthub.io/，获取需要的社区模板包。 登录Linux机器。 上传1中获取到的模板包。 执行如下命令，压缩模板包。 若Linux机器没有安装Helm客户端，则执行如下命令。 tar pzcf {name}-{version}.tgz {name}/ 其中， {name}替换为实际的模板包名。 {version}实际的模板包版本号。 {name}和{version}必须与模板包中Chart.yaml中所写的name和version相同。 若Linux机器已安装Helm客户端，则执行如下命令。 helm package {name}/ 其中，将{name}替换为实际的模板包名。 按照模板包规范的要求设置模板包目录结构和命名模板包。

验证插件 插件安装完成后，在GPU节点及调度了GPU资源的容器中执行nvidia-smi命令，验证GPU设备及驱动的可用性。 GPU节点： # 插件版本为2.0.0以下时，执行以下命令：cd /opt/cloud/cce/nvidia/bin && ./nvidia-smi# 插件版本为2.0.0及以上时，驱动安装路径更改，需执行以下命令：cd /usr/local/nvidia/bin && ./nvidia-smi 容器： cd /usr/local/nvidia/bin && ./nvidia-smi 若能正常返回GPU信息，说明设备可用，插件安装成功。

获取驱动链接-公网地址 登录CCE控制台。 创建节点，在节点规格处选择要创建的GPU节点，选中后下方显示的信息中可以看到节点的GPU显卡型号。 图1 查看显卡型号 登录到https://www.nvidia.com/Download/Find.aspx?lang=cn网站。 如图2所示，在“NVIDIA驱动程序下载”框内选择对应的驱动信息。其中“操作系统”必须选Linux 64-bit。 图2 参数选择 驱动信息确认完毕，单击“搜索”按钮，会跳转到驱动信息展示页面，该页面会显示驱动的版本信息如图3，单击“下载”到下载页面。 图3 驱动信息 获取驱动软件链接方式分两种： 方式一：如图4，在浏览器的链接中找到路径为url=/tesla/396.37/NVIDIA-Linux-x86_64-396.37.run的路径，补齐全路径https://us.download.nvidia.com/tesla/396.37/NVIDIA-Linux-x86_64-396.37.run该方式节点需要绑定EIP 。 方式二：如图4，单击“下载”按钮下载驱动，然后上传到OBS，获取软件的链接，该方式节点不需要绑定EIP。 图4 获取链接

卸载插件 在CCE控制台，单击左侧导航栏的“插件管理”，在“插件实例”页签下，选择对应的集群，单击virtual kubelet下的“卸载”。 在弹出的窗口中，单击“确认”，可卸载该插件。（卸载插件会自动删除CCI侧的所有资源，以确保不会有资源残留造成额外计费） 如果在未卸载virtual-kubelet插件的情况下直接删除集群，CCI侧的资源不会被自动清理，会导致CCI侧资源残留，可能会造成额外计费。因此请确保完成以下任意一操作。 在删除集群前先卸载virtual-kubelet插件。 在直接删除集群后登录CCI控制台删除名为cce-burst-${CLUSTER_ID}的命名空间。 集群休眠时CCI侧正在运行的实例不会自动停止，会持续运行并计费。因此如不需要实例继续运行，请确保在集群休眠前将弹性到CCI的负载实例数缩至0。

约束与限制 gpu-beta插件仅在部分区域可用。 仅支持在v1.11及以上版本的CCE集群中安装本插件，暂不支持鲲鹏集群。 集群中使用GPU节点时必须安装gpu-beta插件。 下载的驱动必须是后缀为“.run”的文件。 仅支持Tesla驱动，不支持GRID驱动。 如果下载链接为公网地址，如nvidia官网地址https://us.download.nvidia.com/tesla/396.37/NVIDIA-Linux-x86_64-396.37.run，各GPU节点均需要绑定EIP。获取驱动链接方法请参考获取驱动链接-公网地址。 若下载链接为OBS上的链接，无需绑定EIP 。获取驱动链接方法请参考获取驱动链接-OBS地址。 请确保Nvidia驱动版本与GPU节点适配。 更改驱动版本后，需要重启节点才能生效。

安装插件 登录CCE控制台，在左侧导航栏中选择“插件管理”。在“插件市场”页签下，单击gpu-beta插件下的“安装插件”。 在安装插件页面，选择安装的集群和插件版本，单击“下一步：规格配置”。 在规格配置页面，配置驱动链接地址。 单击“安装”，安装gpu-beta插件的任务即可提交成功。 待插件安装完成后，单击“返回”，在“插件实例”页签下，选择对应的集群，可查看到运行中的实例，这表明该插件已在当前集群中各GPU节点上安装。

升级插件 登录CCE控制台，在左侧导航栏中选择“插件管理”，在“插件实例”页签下，选择对应的集群，单击“virtual-kubelet”下的“升级”。 如果升级按钮处于冻结状态，则说明当前插件版本是最新的版本，不需要进行升级操作。 升级“virtual-kubelet”插件时，会替换原先节点上的旧版本的“virtual-kubelet”插件，安装最新版本的“virtual-kubelet”插件以实现功能的快速升级。 在基本信息页面选择插件版本，单击“下一步”。 参考安装插件中参数说明配置参数后，单击“升级”即可升级“virtual-kubelet”插件。

Virtual Kubelet可分配资源监控影响说明 安装Virtual Kubelet插件后，从监控的角度，相当于引入一个超大节点，此时在CCE集群监控界面上可分配资源使用率会把CCI的资源放在一起计算。如下所示，刚安装Virtual Kubelet插件后，CPU/内存的可分配率剧烈下降。 图3 集群监控 您可以在节点管理界面或AOM中查看具体节点的分配率。 图4 查看节点可分配资源 图5 在AOM中查看节点资源可分配率

资源自动规整 对弹性到CCI的Pod，若其配置的资源规格不满足CCI容器规范，virtual-kubelet会自动尝试将Pod资源向上规整到满足CCI容器规范的范围，以规整后的资源规格创建Pod到CCI。 自动规整规则如下： 将Pod中除了BestEffort类型容器外的每个容器CPU向上调整至0.25核的整数倍， Memory向上调整至大于等于0.2Gi。 将整个Pod的Memory向上调整至1Gi的整数倍。 若Pod Memory/CPU的比值小于2，则将Pod Memory向上调整至大于等于CPU的2倍，且满足是1Gi的整数倍；若Pod Memory/CPU的比值大于8，则将Pod CPU向上调整至大于等于Memory的1/8，且满足是0.25核的整数倍。 若向上调整之后，CPU超过32核或Memory超过256Gi，则矫正失败，拒绝创建请求。 以上对Pod级别资源向上调整造成的增量CPU和Memory，全部添加到Pod中第一个不为BestEffort的容器上。

约束及限制 仅支持VPC网络模式的CCE集群和CCE Turbo集群（virtual-kubelet 1.2.5版本及以上支持），且仅支持1.21及以下集群。 调度到CCI的实例的存储类型只支持ConfigMap、Secret、emptyDir、SFS、SFS Turbo几种Volume类型，其中emptyDir不支持子路径，且SFS、SFS Turbo类型存储对应的PVC只支持使用 CS I类型的StorageClass。 暂不支持守护进程集（DaemonSet）以及HostNetwork网络模式的容器实例（Pod）弹性到CCI。 跨CCE和CCI实例Service网络互通只支持集群内访问（ClusterIP）类型。 跨CCE和CCI实例，在对接LoadBalancer或Ingress时，禁止指定健康检查端口： 1. 在CCE集群下，由于CCI的容器与CCE的容器在ELB注册的后端使用端口不一致，指定健康检查端口会导致部分后端健康检查异常。 2. 跨集群使用Service对接同一个ELB的监听器时，需确认健康检查方式，避免服务访问异常。 集群所在子网不能与10.247.0.0/16重叠，否则会与CCI命名空间下的Service网段冲突，导致无法使用。 使用插件前需要用户在CCI界面对CCI服务进行授信。 安装virtual-kubelet插件后会在CCI服务新建一个名为"cce-burst-"+集群ID的命名空间，该命名空间完全由virtual-kubelet管理，不建议直接在CCI服务使用该命名空间，如需使用CCI服务，请另外新建命名空间。 实例的规格必须满足云容器实例CCI的容器规范。 使用1.2.5以下版本插件时，各容器的Requests须等于Limits（1.2.5及以上版本插件两者可不相等，弹性到CCI时自动将两者设置为一样，若配置了Limits，则以Limits为准，没有配Limits，则以Requests为准）。 Pod中至少有1个容器配置CPU大于0。 经过资源自动规整后，Pod总CPU不得超过32核，内存不得超过256Gi。

安装插件 在CCE控制台，单击左侧导航栏的“插件管理”，在“插件市场”页签下，单击virtual-kubelet插件下的“安装插件”。 在“基本信息”步骤中，选择安装的集群和插件版本，单击“下一步：规格配置”。 在“规格配置”步骤中，勾选“跨服务互通”后的选择框，可实现CCE集群中的Pod与CCI集群中的Pod通过Kubernetes Service互通。 图1 勾选“跨服务互通” 单击“安装”。 待插件安装完成后，单击“返回”，在“插件实例”页签下，选择对应的集群，可查看到运行中的实例，这表明该插件已在当前集群的各节点中安装。