华为云用户手册

相关操作 您还可以执行表3中的操作。 表3 其他操作 操作 说明 操作步骤 事件 查看PVC或PV的事件名称、事件类型、发生次数、Kubernetes事件、首次和最近发生的时间，便于定位问题。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“事件”，即可查看1小时内的事件（事件保存时间为1小时）。 查看YAML 可对PVC或PV的YAML文件进行查看、复制和下载。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“查看YAML”，即可查看或下载YAML。

云原生监控插件Server模式下为什么不能正常上报指标？ 出现该问题的原因可能为Server模式下插件实例挂载的PV存储空间已满，导致指标无法写入。 请到插件中心，选中prometheus-server-x实例，查看日志。如果日志中存在：“no space left on device”类似的日志打印，则说明Prometheus挂载的磁盘空间不足。 图5 查看Prometheus实例日志 解决方案 方案一：推荐使用Agent模式，对接 AOM 实例。使用AOM托管指标数据，无需管理存储。 方案二：在左侧导航栏中选择“存储”，并切换至monitoring命名空间，选中pvc-prometheus-server-0的磁盘，扩容对应的存储资源。扩容完成后前往有状态负载页面，将prometheus-server的实例重启。 图6 扩容PVC 在磁盘空间不足后已无法写入Prometheus指标，将导致数据无法采集，因此扩容完成重启后，该时段的监控数据将会丢失。

Prometheus插件切换云原生监控插件 Prometheus插件不再维护，能力已完整收编至云原生监控插件，新插件提供了更全面、更强大的监控功能。从Prometheus插件切换至云原生监控插件时，只能继承原有的数据，无法继承旧Prometheus插件的配置。建议您参考以下步骤备份旧Prometheus插件配置： 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“配置与密钥”，切换至“monitoring”命名空间，查看以下三个配置项的YAML文件并保存。 adapter-config prometheus prometheus-server-record-rules 卸载Prometheus插件，安装新的云原生监控插件，并选择“Server”模式。 新插件安装完成后，您可参考原配置项内容重新添加配置。 对比插件升级后的配置项内容差异，根据需求进行更新。 由于插件升级，相同功能的配置项名称存在部分差异，云原生监控插件和Prometheus插件的配置对应关系如下： Prometheus插件配置 云原生监控插件配置 adapter-config user-adapter-config prometheus 插件更新后，该配置功能通过PodMonitor和ServiceMonitor实现，请重新选择对应的监控指标，详情请参见使用云原生监控插件监控自定义指标。 prometheus-server-record-rules 插件更新后，该配置功能通过PrometheusRule实现，请重新创建对应的告警规则，详情请参见使用PrometheusRules配置普罗监控与告警规则。

索引 为什么监控中心没有数据了？ 如何关闭监控中心？ 监控中心为什么没有展示自定义指标？ 为什么云原生监控插件在Server模式下，重启prometheus-server实例可能会导致节点列表的资源信息短时间（1-2分钟）无法正常显示？ 为什么云原生监控插件在Server模式下，重启kube-state-metrics实例可能会导致页面部分数据翻倍？ 云原生监控插件Server模式下为什么不能正常上报指标？ Prometheus插件切换云原生监控插件

为什么监控中心没有数据了？ 可能原因一：云原生监控插件异常 请前往集群详情的“插件中心”页面，先检查插件云原生监控插件是否为“运行中”。 图1 检查插件运行状态 如果插件运行异常，可以根据云原生监控插件的实例的事件进行排查。 图2 查看插件事件 可能原因二：云原生监控插件对接的AOM实例被删除 请在集群详情的“插件中心”页面，检查插件云原生监控插件的配置。 图3 编辑插件配置 确认AOM实例非空。 图4 查看AOM实例

