华为云用户手册

前提条件 创建GPU类型节点，具体请参见创建节点。 安装gpu-device-plugin（原gpu-beta）插件，安装时注意要选择节点上GPU对应的驱动，具体请参见CCE AI套件（NVIDIA GPU）。 gpu-device-plugin（原gpu-beta）插件会把驱动的目录挂载到/usr/local/nvidia/lib64，在容器中使用GPU资源需要将/usr/local/nvidia/lib64追加到LD_LIBRARY_PATH环境变量中。 通常可以通过如下三种方式追加。 制作镜像的Dockerfile中配置LD_LIBRARY_PATH。（推荐） ENV LD_LIBRARY_PATH /usr/local/nvidia/lib64:$LD_LIBRARY_PATH 镜像的启动命令中配置LD_LIBRARY_PATH。 /bin/bash -c "export LD_LIBRARY_PATH=/usr/local/nvidia/lib64:$LD_LIBRARY_PATH && ..." 创建工作负载时定义LD_LIBRARY_PATH环境变量（需确保容器内未配置该变量，不然会被覆盖）。 ... env: - name: LD_LIBRARY_PATH value: /usr/local/nvidia/lib64 ...

使用GPU 创建工作负载申请GPU资源，可按如下方法配置，指定显卡的数量。 apiVersion: apps/v1 kind: Deployment metadata: name: gpu-test namespace: default spec: replicas: 1 selector: matchLabels: app: gpu-test template: metadata: labels: app: gpu-test spec: containers: - image: nginx:perl name: container-0 resources: requests: cpu: 250m memory: 512Mi nvidia.com/gpu: 1 # 申请GPU的数量 limits: cpu: 250m memory: 512Mi nvidia.com/gpu: 1 # GPU数量的使用上限 imagePullSecrets: - name: default-secret 通过nvidia.com/gpu指定申请GPU的数量，支持申请设置为小于1的数量，比如nvidia.com/gpu: 0.5，这样可以多个Pod共享使用GPU。GPU数量小于1时，不支持跨GPU分配，如0.5 GPU只会分配到一张卡上。 使用nvidia.com/gpu参数指定GPU数量时，requests和limits值需要保持一致。 指定nvidia.com/gpu后，在调度时不会将负载调度到没有GPU的节点。如果缺乏GPU资源，会报类似如下的Kubernetes事件。 0/2 nodes are available: 2 Insufficient nvidia.com/gpu. 0/4 nodes are available: 1 InsufficientResourceOnSingleGPU, 3 Insufficient nvidia.com/gpu. 在CCE控制台使用GPU资源，只需在创建工作负载时，选择使用的GPU配额即可。 图1 使用GPU

约束与限制 仅v1.19及以上版本的集群支持修改容器引擎、操作系统、系统盘/数据盘大小、数据盘空间分配、安装前/后执行脚本配置。 修改节点池资源标签、容器引擎、操作系统、安装前/后执行脚本时，修改后的配置仅对新增节点生效，存量节点如需同步配置，需要手动重置存量节点。 修改节点池系统盘/数据盘大小、数据盘空间分配则仅对新增节点生效，即使重置存量节点也无法同步配置。 修改K8s标签和污点数据会根据“存量节点标签及污点”开关状态决定是否自动同步已有节点，无需重置节点。

相关操作 您还可以执行表4中的操作。 表4 其他操作 操作 说明 操作步骤 创建存储卷 通过CCE控制台单独创建PV。 在左侧导航栏选择“存储”，在右侧选择“存储卷”页签。单击右上角“创建存储卷”，在弹出的窗口中填写存储卷声明参数。 存储卷类型：选择“文件存储”。 文件存储：单击“选择文件存储”，在新页面中勾选满足要求的文件存储，并单击“确定”。 PV名称：输入PV名称，同一集群内的PV名称需唯一。 访问模式：仅支持ReadWriteMany，表示存储卷可以被多个节点以读写方式挂载，详情请参见存储卷访问模式。 回收策略：Delete或Retain，详情请参见PV回收策略。 说明： 多个PV使用同一个底层存储时建议使用Retain，避免级联删除底层卷。 挂载参数：输入挂载参数键值对，详情请参见设置文件存储挂载参数。 单击“创建”。 事件 查看PVC或PV的事件名称、事件类型、发生次数、Kubernetes事件、首次和最近发生的时间，便于定位问题。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“事件”，即可查看1小时内的事件（事件保存时间为1小时）。 查看YAML 可对PVC或PV的YAML文件进行查看、复制和下载。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“查看YAML”，即可查看或下载YAML。