为什么云原生监控插件在Server模式下，重启prometheus-server实例可能会导致节点列表的资源信息短时间（1-2分钟）无法正常显示？ 因为当prometheus-server实例重启后，实例指标的uid标签值发生了变化。而由于Server模式本地存储了数据的机制，导致prometheus-server实例滚动重启的这段时间里指标重叠，即云原生监控插件上报到AOM的指标同时存在新老prometheus-server实例的指标，因而导致节点列表的资源信息不准确。故在指标重叠的这段时间内，不展示节点列表的资源信息。若无特殊场景，对接AOM推荐使用Agent模式的云原生监控插件。

升级参数说明 参数 说明 限制 最大浪涌（maxSurge） 与spec.replicas相比，可以有多少个Pod存在，默认值是25%。 比如spec.replicas为 4，那升级过程中就不能超过5个Pod存在，即按1个的步长升级，实际升级过程中会换算成数字，且换算会向上取整。这个值也可以直接设置成数字。 仅Deployment、DaemonSet支持配置。 最大无效实例数（maxUnavailable） 与spec.replicas相比，可以有多少个Pod失效，也就是删除的比例，默认值是25%。 比如spec.replicas为4，那升级过程中就至少有3个Pod存在，即删除Pod的步长是1。同样这个值也可以设置成数字。 仅Deployment、DaemonSet支持配置。 实例可用最短时间（minReadySeconds） 指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间， 只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。 - 最大保留版本数（revisionHistoryLimit） 用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 kubectl get rs 的输出。 每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet， 将失去回滚到 Deployment 的对应修订版本的能力。 默认情况下，系统保留 10 个旧 ReplicaSet，但其理想值取决于新 Deployment 的频率和稳定性。 - 升级最大时长（progressDeadlineSeconds） 指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded。Deployment 控制器将持续重试 Deployment。 将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。 如果指定，则此字段值需要大于 .spec.minReadySeconds 取值。 - 缩容时间窗（terminationGracePeriodSeconds） 优雅删除时间，默认为30秒，删除Pod时发送SIGTERM终止信号，然后等待容器中的应用程序终止执行，如果在terminationGracePeriodSeconds时间内未能终止，则发送SIGKILL的系统信号强行终止。 -

升级示例 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 在前面的例子中，由于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。

回滚 回滚也称为回退，即当发现升级出现问题时，让应用回到老版本。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。

解决方案 问题场景一：该节点为集群升级过程中跳过的节点。 配置Kubectl命令，具体请参见通过kubectl连接集群。 查看对应节点kubelet版本，以下为正常回显： 图1 kubelet版本 若该节点的VERSION与其他节点不同，则该节点为升级过程中跳过的节点，请在合适的时间重置节点后，重试检查。 重置节点会重置所有节点标签，可能影响工作负载调度，请在重置节点前检查并保留您手动为该节点打上的标签。

前提条件 目标集群已创建，且集群中包含GPU节点，并已运行GPU相关业务。 在集群中安装CCE AI套件（NVIDIA GPU），且插件的metrics API正常工作。您可以登录GPU节点，执行以下命令进行检查： curl {Pod IP}:2112/metrics 其中{Pod IP}是GPU插件的Pod IP，返回指标结果则为正常。 在集群中安装3.9.5及以上版本的云原生监控插件，且部署模式需选择“Server模式”。

升级 您可以通过CCE控制台实现无状态工作负载、有状态工作负载、守护进程集的快速升级。 本文以无状态工作负载为例说明如何进行升级。 若需要更换镜像或镜像版本，您需要提前将镜像上传到 容器镜像服务 ，上传方法请参见通过Docker客户端上传镜像。 登录CCE控制台，进入一个已有的集群，在左侧导航栏中选择“工作负载”。 选择“无状态负载”页签，单击待升级工作负载后的“升级”。 暂不支持批量升级多个工作负载。 有状态工作负载升级时，若升级类型为替换升级，需要用户手动删除实例后才能升级成功，否则界面会始终显示“处理中”。 请根据业务需求进行工作负载的升级，参数设置方法与创建工作负载时一致。 更新完成后，单击“升级工作负载”，并手动确认YAML文件差异后提交升级。

事件 本文以无状态工作负载为例说明如何使用事件功能。任务或定时任务中的事件功能可直接单击工作负载操作栏中的“事件”按钮查看。 登录CCE控制台，进入一个已有的集群，在左侧导航栏中选择“工作负载”。 选择“无状态负载”页签，单击工作负载名称，可在“实例列表”中单击某个实例的“事件”按钮，查看该工作负载或具体实例的事件名称、事件类型、发生次数、Kubernetes事件、首次和最近发生的时间。 事件保存时间为1小时，1小时后自动清除数据。

操作场景 工作负载创建后，您可以对其执行升级、编辑YAML、日志、监控、回退、删除等操作。 表1 工作负载/任务管理 操作 描述 日志 可查看工作负载的日志信息。 升级 可以通过更换镜像或镜像版本实现无状态工作负载、有状态工作负载、守护进程集的快速升级，业务无中断。 编辑YAML 可通过在线YAML编辑窗对无状态工作负载、有状态工作负载、定时任务和容器组的YAML文件进行修改和下载。普通任务的YAML文件仅支持查看、复制和下载。 说明： 如果对已有的定时任务（CronJob）进行修改，修改之后运行的新Pod将使用新的配置，而已经运行的Pod将继续运行不会发生任何变化。 回退 无状态工作负载可以进行回退操作，仅无状态工作负载可用。 重新部署 工作负载可以进行重新部署操作，重新部署后将重启负载下的全部容器组Pod。 关闭/开启升级 无状态工作负载可以进行关闭/开启升级操作，仅无状态工作负载可用。 标签管理 标签是以key/value键值对的形式附加在工作负载上的。添加标签后，可通过标签对工作负载进行管理和选择。任务或定时任务无法使用标签管理功能。 删除 若工作负载无需再使用，您可以将工作负载或任务删除。工作负载或任务删除后，将无法恢复，请谨慎操作。 事件 查看具体实例的事件名称、事件类型、发生次数、Kubernetes事件、首次和最近发生的时间。 停止/启动 停止/启动一个定时任务，该功能仅定时任务可用。

PV与PVC Kubernetes抽象了PV（PersistentVolume）和PVC（PersistentVolumeClaim）来定义和使用存储，从而让使用者不用关心具体的基础设施，当需要存储资源的时候，只要像CPU和内存一样，声明要多少即可。 PV：PV是PersistentVolume的缩写，译为持久化存储卷，描述的是一个集群里的持久化存储卷，它和节点一样，属于集群级别资源，其对象作用范围是整个Kubernetes集群。PV可以有自己的独立生命周期，不依附于Pod。 PVC：PVC是PersistentVolumeClaim的缩写，译为持久化存储卷声明，描述的是负载对存储的申领。为应用配置存储时，需要声明一个存储需求（即PVC），Kubernetes会通过最佳匹配的方式选择一个满足需求的PV，并与PVC绑定。PVC与PV是一一对应关系，在创建PVC时，需描述请求的持久化存储的属性，比如，存储的大小、可读写权限等等。 在Pod中可以使用Volume关联PVC，即可让Pod使用到存储资源，它们之间的关系如下图所示。 图1 PVC绑定PV

存储卷访问模式 存储卷只能以底层存储资源所支持的方式挂载到宿主系统上。例如，文件存储可以支持多个节点读写，云硬盘只能被一个节点读写。 ReadWriteOnce：存储卷可以被一个节点以读写方式挂载。 ReadWriteMany：存储卷可以被多个节点以读写方式挂载。 表1 存储卷支持的访问模式 存储类型 ReadWriteOnce ReadWriteMany 云硬盘EVS √ × 文件存储SFS × √ 对象存储OBS × √ 极速文件存储SFS Turbo × √ 本地持久卷LocalPV √ ×