约束与限制 支持多个PV挂载同一个SFS或SFS Turbo，但有如下限制： 多个不同的PVC/PV使用同一个底层SFS或SFS Turbo卷时，如果挂载至同一Pod使用，会因为PV的volumeHandle参数值相同导致无法为Pod挂载所有PVC，出现Pod无法启动的问题，请避免该使用场景。 PV中persistentVolumeReclaimPolicy参数建议设置为Retain，否则可能存在一个PV删除时级联删除底层卷，其他关联这个底层卷的PV会由于底层存储被删除导致使用出现异常。 重复用底层存储时，建议在应用层做好多读多写的隔离保护，防止产生的数据覆盖和丢失。 使用SFS 3.0存储卷时，挂载点不支持修改属组和权限。 使用SFS 3.0存储卷时，创建、删除PVC和PV过程中可能存在时延，实际计费时长请以SFS侧创建、删除时刻为准。 SFS 3.0存储卷在Delete回收策略下暂不支持自动回收文件存储卷。当删除PV/PVC时，需要手动删除所有文件后才可以正常删除PV和PVC。

验证数据持久化及共享性 查看部署的应用及文件。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-mjhm9 1/1 Running 0 46s web-demo-846b489584-wvv5s 1/1 Running 0 46s 依次执行以下命令，查看Pod的/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data kubectl exec web-demo-846b489584-wvv5s -- ls /data 两个Pod均无返回结果，说明/data路径下无文件。 执行以下命令，在/data路径下创建static文件。 kubectl exec web-demo-846b489584-mjhm9 -- touch /data/static 执行以下命令，查看/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data 预期输出如下： static 验证数据持久化 执行以下命令，删除名称为web-demo-846b489584-mjhm9的Pod。 kubectl delete pod web-demo-846b489584-mjhm9 预期输出如下： pod "web-demo-846b489584-mjhm9" deleted 删除后，Deployment控制器会自动重新创建一个副本。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下，web-demo-846b489584-d4d4j为新建的Pod： web-demo-846b489584-d4d4j 1/1 Running 0 110s web-demo-846b489584-wvv5s 1/1 Running 0 7m50s 执行以下命令，验证新建的Pod中/data路径下的文件是否更改。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： static static文件仍然存在，则说明数据可持久化保存。 验证数据共享性 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-d4d4j 1/1 Running 0 7m web-demo-846b489584-wvv5s 1/1 Running 0 13m 执行以下命令，在任意一个Pod的/data路径下创建share文件。本例中选择名为web-demo-846b489584-d4d4j的Pod。 kubectl exec web-demo-846b489584-d4d4j -- touch /data/share 并查看该Pod中/data路径下的文件。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： share static 由于写入share文件的操作未在名为web-demo-846b489584-wvv5s的Pod中执行，在该Pod中查看/data路径下是否存在文件以验证数据共享性。 kubectl exec web-demo-846b489584-wvv5s -- ls /data 预期输出如下： share static 如果在任意一个Pod中的/data路径下创建文件，其他Pod下的/data路径下均存在此文件，则说明两个Pod共享一个存储卷。

通过监控中心查看Master节点组件指标 云原生监控中心已支持对Master节点的kube-apiserver组件进行监控，您在集群中开通云原生监控中心后（安装云原生监控插件版本为3.5.0及以上），可以查看仪表盘中的APIServer视图，监控API指标。 如需对kube-controller、kube-scheduler、etcd-server组件进行监控，请参考以下步骤。 此3个组件监控指标不在容器基础指标范围，监控中心将该类指标上报至 AOM 后会进行收费，因此监控中心会默认屏蔽采集该类指标。 登录CCE控制台，单击集群名称进入集群详情页。 在左侧导航栏中选择“配置与密钥”，并切换至“monitoring”命名空间，找到名为“persistent-user-config”的配置项。 单击“更新”，对配置数据进行编辑，并在serviceMonitorDisable字段下删除以下配置。 serviceMonitorDisable: - monitoring/kube-controller - monitoring/kube-scheduler - monitoring/etcd-server - monitoring/log-operator 图1 删除配置 单击“确定”。 等待5分钟后，您可前往AOM控制台，在“指标浏览”中找到集群上报的AOM实例，查看上述组件的指标。 图2 查看指标