存储卷挂载方式 通常在使用存储卷时，可以通过以下方式挂载： 可以使用PV描述已有的存储资源，然后通过创建PVC在Pod中使用存储资源。也可以使用动态创建的方式，在PVC中指定存储类（StorageClass），利用StorageClass中的Provisioner自动创建PV来绑定PVC。 表2 挂载存储卷的方式 挂载方式 说明 支持的存储卷类型 其他限制 静态创建存储卷（使用已有存储） 即使用已有的存储（例如云硬盘、文件存储等）创建好PV，并通过PVC在工作负载中挂载。Kubernetes会将PVC和匹配的PV进行绑定，这样就实现了工作负载访问存储服务的能力。 所有存储卷均支持 无 动态创建存储卷（自动创建存储） 即在PVC中指定存储类（StorageClass），由存储Provisioner根据需求创建底层存储介质，实现PV的自动化创建并直接绑定至PVC。 云硬盘存储、对象存储、文件存储、本地持久卷 无 动态挂载（VolumeClaimTemplate） 动态挂载能力通过卷申领模板（volumeClaimTemplates字段）实现，并依赖于StorageClass的动态创建PV能力。动态挂载可以为每一个Pod关联一个独有的PVC及PV，当Pod被重新调度后，仍然能够根据该PVC名称挂载原有的数据。 仅云硬盘存储、本地持久卷支持 仅有状态工作负载支持

Volume（卷） 容器中的文件在磁盘上是临时存放的，这给容器中运行的较重要的应用程序带来如下两个问题： 当容器重建时，容器中的文件将会丢失。 当在一个Pod中同时运行多个容器时，容器间需要共享文件。 Kubernetes抽象出了Volume（卷）来解决以上两个问题。Kubernetes的Volume是Pod的一部分，Volume不是单独的对象，不能独立创建，只能在Pod中定义。Pod中的所有容器都可以使用Volume，但需要将Volume挂载到容器中的目录下。 实际中使用容器存储如下图所示，可将同一个Volume挂载到不同的容器中，实现不同容器间的存储共享。 存储卷的基本使用原则如下： 一个Pod可以挂载多个Volume。虽然单Pod可以挂载多个Volume，但是并不建议给一个Pod挂载过多卷。 一个Pod可以挂载多种类型的Volume。 每个被Pod挂载的Volume卷，可以在不同的容器间共享。 Kubernetes环境推荐使用PVC和PV方式挂载Volume。 卷（Volume）的生命周期与挂载它的Pod相同，即Pod被删除的时候，Volume也一起被删除。但是Volume里面的文件可能在Volume消失后仍然存在，这取决于Volume的类型。 Kubernetes提供了非常丰富的Volume类型，主要可分为In-Tree和Out-of-Tree两个大类： 卷（Volume）分类 描述 In-Tree In-Tree卷是通过Kubernetes代码仓库维护的，与Kubernetes二进制文件一起构建、编译、发布，当前Kubernetes已不再接受这种模式的卷类型。 例如HostPath、EmptyDir、Secret和ConfigMap等Kubernetes原生支持的卷都属于这个类型。 而PVC（PersistentVolumeClaim）可以说是一种特殊的In-Tree卷，Kubernetes使用这种类型的卷从In-Tree模式向Out-of-Tree模式进行转换，这种类型的卷允许使用者在不同的存储供应商环境中“申请”使用底层存储创建的PV（PersistentVolume）。 Out-of-Tree Out-of-Tree卷包括容器存储接口（ CS I）和FlexVolume（已弃用），存储供应商只需遵循一定的规范即可创建自定义存储插件，创建可供Kubernetes使用的PV，而无需将插件源码添加到Kubernetes代码仓库。例如SFS、OBS等 云存储 都是通过在集群中安装存储驱动的形式使用的，需要在集群中创建对应的PV，然后使用PVC挂载到Pod中。