通过控制台创建 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“服务”，切换至“路由”页签，在右上角单击“创建路由”。 设置Ingress参数。本示例中仅列举必选参数，其余参数可根据需求参考通过控制台创建ELB Ingress进行设置。 名称：自定义服务名称，可与工作负载名称保持一致。 负载均衡器：选择弹性负载均衡的类型、创建方式。 类型：本例中仅支持选择“独享型”。 创建方式：本文中以选择已有ELB为例进行说明，关于自动创建的配置参数请参见负载均衡器。 监听器配置： 前端协议：支持HTTP和HTTPS。本文以HTTP协议为例。 对外端口：开放在负载均衡服务地址的端口，可任意指定。 高级配置： 配置 说明 使用限制 获取监听器端口号 开启后可以将ELB实例的监听端口从报文的HTTP头中带到后端云服务器。 独享型ELB实例支持配置。 获取客户端请求端口号 开启后可以将客户端的源端口从报文的HTTP头中带到后端云服务器。 独享型ELB实例支持配置。 重写X-Forwarded-Host 开启后将以客户端请求头的Host重写X-Forwarded-Host传递到后端云服务器。 独享型ELB实例支持配置。 图1 配置HTTP/HTTPS头字段 转发策略配置：填写 域名 匹配规则及需要访问的目标Service。请求的访问地址与转发规则匹配时（转发规则由域名、URL组成，例如：10.117.117.117:80/helloworld），此请求将被转发到对应的目标Service处理。 单击“确定”，创建Ingress。

时区同步 创建工作负载时，支持设置容器使用节点相同的时区。您可以在创建工作负载时打开时区同步配置。 时区同步功能依赖容器中挂载的本地磁盘（HostPath），如下所示，开启时区同步后，Pod中会通过HostPath方式，将节点的“/etc/localtime”挂载到容器的“/etc/localtime”，从而使得节点和容器使用相同的时区配置文件。 kind: Deployment apiVersion: apps/v1 metadata: name: test namespace: default spec: replicas: 2 selector: matchLabels: app: test template: metadata: labels: app: test spec: volumes: - name: vol-162979628557461404 hostPath: path: /etc/localtime type: '' containers: - name: container-0 image: 'nginx:alpine' volumeMounts: - name: vol-162979628557461404 readOnly: true mountPath: /etc/localtime imagePullPolicy: IfNotPresent imagePullSecrets: - name: default-secret 父主题： 容器设置

VPC内访问 根据集群容器网络模型不同，从容器访问内部网络有不同表现。 容器隧道网络 容器隧道网络在节点网络基础上通过隧道封装网络数据包，容器访问同VPC下其他资源时，只要节点能访问通，容器就能访问通。如果访问不通，需要确认对端资源的安全组配置是否能够允许容器所在节点访问。 云原生网络2.0 云原生网络2.0模型下，容器直接从VPC网段内分配IP地址，容器网段是节点所在VPC的子网，容器与VPC内其他地址天然能够互通。如果访问不通，需要确认对端资源的安全组配置是否能够允许容器网段访问。 VPC网络 VPC网络使用了VPC路由功能来转发容器的流量，容器网段与节点VPC不在同一个网段，容器访问同VPC下其他资源时，需要对端资源的安全组能够允许容器网段访问。 例如集群节点所在网段为192.168.10.0/24，容器网段为172.16.0.0/16。 VPC下（集群外）有一个地址为192.168.10.52的E CS ，其安全组规则仅允许集群节点的IP网段访问。 此时如果从容器中ping 192.168.10.52，会发现无法ping通。 kubectl exec test01-6cbbf97b78-krj6h -it -- /bin/sh / # ping 192.168.10.25 PING 192.168.10.25 (192.168.10.25): 56 data bytes ^C --- 192.168.10.25 ping statistics --- 104 packets transmitted, 0 packets received, 100% packet loss 在安全组放通容器网段172.16.0.0/16访问。 此时再从容器中ping 192.168.10.52，会发现可以ping通。 $ kubectl exec test01-6cbbf97b78-krj6h -it -- /bin/sh / # ping 192.168.10.25 PING 192.168.10.25 (192.168.10.25): 56 data bytes 64 bytes from 192.168.10.25: seq=0 ttl=64 time=1.412 ms 64 bytes from 192.168.10.25: seq=1 ttl=64 time=1.400 ms 64 bytes from 192.168.10.25: seq=2 ttl=64 time=1.299 ms 64 bytes from 192.168.10.25: seq=3 ttl=64 time=1.283 ms ^C --- 192.168.10.25 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss

容器访问内网不通的定位方法 如前所述，从容器中访问内部网络不通的情况可以按如下路径排查： 查看要访问的对端服务器安全组规则，确认是否允许容器访问。 容器隧道网络模型需要放通容器所在节点的IP地址 VPC网络模型需要放通容器网段 云原生网络2.0需要放通容器所在子网网段 查看要访问的对端服务器是否设置了白名单，如DCS的Redis实例，需要添加白名单才允许访问。添加容器和节点网段到白名单后可解决问题。 查看要访问的对端服务器上是否安装了容器引擎，是否存在与CCE中容器网段冲突的情况。如果有网络冲突，会导致无法访问。

跨VPC访问 跨VPC访问通常采用对等连接等方法打通VPC。 容器隧道网络只需将节点网络与对端VPC打通，容器自然就能访问对端VPC。 云原生网络2.0与容器隧道网络类似，将容器所在子网网段与对端VPC打通即可。 VPC网络由于容器网段独立，除了要打通VPC网段，还要打通容器网段。 例如有如下两个VPC。 vpc-demo：网段为192.168.0.0/16，集群在vpc-demo内，容器网段为10.0.0.0/16。 vpc-demo2：网段为10.1.0.0/16。 创建一个名为peering-demo的对等连接（本端为vpc-demo，对端为vpc-demo2），注意对端VPC的路由添加容器网段。 这样配置后，在vpc-demo2中就能够访问容器网段10.0.0.0/16。具体访问时要关注安全组配置，打通端口配置。

访问其他云服务 与CCE进行内网通信的与服务常见服务有：RDS、DCS、Kafka、RabbitMQ、ModelArts等。 访问其他云服务除了上面所说的VPC内访问和跨VPC访问的网络配置外，还需要关注所访问的云服务是否允许外部访问，如DCS的Redis实例，需要添加白名单才允许访问。通常这些云服务会允许同VPC下IP访问，但是VPC网络模型下容器网段与VPC网段不同，需要特殊处理，将容器网段加入到白名单中。

静态挂载存储的迁移 静态挂载存储场景下，即工作负载中通过volumes字段挂载存储卷，所有类型的工作负载均可通过该方法挂载存储。使用该挂载方法的存储从SFS 1.0迁移到SFS 3.0或SFS Turbo的迁移操作步骤一致，本示例以SFS Turbo为例进行操作。 选择对应的CCE集群，进入“存储”界面，在“存储卷”页签下单击右上角“创建存储卷”。 设置以下参数。 存储卷类型：选择“极速文件存储”。 极速文件存储：选择数据迁移后的极速文件存储卷。 PV名称：自定义PV名称。 访问模式：选择“ReadWriteMany”。 回收策略：选择“Retain”。 PV创建完成后，在“存储卷声明”页签下单击右上角“创建存储卷声明”。 设置以下参数。 存储卷声明类型：选择“极速文件存储”。 PVC名称：自定义PVC名称，需与原SFS1.0 PVC名称不同。 创建方式：选择“已有存储卷”。 关联存储卷：选择上一步中已创建的存储卷。 PVC创建完成后，如下图所示。 在左侧导航栏中选择“工作负载”，找到目标工作负载，将工作负载实例数需要缩容到0。 单击工作负载“操作”栏中的“升级”按钮。在“容器配置”中，选择“数据存储”，切换至“存储卷声明PVC”页签，使用2创建的PVC替换工作负载使用的存储卷声明。 迁移后，请保持容器内的挂载路径和子路径与之前挂载SFS1.0时一致。 替换完成后，可扩容工作负载实例数。 确认无问题后，可清理CCE侧的SFS 1.0的存储卷。