操作场景 环境变量是指容器运行环境中设定的一个变量，环境变量可以在工作负载部署后修改，为工作负载提供极大的灵活性。 CCE中设置的环境变量与Dockerfile中的“ENV”效果相同。 容器启动后，容器中的内容不应修改。如果修改配置项（例如将容器应用的密码、证书、环境变量配置到容器中），当容器重启（例如节点异常重新调度Pod）后，会导致配置丢失，业务异常。 配置信息应通过入参等方式导入容器中，以免重启后配置丢失。 环境变量支持如下几种方式设置。 自定义：手动填写环境变量名称及对应的参数值。 配置项导入：将配置项中所有键值都导入为环境变量。 配置项键值导入：将配置项中某个键的值导入作为某个环境变量的值。例如图1中将configmap-example这个配置项中configmap_key的值configmap_value导入为环境变量key1的值，导入后容器中将会存在一个名为key1的环境变量，其值为configmap_value。 密钥导入：将密钥中所有键值都导入为环境变量。 密钥键值导入：将密钥中某个键的值导入作为某个环境变量的值。例如图1中将secret-example这个配置项中secret_key的值secret_value导入为环境变量key2的值，导入后容器中将会存在一个名为key2的环境变量，其值为secret_value。 变量/变量引用：用Pod定义的字段作为环境变量的值。例如图1中将此Pod的名称导入为环境变量key3的值，导入后容器中将会存在一个名为key3的环境变量，其值为该Pod的名称。 资源引用：用容器定义的资源申请值或限制值作为环境变量的值。例如图1中将容器container-1的CPU限制值导入为环境变量key4的值，导入后容器中将会存在一个名为key4的环境变量，其值为容器container-1的CPU限制值。

YAML样例 apiVersion: apps/v1 kind: Deployment metadata: name: env-example namespace: default spec: replicas: 1 selector: matchLabels: app: env-example template: metadata: labels: app: env-example spec: containers: - name: container-1 image: nginx:alpine imagePullPolicy: Always resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi env: - name: key # 自定义 value: value - name: key1 # 配置项键值导入 valueFrom: configMapKeyRef: name: configmap-example key: configmap_key - name: key2 # 密钥键值导入 valueFrom: secretKeyRef: name: secret-example key: secret_key - name: key3 # 变量引用，用Pod定义的字段作为环境变量的值 valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: key4 # 资源引用，用Container定义的字段作为环境变量的值 valueFrom: resourceFieldRef: containerName: container1 resource: limits.cpu divisor: 1 envFrom: - configMapRef: # 配置项导入 name: configmap-example - secretRef: # 密钥导入 name: secret-example imagePullSecrets: - name: default-secret

环境变量查看 如果configmap-example和secret-example的内容如下。 $ kubectl get configmap configmap-example -oyaml apiVersion: v1 data: configmap_key: configmap_value kind: ConfigMap ... $ kubectl get secret secret-example -oyaml apiVersion: v1 data: secret_key: c2VjcmV0X3ZhbHVl # c2VjcmV0X3ZhbHVl为secret_value的base64编码 kind: Secret ... 则进入Pod中查看的环境变量结果如下。 $ kubectl get pod NAME READY STATUS RESTARTS AGE env-example-695b759569-lx9jp 1/1 Running 0 17m $ kubectl exec env-example-695b759569-lx9jp -- printenv / # env key=value # 自定义环境变量 key1=configmap_value # 配置项键值导入 key2=secret_value # 密钥键值导入 key3=env-example-695b759569-lx9jp # Pod的metadata.name key4=1 # container1这个容器的limits.cpu，单位为Core，向上取整 configmap_key=configmap_value # 配置项导入，原配置项中的键值直接会导入结果 secret_key=secret_value # 密钥导入，原密钥中的键值直接会导入结果