升级参数说明 参数 说明 限制 最大浪涌（maxSurge） 与spec.replicas相比，可以有多少个Pod存在，默认值是25%。 比如spec.replicas为 4，那升级过程中就不能超过5个Pod存在，即按1个的步长升级，实际升级过程中会换算成数字，且换算会向上取整。这个值也可以直接设置成数字。 仅Deployment支持配置。 最大无效实例数（maxUnavailable） 与spec.replicas相比，可以有多少个Pod失效，也就是删除的比例，默认值是25%。 比如spec.replicas为4，那升级过程中就至少有3个Pod存在，即删除Pod的步长是1。同样这个值也可以设置成数字。 仅Deployment支持配置。 实例可用最短时间（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可以非常方便的回滚到老版本。 例如上面升级的新版镜像有问题，可以执行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。

升级示例 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。

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

操作步骤 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“配置与密钥”，在右上角单击“创建配置项”。 填写参数。 表1 新建配置参数说明 参数 参数说明 名称 新建的配置项名称，同一个命名空间里命名必须唯一。 命名空间 新建配置项所在的命名空间。若不选择，默认为default。 描述 配置项的描述信息。 配置数据 配置项的数据。 键值对形式，单击添加。其中值支持String、JSON和YAML格式。 标签 配置项的标签。键值对形式，输入键值对后单击“确认添加”。 配置完成后，单击“确定”。 工作负载配置列表中会出现新创建的工作负载配置。

使用kubectl创建配置项 请参见通过kubectl连接集群配置kubectl命令。 创建并编辑cce-configmap.yaml文件。 vi cce-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: cce-configmap data: SPECIAL_LEVEL: Hello SPECIAL_TYPE: CCE 表2 关键参数说明 参数 说明 apiVersion 固定值为v1。 kind 固定值为ConfigMap。 metadata.name 配置项名称，可自定义。 data 配置项的数据，需填写键值对形式。 创建配置项。 kubectl create -f cce-configmap.yaml 查看已创建的配置项。 kubectl get cm NAME DATA AGE cce-configmap 3 7m

通过控制台管理节点污点 在CCE控制台上同样可以管理节点的污点，且可以批量操作。 登录CCE控制台，单击集群名称进入集群。 在集群控制台左侧导航栏中选择“节点管理”，切换至“节点”页签，勾选目标节点，并单击左上方“标签与污点管理”。 在弹出的窗口中，在“批量操作”下方单击“新增批量操作”，然后选择“添加/更新”或“删除”，选择“污点(Taints)”。 填写需要操作污点的“键”和“值”，选择污点的效果，单击“确定”。 图1 添加污点 污点添加成功后，再次进入该界面，在节点数据下可查看到已经添加的污点。

系统污点说明 当节点出现某些问题时，Kubernetes会自动给节点添加一个污点，当前内置的污点包括： node.kubernetes.io/not-ready：节点未准备好。这相当于节点状况 Ready 的值为 "False"。 node.kubernetes.io/unreachable：节点控制器访问不到节点。这相当于节点状况 Ready 的值为 "Unknown"。 node.kubernetes.io/memory-pressure：节点存在内存压力。 node.kubernetes.io/disk-pressure：节点存在磁盘压力。 node.kubernetes.io/pid-pressure：节点存在 PID 压力。 node.kubernetes.io/network-unavailable：节点网络不可用。 node.kubernetes.io/unschedulable：节点不可调度。 node.cloudprovider.kubernetes.io/uninitialized：如果 kubelet 启动时指定了一个“外部”云平台驱动， 它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager 的一个控制器初始化这个节点后，kubelet 将删除这个污点。

相关操作：容忍度（Toleration） 容忍度应用于Pod上，允许（但并不要求）Pod 调度到带有与之匹配的污点的节点上。 污点和容忍度相互配合，可以用来避免 Pod 被分配到不合适的节点上。 每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。 在 Pod 中设置容忍度示例如下： apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent tolerations: - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule" 上面示例表示这个Pod容忍标签为key1=value1，效果为NoSchedule的污点，所以这个Pod能够调度到对应的节点上。 同样还可以按如下方式写，表示当节点有key1这个污点时，可以调度到节点。 tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"