配置访问OBS服务的 VPC终端节点 登录VPC终端节点控制台。 在“终端节点”页面，单击“购买终端节点”。 根据界面提示配置必选参数。 表3 终端节点配置参数 参数 说明 区域 终端节点所在区域，需要与Autopilot集群所在区域保持一致。 计费方式 此处选择按需计费。 服务类别 选择“按名称查找服务”。 服务名称 参考表4，根据集群所在区域填写，并单击“验证”。 虚拟私有云 需要选择Autopilot集群所在的虚拟私有云。 路由表 选择一个已有的路由表。 表4 OBS服务名称 区域 名称 华南-广州友好 cn-south-4.com.myhuaweicloud.v4.obsv2 西南-贵阳一 cn-southwest-2.com.myhuaweicloud.v4.obsv2 华南-广州 cn-southcom.myhuaweicloud.v4.obsv2 华东-上海一 cn-east-3.com.myhuaweicloud.v4.obsv2 图3 创建OBS服务的VPC终端节点 参数配置完成，单击“立即购买”，进行规格确认。 规格确认无误，单击“提交”，任务提交成功。 参数信息配置有误，需要修改，单击“上一步”，修改参数，然后单击“提交”。 返回终端节点列表，如果终端节点状态为“已接受”，表示终端节点已成功连接至终端节点服务。

配置访问SWR服务的VPC终端节点 登录VPC终端节点控制台。 在“终端节点”页面，单击“购买终端节点”。 根据界面提示配置必选参数。 表1 终端节点配置参数 参数 说明 区域 终端节点所在区域，需要与Autopilot集群所在区域保持一致。 计费方式 此处选择按需计费。 服务类别 选择“按名称查找服务”。 服务名称 参考表2，根据集群所在区域填写，并单击“验证”。 虚拟私有云 需要选择Autopilot集群所在的虚拟私有云。 子网 选择一个已有子网。 IPv4地址 默认可选择“自动分配IPv4地址”，您也可以根据需求选择“手动指定IP地址”。 表2 SWR服务名称 区域 名称 华南-广州友好 cn-south-4.SWR.f80386a2-ce16-4f92-9df9-20f7fc01e7a2 西南-贵阳一 com.myhuaweicloud.cn-southwest-2.swr 华南-广州 swr.cn-south-1.myhuaweicloud.com 华东-上海一 com.myhuaweicloud.cn-east-3.swr 图2 创建SWR服务的VPC终端节点 参数配置完成，单击“立即购买”，进行规格确认。 规格确认无误，单击“提交”，任务提交成功。 参数信息配置有误，需要修改，单击“上一步”，修改参数，然后单击“提交”。 返回终端节点列表，如果终端节点状态为“已接受”，表示终端节点已成功连接至终端节点服务。

使用CloudShell连接集群 CloudShell是一款用于管理与运维云资源的网页版Shell工具，CCE支持使用CloudShell连接集群，如图1所示，单击“命令行工具”即可在CloudShell中使用kubectl访问集群。 CloudShell中kubectl证书有效期为1天，从云容器引擎重新跳转可以重置有效期。 CloudShell基于VPCEP实现，在CloudShell中使用kubectl访问集群需要在集群控制节点的安全组（安全组名称：集群名称-cce-control-随机数）中放通如下网段访问5443端口。5443端口默认对所有网段放通，如果您对安全组做过加固，当出现在CloudShell中无法访问集群时，请检查5443端口是否放通了198.19.0.0/16网段。 集群必须安装CoreDNS才能使用CloudShell。 当前仅北京一、北京四、上海一、上海二、广州、贵阳一和乌兰察布一支持使用CloudShell登录容器。 CloudShell暂不支持委托账号和子项目。 图1 CloudShell 图2 在CloudShell中使用kubectl

开通监控中心 购买集群时开通 登录云容器引擎控制台，购买集群。 在“插件选择”页面，勾选云原生监控插件。 在“插件配置”页面，选择云原生监控插件需要对接的AOM实例。如AccessCode未创建，请先创建AccessCode。 图1 启用容器监控 在监控中心页面开通 在目标集群左侧导航栏选择“监控中心”。 单击“立即开通”，并选择指标上报的AOM实例。 图2 开通监控中心 开通成功后，等待3-5分钟，监控数据将上报至AOM实例，随即可以使用监控中心相关功能。 在插件管理页面开通 在目标集群左侧导航栏选择“插件中心”。 选择云原生监控插件，单击“安装”。 开启对接AOM开关，指标将上报至AOM实例。 图3 安装云原生监控插件 插件安装完成3-5分钟后，监控数据将上报至AOM实例，随即可以使用监控中心相关功能。 如需关闭监控中心，请前往CCE控制台“插件管理”页面卸载云原生监控插件，或关闭AOM对接，即可以停止使用该功能。