验证 以8U32G节点为例，并提前在集群中部署一个CPU request为1，limit为2的工作负载。 登录到节点池中的一个节点，查看/var/lib/kubelet/cpu_manager_state输出内容。 cat /var/lib/kubelet/cpu_manager_state 回显如下： {"policyName":"enhanced-static","defaultCpuSet":"0,2-7","entries":{"6739f6f2-ebe5-48ae-945a-986d5d8919b9":{"container-1":"0-7,10001"}},"checksum":1638128523} policyName字段值为enhanced-static代表策略设置成功。 优先使用CPU号将10000作为基数，本例中10001即代表容器使用的亲和CPU号为1，0-7代表该Pod中容器可以使用的CPU集合。 查看容器的cpuset.preferred_cpus的cgroup设置，输出内容即为优先使用的CPU号。 cat /sys/fs/cgroup/cpuset/kubepods/burstable/pod{pod uid}/{容器id}/cpuset.preferred_cpus {pod uid}为Pod UID，可在已通过kubectl连接集群的机器上使用以下命令获取： kubectl get po {pod name} -n {namespace} -ojsonpath='{.metadata.uid}{"\n"}' 命令中的{pod name}和{namespace}是Pod名称及其所在的命名空间。 {容器id}需要是完整的容器ID，可在容器运行的节点上通过以下命令获取： docker节点池：命令中的{pod name}是Pod名称。 docker ps --no-trunc | grep {pod name} | grep -v cce-pause | awk '{print $1}' containerd节点池：命令中的{pod name}是Pod名称，{pod id}是Pod的ID，{container name}是容器名称。 # 获取Pod ID crictl pods | grep {pod name} | awk '{print $1}' # 获取完整容器ID crictl ps --no-trunc | grep {pod id} | grep {container name} | awk '{print $1}' 完整示例如下： cat /sys/fs/cgroup/cpuset/kubepods/burstable/pod6739f6f2-ebe5-48ae-945a-986d5d8919b9/5ba5603434b95fd22d36fba6a5f1c44eba83c18c2e1de9b52ac9b52e93547a13/cpuset.preferred_cpus 回显如下，表示优先使用1号CPU。 1

操作步骤 登录CCE控制台。 单击集群名称进入集群，在左侧选择“节点管理”，在右侧选择“节点池”页签。 选择一个操作系统为Huawei Cloud EulerOS 2.0的节点池，单击节点池名称后的“配置管理”。 在侧边栏滑出的“配置管理”窗口中，修改kubelet组件的CPU管理策略配置（cpu-manager-policy）参数值，选择enhanced-static。 图1 CPU管理策略配置 单击“确定”，完成配置操作。

Ingress支持的Service类型 ELB Ingress支持的Service类型如表1所示。 表1 ELB Ingress支持的Service类型 集群类型 ELB类型 集群内访问（ClusterIP） 节点访问（NodePort） CCE Standard集群 共享型负载均衡 不支持 支持 独享型负载均衡 不支持（集群内访问服务关联实例未绑定eni网卡，独享型负载均衡无法对接） 支持 CCE Turbo 集群 共享型负载均衡 不支持 支持 独享型负载均衡 支持 不支持（节点访问服务关联实例已绑定eni网卡，独享型负载均衡无法对接） Nginx Ingress支持的Service类型如表2所示。 表2 Nginx Ingress支持的Service类型 集群类型 ELB类型 集群内访问（ClusterIP） 节点访问（NodePort） CCE Standard集群 共享型负载均衡 支持 支持 独享型负载均衡 支持 支持 CCE Turbo集群 共享型负载均衡 支持 支持 独享型负载均衡 支持 支持

ELB Ingress Controller工作原理 CCE自研的ELB Ingress Controller基于弹性负载均衡服务ELB实现公网和内网（同一VPC内）的七层网络访问，通过不同的URL将访问流量分发到对应的服务。 ELB Ingress Controller部署于Master节点上，与集群所在VPC下的弹性负载均衡器绑定，支持在同一个ELB实例（同一IP）下进行不同域名、端口和转发策略的设置。ELB Ingress Controller的工作原理如图2，实现步骤如下： 用户创建Ingress资源，在Ingress中配置流量访问规则，包括负载均衡器、URL、SSL以及访问的后端Service端口等。 Ingress Controller监听到Ingress资源发生变化时，就会根据其中定义的流量访问规则，在ELB侧重新配置监听器以及后端服务器路由。 当用户进行访问时，流量根据ELB中配置的转发策略转发到对应的后端Service端口，然后再经过Service二次转发访问到关联的各个工作负载。 图2 ELB Ingress工作原理（CCE Standard集群以及CCE Turbo集群使用共享型ELB场景） 在使用CCE Turbo集群 + 独享型ELB实例时，Pod IP直接从VPC中分配，支持ELB直通Pod。创建集群外部访问的Ingress时，可使用ELB对接ClusterIP服务，直接将Pod作为ELB监听器的后端服务器，外部流量可以不经过节点端口转发直接访问集群中的Pod。 图3 ELB Ingress直通容器原理（CCE Turbo集群使用独享型ELB场景）

Nginx Ingress Controller工作原理 Nginx型的Ingress使用弹性负载均衡（ELB）作为流量入口，并在集群中部署nginx-ingress插件来对流量进行负载均衡及访问控制。 nginx-ingress插件使用开源社区的模板与镜像，使用过程中可能存在缺陷，CCE会定期同步社区版本来修复已知漏洞。请评估是否满足您的业务场景要求。 开源社区地址：https://github.com/kubernetes/ingress-nginx Nginx型的Ingress Controller通过pod部署在工作节点上，因此引入了相应的运维成本和Nginx组件运行成本，其工作原理如图4，实现步骤如下： 当用户更新Ingress资源后，Ingress Controller就会将其中定义的转发规则写入到Nginx的配置文件（nginx.conf）中。 内置的Nginx组件进行reload，加载更新后的配置文件，完成Nginx转发规则的修改和更新。 在流量访问集群时，首先被已创建的负载均衡实例转发到集群内部的Nginx组件，然后Nginx组件再根据转发规则将其转发至对应的各个工作负载。 图4 Nginx Ingress Controller工作原理

为什么需要Ingress Service基于TCP和UDP协议进行访问转发，为集群提供了四层负载均衡的能力。但是在实际场景中，Service无法满足应用层中存在着大量的HTTP/HTTPS访问需求。因此，Kubernetes集群提供了另一种基于HTTP协议的访问方式——Ingress。 Ingress是Kubernetes集群中一种独立的资源，制定了集群外部访问流量的转发规则。如图1所示，用户可根据域名和路径对转发规则进行自定义，完成对访问流量的细粒度划分。 图1 Ingress示意图 下面对Ingress的相关定义进行介绍： Ingress资源：一组基于域名或URL把请求转发到指定Service实例的访问规则，是Kubernetes的一种资源对象，通过接口服务实现增、删、改、查的操作。 Ingress Controller：请求转发的执行器，用以实时监控资源对象Ingress、Service、Endpoint、Secret（主要是TLS证书和Key）、Node、ConfigMap的变化，解析Ingress定义的规则并负责将请求转发到相应的后端Service。 Ingress Controller在不同厂商之间的实现方式不同，根据负载均衡器种类的不同，可以将其分成ELB型和Nginx型。CCE支持上述两种Ingress Controller类型，其中ELB Ingress Controller基于弹性负载均衡服务（ELB）实现流量转发；而Nginx Ingress Controller使用Kubernetes社区维护的模板与镜像，通过Nginx组件完成流量转发。

注意事项 建议其他资源不要使用Ingress自动创建的ELB实例，否则在删除Ingress时，ELB实例会被占用，导致资源残留。 添加Ingress后请在CCE页面对所选ELB实例进行配置升级和维护，不可在ELB页面对配置进行更改，否则可能导致Ingress服务异常。 Ingress转发策略中注册的URL需与后端应用提供访问的URL一致，否则将返回404错误。 独享型ELB规格必须支持应用型（HTTP/HTTPS），且网络类型必须支持私网（有私有IP地址）。 同集群使用多个Ingress对接同一个ELB端口时，监听器的配置项（例如监听器关联的证书、监听器HTTP2属性等）均以第一个Ingress配置为准。