基于优先级调度示例 如果集群中存在两个空闲节点，存在3个优先级的工作负载，分别为high-priority，med-priority，low-priority，首先运行high-priority占满集群资源，然后提交med-priority，low-priority的工作负载，由于集群资源全部被更高优先级工作负载占用，med-priority，low-priority的工作负载为pending状态，当high-priority工作负载结束，按照优先级调度原则，med-priority工作负载将优先调度。 通过priority.yaml创建3个优先级定义（PriorityClass），分别为：high-priority，med-priority，low-priority。 priority.yaml文件内容如下： apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 100 globalDefault: false description: "This priority class should be used for volcano job only." --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: med-priority value: 50 globalDefault: false description: "This priority class should be used for volcano job only." --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: low-priority value: 10 globalDefault: false description: "This priority class should be used for volcano job only." 创建PriorityClass： kubectl apply -f priority.yaml 查看优先级定义信息。 kubectl get PriorityClass 回显如下： NAME VALUE GLOBAL-DEFAULT AGE high-priority 100 false 97s low-priority 10 false 97s med-priority 50 false 97s system-cluster-critical 2000000000 false 6d6h system-node-critical 2000001000 false 6d6h 创建高优先级工作负载high-priority-job，占用集群的全部资源。 high-priority-job.yaml apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: priority-high spec: schedulerName: volcano minAvailable: 4 priorityClassName: high-priority tasks: - replicas: 4 name: "test" template: spec: containers: - image: alpine command: ["/bin/sh", "-c", "sleep 1000"] imagePullPolicy: IfNotPresent name: running resources: requests: cpu: "1" restartPolicy: OnFailure 执行以下命令下发作业： kubectl apply -f high_priority_job.yaml 通过 kubectl get pod 查看Pod运行信息，如下： NAME READY STATUS RESTARTS AGE priority-high-test-0 1/1 Running 0 3s priority-high-test-1 1/1 Running 0 3s priority-high-test-2 1/1 Running 0 3s priority-high-test-3 1/1 Running 0 3s 此时，集群节点资源已全部被占用。 创建中优先级工作负载med-priority-job和低优先级工作负载low-priority-job。 med-priority-job.yaml apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: priority-medium spec: schedulerName: volcano minAvailable: 4 priorityClassName: med-priority tasks: - replicas: 4 name: "test" template: spec: containers: - image: alpine command: ["/bin/sh", "-c", "sleep 1000"] imagePullPolicy: IfNotPresent name: running resources: requests: cpu: "1" restartPolicy: OnFailure low-priority-job.yaml apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: priority-low spec: schedulerName: volcano minAvailable: 4 priorityClassName: low-priority tasks: - replicas: 4 name: "test" template: spec: containers: - image: alpine command: ["/bin/sh", "-c", "sleep 1000"] imagePullPolicy: IfNotPresent name: running resources: requests: cpu: "1" restartPolicy: OnFailure 执行以下命令下发作业： kubectl apply -f med_priority_job.yaml kubectl apply -f low_priority_job.yaml 通过 kubectl get pod 查看Pod运行信息，集群资源不足，Pod处于Pending状态，如下： NAME READY STATUS RESTARTS AGE priority-high-test-0 1/1 Running 0 3m29s priority-high-test-1 1/1 Running 0 3m29s priority-high-test-2 1/1 Running 0 3m29s priority-high-test-3 1/1 Running 0 3m29s priority-low-test-0 0/1 Pending 0 2m26s priority-low-test-1 0/1 Pending 0 2m26s priority-low-test-2 0/1 Pending 0 2m26s priority-low-test-3 0/1 Pending 0 2m26s priority-medium-test-0 0/1 Pending 0 2m36s priority-medium-test-1 0/1 Pending 0 2m36s priority-medium-test-2 0/1 Pending 0 2m36s priority-medium-test-3 0/1 Pending 0 2m36s 删除high_priority_job工作负载，释放集群资源，med_priority_job会被优先调度。 执行 kubectl delete -f high_priority_job.yaml 释放集群资源，查看Pod的调度信息，如下： NAME READY STATUS RESTARTS AGE priority-low-test-0 0/1 Pending 0 5m18s priority-low-test-1 0/1 Pending 0 5m18s priority-low-test-2 0/1 Pending 0 5m18s priority-low-test-3 0/1 Pending 0 5m18s priority-medium-test-0 1/1 Running 0 5m28s priority-medium-test-1 1/1 Running 0 5m28s priority-medium-test-2 1/1 Running 0 5m28s priority-medium-test-3 1/1 Running 0 5m28s

优先级调度与抢占介绍 用户在集群中运行的业务丰富多样，包括核心业务、非核心业务，在线业务、离线业务等，根据业务的重要程度和SLA要求，可以对不同业务类型设置相应的高优先级。比如对核心业务和在线业务设置高优先级，可以保证该类业务优先获取集群资源。当集群资源被非核心业务占用，整体资源不足时，如果有新的核心业务提交部署请求，可以通过抢占的方式驱逐部分非核心业务，释放集群资源用于核心业务的调度运行。 CCE集群支持的优先级调度如表1所示。 表1 业务优先级保障调度 调度类型 说明 支持的调度器 基于优先级调度 调度器优先保障高优先级业务运行，但不会主动驱逐已运行的低优先级业务。基于优先级调度配置默认开启，不支持关闭。 kube-scheduler调度器/Volcano调度器 基于优先级抢占调度 当集群资源不足时，调度器主动驱逐低优先级业务，保障高优先级业务正常调度。 Volcano调度器

基于优先级抢占调度的亲和/反亲和示例 在Pod间亲和场景中，不推荐Pod与比其优先级低的Pod亲和。如果pending状态的Pod与节点上的一个或多个较低优先级Pod具有Pod间亲和性，对较低优先级的Pod发起抢占时，会无法满足Pod间亲和性规则，抢占规则和亲和性规则产生矛盾。 在这种情况下，调度程序无法保证pending状态的Pod可以被调度。详情请参见与低优先级Pod之间的Pod间亲和性。 在Pod间反亲和场景中，如果启用优先级抢占，当deploy1与比其优先级低的deploy2亲和，volcano-scheduler为保证业务自运维，将驱逐deploy3，并将deploy1调度到节点上。被驱逐的deploy3将会在新节点准备好后，调度到新节点上。 图2 与低优先级的Pod亲和场景 在Pod间反亲和场景中，volcano-scheduler为减少对其它业务的影响，将不驱逐deploy2和deploy3，而是在新节点准备好后，调度到新节点上。 图3 与低优先级Pod反亲和场景

容器组（Pod） 容器组（Pod）是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。 Pod使用主要分为两种方式： Pod中运行一个容器。这是Kubernetes最常见的用法，您可以将Pod视为单个封装的容器，但是Kubernetes是直接管理Pod而不是容器。 Pod中运行多个需要耦合在一起工作、需要共享资源的容器。通常这种场景下应用包含一个主容器和几个辅助容器（SideCar Container），如图1所示，例如主容器为一个web服务器，从一个固定目录下对外提供文件服务，而辅助容器周期性的从外部下载文件存到这个固定目录下。 图1 Pod 实际使用中很少直接创建Pod，而是使用Kubernetes中称为Controller的抽象层来管理Pod实例，例如Deployment和Job。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。通常，Controller会使用Pod Template来创建相应的Pod。

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