华为云用户手册

参数说明 表1 灰度发布参数说明 参数 是否必填 参数类型 描述 kubernetes.io/elb.canary 否 string 设置Ingress灰度发布的开关。设置为true后，配合不同的注解，可以实现不同的灰度发布功能。 取值范围：true 独享型负载均衡器生效。 设置为true后，不允许删除或修改。 kubernetes.io/elb.canary-weight 否 string 权重灰度发布权重值，设置后Ingress以权重灰度形式发布。 取值为0-100的正整数，为灰度流量分配的百分比。 发布成权重灰度Ingress时，该参数必填。 不能与其他灰度发布功能同时设置。 kubernetes.io/elb.session-affinity-mode 否 string 开启权重灰度发布后，配置会话保持能力。 灰度发布仅支持设置为 "HTTP_COOKIE"。 kubernetes.io/ elb.session-affinity-option 否 string 开启权重灰度发布会话保持能力后，会话保持的超时时间。 参数值为json字符串，格式如下： {"persistence_timeout": "1440"} 参数说明： 超时时间范围为1-1440。 默认值为1440。 kubernetes.io/elb.canary-by-header 否 string header灰度发布的Key值，表示请求头参数的名称。需要与kubernetes.io/elb.canary-by-header-value成对使用。 参数说明： 长度限制1-40字符，只允许包含字母、数字、中划线（-）和下划线（_）。 kubernetes.io/elb.canary-by-header-value 否 string header灰度发布的Values值，需要与kubernetes.io/elb.canary-by-header成对使用。 参数值为json格式的数组，例如： '{"values":["a","b"]}' 参数说明： 数组长度：最小值为1，最大值为10。 数组取值：长度限制1-128字符，不支持空格，双引号，支持以下通配符：*（匹配0个或更多字符）和？（正好匹配1个字符）。 kubernetes.io/elb.canary-by-cookie 否 string cookie灰度发布的key值，表示请求cookie参数的名称。需要与kubernetes.io/elb.canary-by-cookie-value成对使用。 参数说明： 长度限制1-100字符，支持包含字母、数字、以及 !%'"()*+,./:=?@^\\-_`~ 等字符。 kubernetes.io/elb.canary-by-cookie-value 否 string cookie灰度发布的values值，需要与kubernetes.io/elb.canary-by-cookie成对使用。 参数值为json格式的数组，例如： '{"values":["a","b"]}' 参数说明： 数组长度：最小值为1，最大值为10。 数组取值：长度限制1-100字符，不支持空格，支持包含字母、数字、以及 !%'"()*+,./:=?@^\\-_`~ 等字符。 kubernetes.io/elb.canary-related-ingress-uid 否 string 灰度发布Ingress关联的原始Ingress的uid信息，用于前端展示原始Ingress和灰度发布的Ingress的关联关系。 ● 参数格式：字符串 ● 取值：原始Ingress的metadata.uid字段

灰度发布服务部署 部署原服务。 部署名为origin-server的工作负载。 部署名为origin-service的service，关联刚创建的origin-server工作负载。（CCE Standard集群创建nodeport类型Service，Turbo集群创建ClusterIP类型Service） 部署名为origin-ingress的Ingress，关联刚创建的origin-service服务。 Ingress的配置如下： apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: origin-ingress namespace: default annotations: kubernetes.io/elb.port: '81' kubernetes.io/elb.id: e491f4e7-2351-4984-ad0a-8569e5e964a3 kubernetes.io/elb.class: performance spec: rules: - host: nginx1.com http: paths: - path: / backend: service: name: origin-service port: number: 81 property: ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH pathType: ImplementationSpecific ingressClassName: cce 灰度发布新版本服务。 部署新版本工作负载、服务和Ingress，使得流量能够通过权重或者头域导流到新版本服务上。 部署名为canary-server的工作负载。 部署名为canary-service的服务，关联刚创建的canary-server工作负载。（CCE Standard集群创建nodeport类型Service，Turbo集群创建ClusterIP类型Service） 部署名为canary-weight-ingress的Ingress，关联刚创建的canary-service服务，实现权重灰度发布。 Ingress的配置如下： apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: canary-weight-ingress namespace: default annotations: kubernetes.io/elb.canary: 'true' // 设置为true，表示启用canary注解功能。 kubernetes.io/elb.canary-weight: '40' // 权重值设置，表示对应请求40%的流量将被导流到新版本服务上。 kubernetes.io/elb.class: performance // 仅独享型ELB支持灰度发布 kubernetes.io/elb.id: e491f4e7-2351-4984-ad0a-8569e5e964a3 kubernetes.io/elb.port: '81' spec: ingressClassName: cce rules: - host: nginx1.com http: paths: - path: / pathType: ImplementationSpecific backend: service: name: canary-service port: number: 81 property: ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH 部署名为canary-header-ingress的Ingress，关联刚创建的canary-service服务，实现Header灰度发布。 Ingress的配置如下： apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: canary-header-ingress namespace: default annotations: kubernetes.io/elb.canary: 'true' kubernetes.io/elb.canary-by-header: 'location' // header的key值设置为location kubernetes.io/elb.canary-by-header-value: '{"values":["hz","sz","sh"]}' // header的value值设置为hz、sz、sh kubernetes.io/elb.class: performance kubernetes.io/elb.id: e491f4e7-2351-4984-ad0a-8569e5e964a3 kubernetes.io/elb.port: '81' spec: ingressClassName: cce rules: - host: nginx1.com http: paths: - path: / pathType: ImplementationSpecific backend: service: name: canary-service port: number: 80 property: ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH 查看灰度发布新版本服务是否成功。 查看Ingress创建： $ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE canary-header-ingress cce nginx1.com 88.88.88.165 80 46s canary-weight-ingress cce nginx1.com 88.88.88.165 80 117s origin-ingress cce nginx1.com 88.88.88.165 80 2m25s 查看ELB生成规则： 服务请求返回结果： 使用location：hz请求头的请求访问服务： $ curl -H "Host: nginx1.com" -H "location: hz" http://88.88.88.165:81/ 预期结果： $ new 多次访问，返回结果均为new 不使用请求头的请求访问服务： $ curl -H "Host: nginx1.com" http://88.88.88.165:81/ 预期结果：返回值40%为new，60%为old。 老版本服务下线。 新版本服务运行稳定后，需要下线老版本服务。下线流程将原服务Ingress中的Service修改为新版本服务的Service，使流量都路由到新版本服务上，然后删除灰度Ingress。 将原服务Ingress关联的Service更新为新版本Service。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: origin-ingress namespace: default annotations: kubernetes.io/elb.port: '81' kubernetes.io/elb.id: e491f4e7-2351-4984-ad0a-8569e5e964a3 kubernetes.io/elb.class: performance spec: rules: - host: nginx1.com http: paths: - path: / backend: service: name: canary-service port: number: 81 property: ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH pathType: ImplementationSpecific ingressClassName: cce 验证老版本服务是否下线完成。 使用带header和不带header的请求，多次访问。 $ curl -H "Host: nginx1.com" -H "location: hz" http://88.88.88.165:81/ $ curl -H "Host: nginx1.com" http://88.88.88.165:81/ 预期结果：输出均为new，无old返回。 确认老版本服务下线完成后，删除灰度发布Ingress。 $ kubectl delete ingress canary-weight-ingress canary-header-ingress

约束与限制 该特性存在集群版本限制，仅在以下版本中生效： v1.23集群：v1.23.14-r0 及以上版本 v1.25集群：v1.25.9-r0 及以上版本 v1.27集群：v1.27.6-r0 及以上版本 v1.28集群：v1.28.4-r0 及以上版本 其他更高版本的集群 创建灰度Ingress后，不应删除原Ingress。 单个ELB下的监听器，如果关联的多个Ingress配置了多个灰度策略，头域优先级最高，cookie次之，权重优先级最低。

集群信息 集群信息包括多个维度： 集群ID：集群资源唯一标识，创建成功后自动生成，可用于API接口调用等场景。 集群名称：集群创建成功后可以单击进行修改。 集群原名：修改集群名称后显示的集群原名，设置其他集群的名称时和该集群的原名同样不可以重复。 集群状态：当前集群的运行状态，详情请参见集群生命周期。 集群类别：显示当前集群为CCE Standard集群或CCE Turbo集群，两者差异请参见集群类型对比。 集群创建时间：显示集群创建的时间，CCE以该时间作为计费依据。

使用成本洞察 开通后，进入成本洞察界面，查看已接入集群的成本状况。您可以切换页签，进行年度、季度、月度成本分析报表查看。 图11 查看成本状况 表1 界面功能说明 名称 所属报告 说明 本年至今成本（去年同期、环比去年） 年度 本年至今：本年开始到最新账单日期产生的成本 去年同期：对比去年相同日期产生的成本 环比去年：（本年至今成本 - 去年同期成本）/ 去年同期成本 年末预测成本（去年同期、环比去年） 年度 年末预测成本：到本年年末预计产生的总成本开销 去年同期：去年整年产生的成本 环比去年：（年末预测成本 - 去年同期成本）/ 去年同期成本 本季至今成本（上季度同期、环比上季度） 季度 本季至今成本：本季开始到最新账单日期产生的成本 上季度同期：对比上季度相同日期产生的成本 环比上季度：（本季至今成本 - 上季度同期成本）/ 上季度同期成本 季末预测成本（上季度同期、环比上季度） 季度 季末预测成本：到本季度末，整季预估产生的总成本开销 上季度同期：上季度整季产生的成本 环比上季度：（季末预测成本 - 上季度同期成本）/ 上季度同期成本 本月至今成本（上月同期、环比上月） 月度 本月至今成本：本月开始到最新账单日期产生的成本 上月同期：对比上月相同日期产生的成本 环比上月：（本月至今成本 - 上月同期成本）/ 上月同期成本 月末预测成本（上月同期、环比上月） 月度 月末预测成本：到本月月末，整月预估产生的总成本开销 上月同期：上月整月产生的成本 环比上月：（月末预测成本 - 上月同期成本）/ 上月同期成本 总成本趋势 年度、季度、月度 呈现本年、本季度、本月成本详情，以及分别和上年、上季、上月的成本对比趋势

部门成本分析 在部门成本分析模块查看部门成本分析报告。 图12 查看部门成本分析 表2 部门成本明细报表功能说明 名称 所属报告 说明 部门名称 年度、季度、月度 部门配置名称 本年至今成本 年度 本年开始到最新账单日期产生的成本 去年同期成本 年度 对比去年相同日期产生的成本 去年总成本 年度 去年整年产生的成本 对比去年同期增长值 年度 本年至今成本 - 去年同期成本 对比去年同期增长率 年度 （本年至今成本 - 去年同期成本）/ 去年同期成本 本年CPU成本 年度 本年开始到最新账单日期产生的CPU成本 本年CPU成本占部门整体成本百分比 年度 本年CPU成本 / 本年至今成本（部门成本） 本年至今相比去年同期CPU增长成本 年度 本年CPU成本 - 去年同期CPU成本 本季至今成本 季度 本季开始到最新账单日期产生的成本 上季度同期成本 季度 对比上季度相同日期产生的成本 上季度总成本 季度 上季度整季产生的成本 对比上季度同期增长值 季度 本季至今成本 - 上季度同期成本 对比上季度同期增长率 季度 （本季至今成本 - 上季度同期成本）/ 上季度同期成本 本季度CPU成本 季度 本季开始到最新账单日期产生的CPU成本 本季度CPU成本占部门整体成本百分比 季度 本季CPU成本 / 本季至今成本（部门成本） 本季度相比上季度同期CPU增长成本 季度 本季CPU成本 - 上季度CPU成本 本月至今成本 月度 本月开始到最新账单日期产生的成本 上月同期成本 月度 对比上月相同日期产生的成本 上月总成本 月度 上月整月产生的成本 对比上月同期增长值 月度 本月至今成本 - 上月同期成本 对比上月同期增长率 月度 （本月至今成本 - 上月同期成本） / 上月同期成本 本月CPU成本 月度 本月开始到最新账单日期产生的CPU成本 本月CPU成本占部门整体成本百分比 月度 本月CPU成本 / 本月至今成本（部门成本） 本月相比上月同期CPU增长成本 月度 本月CPU成本 - 上月CPU成本

部门管理 登录CCE控制台，单击左侧导航栏中的“云原生成本治理”。 图5 云原生成本治理 单击“部门管理”，进行部门配置查看。 图6 部门管理 单击“编辑部门”，修改自定义部门配置。 图7 编辑部门 单击“下一步”，修改公共成本分摊到部门的比例。 图8 修改公共成本分摊 单击“提交配置”，便可以在部门管理界面看到配置的结果。 图9 提交配置 配置完成后，关闭部门管理界面，即可在云原生成本治理查看相应部门的成本分析报告。 图10 查看成本分析报告

使用密钥设置工作负载的环境变量 使用控制台方式 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏选择“工作负载”，单击右上角“创建工作负载”。 在创建工作负载时，在“容器配置”中找到“环境变量”，单击“新增变量”。 密钥导入：选择一个密钥，将密钥中所有键值都导入为环境变量。 密钥项键值导入：将密钥中某个键的值导入作为某个环境变量的值。 变量名称：工作负载中的环境变量名称，可自定义，默认为密钥中选择的键名。 变量/变量引用：选择一个密钥及需要导入的键名，将其对应的值导入为工作负载环境变量。 例如将mysecret这个密钥中“username”的值导入，作为工作负载环境变量“username”的值，导入后容器中将会有一个名为“username”的环境变量。 配置其他工作负载参数后，单击“创建工作负载”。 等待工作负载正常运行后，您可登录容器执行以下语句，查看该密钥是否已被设置为工作负载的环境变量。 printenv username 如输出与Secret中的内容一致，则说明该密钥已被设置为工作负载的环境变量。 使用kubectl方式 请参见通过kubectl连接集群配置kubectl命令。 创建并编辑nginx-secret.yaml文件。 vi nginx-secret.yaml YAML文件内容如下： 密钥导入：如果要将一个密钥中所有数据都添加到环境变量中，可以使用envFrom参数，密钥中的Key会成为工作负载中的环境变量名称。 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-secret spec: replicas: 1 selector: matchLabels: app: nginx-secret template: metadata: labels: app: nginx-secret spec: containers: - name: container-1 image: nginx:latest envFrom: # 使用envFrom来指定环境变量引用的密钥 - secretRef: name: mysecret # 引用的密钥名称 imagePullSecrets: - name: default-secret 密钥键值导入：您可以在创建工作负载时将密钥设置为环境变量，使用valueFrom参数单独引用Secret中的Key/Value。 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-secret spec: replicas: 1 selector: matchLabels: app: nginx-secret template: metadata: labels: app: nginx-secret spec: containers: - name: container-1 image: nginx:latest env: # 设置工作负载中的环境变量 - name: SECRET_USERNAME # 工作负载中的环境变量名称 valueFrom: # 使用valueFrom来指定环境变量引用的密钥 secretKeyRef: name: mysecret # 引用的密钥名称 key: username # 引用的密钥中的key - name: SECRET_PASSWORD # 添加多个环境变量参数，可同时导入多个环境变量 valueFrom: secretKeyRef: name: mysecret key: password imagePullSecrets: - name: default-secret 创建工作负载。 kubectl apply -f nginx-secret.yaml 创建完成后，查看Pod中的环境变量。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep nginx-secret 预期输出如下： nginx-secret-*** 1/1 Running 0 2m18s 执行以下命令，查看该Pod中的环境变量。 kubectl exec nginx-secret-*** -- printenv SPECIAL_USERNAME SPECIAL_PASSWORD 如输出与Secret中的内容一致，则说明该密钥已被设置为工作负载的环境变量。

操作步骤 集群升级步骤包括：升级前检查、备份、配置与升级、升级后处理。 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏选择“集群升级”。 根据当前集群版本，系统将为您生成最佳升级路径，您可以在该路径中选择需要升级的版本，确认集群版本差异、插件版本等信息，然后单击“前往升级”。 进行升级前检查，单击“开始检查”并确认。如集群中存在异常项或风险项，请根据页面提示的检查结果进行处理，处理完成后需重新进行升级前检查。 异常项：请查看页面提示的解决方案并处理异常后，重新进行升级前检查。 风险项：表示该结果可能会影响集群升级结果，请您查看风险说明并确认您是否处于风险影响范围。如确认无风险，可单击该风险项后的“确认”按钮，手动跳过该风险项，然后重新进行升级前检查。 待升级前检查通过后，单击“下一步”。 进行集群备份。集群升级过程中将自动进行etcd数据备份，您可手动进行Master节点备份，以加快Master节点升级失败时的回滚速度，如无需手动备份可直接单击“下一步”。 备份方式 备份对象 备份方式 备份时间 回滚时间 说明 etcd数据备份 etcd数据 升级流程中自动备份 1-5min 2h 必选备份，升级过程中自动进行，用户无需关注 EVS快照备份 Master节点磁盘，包括组件镜像、配置、日志以及etcd数据 通过页面一键备份（手动触发） 1-5min 20min - 配置升级参数。 插件升级配置：此处列出了您的集群中已安装的插件。在集群升级过程中系统会自动升级已选择的插件，以兼容升级后的集群版本，您可以单击插件右侧的“配置”重新定义插件参数。 插件右侧如有标记，表示当前插件不能同时兼容集群升级起始和目标版本，在集群版本升级完成后将为您升级该插件 ，该插件在集群升级过程中可能无法正常使用。 配置完成后，单击“立即升级”按钮，并确认升级操作后集群开始升级。您可以在页面下方查看版本升级的进程。 若在集群升级过程中出现升级失败的提示，请参照提示信息修复问题后重试。 升级完成后，单击“下一步”，请根据页面提示的检查项进行升级后验证。确认所有检查项均正常后，可单击“完成”按钮，并确认完成升级后检查，详情请参见升级后验证。 您可以在集群列表页面查看集群当前的Kubernetes版本，确认升级成功。

通过kubectl命令行动态挂载本地持久卷 使用kubectl连接集群。 创建statefulset-local.yaml文件，本示例中将本地持久卷挂载至/data路径。 apiVersion: apps/v1 kind: StatefulSet metadata: name: statefulset-local namespace: default spec: selector: matchLabels: app: statefulset-local template: metadata: labels: app: statefulset-local spec: containers: - name: container-1 image: nginx:latest volumeMounts: - name: pvc-local # 需与volumeClaimTemplates字段中的名称对应 mountPath: /data # 存储卷挂载的位置 imagePullSecrets: - name: default-secret serviceName: statefulset-local # Headless Service名称 replicas: 2 volumeClaimTemplates: - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-local namespace: default annotations: everest.io/csi.volume-name-prefix: test # 可选字段，定义自动创建的底层存储名称前缀 spec: accessModes: - ReadWriteOnce # 本地持久卷必须为ReadWriteOnce resources: requests: storage: 10Gi # 存储卷容量大小 storageClassName: csi-local-topology # StorageClass类型为本地持久卷 --- apiVersion: v1 kind: Service metadata: name: statefulset-local # Headless Service名称 namespace: default labels: app: statefulset-local spec: selector: app: statefulset-local clusterIP: None ports: - name: statefulset-local targetPort: 80 nodePort: 0 port: 80 protocol: TCP type: ClusterIP 表2 关键参数说明 参数 是否必选 描述 everest.io/csi.volume-name-prefix 否 可选字段，集群版本为v1.23.14-r0、v1.25.9-r0、v1.27.6-r0、v1.28.4-r0及以上时支持，且集群中需安装2.4.15及以上版本的Everest插件。 定义自动创建的底层存储名称，实际创建的底层存储名称为“存储卷名称前缀”与“PVC UID”的拼接组合，如果不填写该参数，默认前缀为“pvc”。 取值范围：参数值长度为1~26，且必须是小写字母、数字、中划线，不能以中划线开头或结尾。 例如，存储卷名称前缀设置为“test”，则实际创建的底层存储名称test-{uid}。 storage 是 PVC申请容量，单位为Gi。 storageClassName 是 本地持久卷对应的存储类名称为csi-local-topology。 执行以下命令，创建一个挂载本地持久卷存储的应用。 kubectl apply -f statefulset-local.yaml 工作负载创建成功后，您可以尝试验证数据持久化。

验证数据持久化 查看部署的应用及文件。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep statefulset-local 预期输出如下： statefulset-local-0 1/1 Running 0 45s statefulset-local-1 1/1 Running 0 28s 执行以下命令，查看本地持久卷是否挂载至/data路径。 kubectl exec statefulset-local-0 -- df | grep data 预期输出如下： /dev/mapper/vg--everest--localvolume--persistent-pvc-local 10255636 36888 10202364 0% /data 执行以下命令，查看/data路径下的文件。 kubectl exec statefulset-local-0 -- ls /data 预期输出如下： lost+found 执行以下命令，在/data路径下创建static文件。 kubectl exec statefulset-local-0 -- touch /data/static 执行以下命令，查看/data路径下的文件。 kubectl exec statefulset-local-0 -- ls /data 预期输出如下： lost+found static 执行以下命令，删除名称为web-local-auto-0的Pod。 kubectl delete pod statefulset-local-0 预期输出如下： pod "statefulset-local-0" deleted 删除后，StatefulSet控制器会自动重新创建一个同名副本。执行以下命令，验证/data路径下的文件是否更改。 kubectl exec statefulset-local-0 -- ls /data 预期输出如下： lost+found static static文件仍然存在，则说明本地持久卷中的数据可持久化保存。

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

使用场景 动态挂载仅可在创建有状态负载时使用，通过卷声明模板（volumeClaimTemplates字段）实现，并依赖于StorageClass的动态创建PV能力。在多实例的有状态负载中，动态挂载可以为每一个Pod关联一个独有的PVC及PV，当Pod被重新调度后，仍然能够根据该PVC名称挂载原有的数据。而在无状态工作负载的普通挂载方式中，当存储支持多点挂载（ReadWriteMany）时，工作负载下的多个Pod会被挂载到同一个底层存储中。

公平调度介绍 在实际业务中，经常会遇到将集群稀缺资源分配给多个用户的情况，每个用户获得资源的权利都相同，但是需求数却可能不同，如何公平的将资源分配给每个用户是一项非常有意义的事情。调度层面有一种常用的方法为最大最小化公平分配算法（max-min fairness share），尽量满足用户中的最小的需求，然后将剩余的资源公平分配给剩下的用户。形式化定义如下： 资源分配以需求递增的方式进行分配 每个用户获得的资源不超过其需求 未得到满足的用户等价平分剩下的资源

创建LoadBalancer类型Service 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“服务”，在右上角单击“创建服务”。 设置参数。 Service名称：自定义服务名称，可与工作负载名称保持一致。 访问类型：选择“负载均衡 LoadBalancer”。 命名空间：工作负载所在命名空间。 服务亲和： 集群级别：集群下所有节点的IP+访问端口均可以访问到此服务关联的负载，服务访问会因路由跳转导致一定性能损失，且无法获取到客户端源IP。 选择器：添加标签，Service根据标签选择Pod，填写后单击“确认添加”。也可以引用已有工作负载的标签，单击“引用负载标签”，在弹出的窗口中选择负载，然后单击“确定”。 负载均衡器：选择弹性负载均衡的类型、创建方式。 ELB类型可选择“独享型”，独享型ELB可以根据支持的协议类型选择“网络型（TCP/UDP）”、“应用型（HTTP/HTTPS）”或“网络型（TCP/UDP）&应用型（HTTP/HTTPS）”。 创建方式可选择“选择已有”或“自动创建”。不同创建方式的配置详情请参见表1。 表1 ELB配置 创建方式 配置 选择已有 仅支持选择与集群在同一个VPC下的ELB实例。如果没有可选的ELB实例，请单击“创建负载均衡器”跳转到ELB控制台创建。 自动创建 实例名称：请填写ELB名称。 企业项目：该参数仅对开通企业项目的企业客户账号显示。企业项目是一种云资源管理方式，企业项目管理服务提供统一的云资源按项目管理，以及项目内的资源管理、成员管理。 可用区：可以选择在多个可用区创建负载均衡实例，提高服务的可用性。如果业务需要考虑容灾能力，建议选择多个可用区。 前端子网：用于分配ELB实例对外服务的IP地址。 后端子网：用于与后端服务建立连接的IP地址。 网络型规格/应用型规格/规格： 弹性规格：适用于业务用量波动较大的场景，按实际使用量收取每小时使用的容量费用。 固定规格：适用于业务用量较为稳定的场景，按固定规格折算收取每小时使用的容量费用。 弹性公网IP：选择“自动创建”时，可配置公网带宽的计费方式及带宽大小。 资源标签：通过为资源添加标签，可以对资源进行自定义标记，实现资源的分类。您可以在TMS中创建“预定义标签”，预定义标签对所有支持标签功能的服务资源可见，通过使用预定义标签可以提升标签创建和迁移效率。v1.27.5-r0、v1.28.3-r0及以上版本集群支持。 负载均衡配置：您可以单击负载均衡配置的“编辑”图标配置ELB实例的参数，在弹出窗口中配置ELB实例的参数。 分配策略：可选择加权轮询算法、加权最少连接或源IP算法。 加权轮询算法：根据后端服务器的权重，按顺序依次将请求分发给不同的服务器。它用相应的权重表示服务器的处理性能，按照权重的高低以及轮询方式将请求分配给各服务器，相同权重的服务器处理相同数目的连接数。常用于短连接服务，例如HTTP等服务。 加权最少连接：最少连接是通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法。加权最少连接就是在最少连接数的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权重，使其能够接受相应权值数的服务请求。常用于长连接服务，例如数据库连接等服务。 源IP算法：将请求的源IP地址进行Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源IP的访问进行负载分发，同时使得同一个客户端IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无cookie功能的TCP协议。 会话保持类型：默认不启用，可选择“源IP地址”。基于源IP地址的简单会话保持，即来自同一IP地址的访问请求转发到同一台后端服务器上。 当分配策略使用源IP算法时，不支持设置会话保持。 健康检查：设置负载均衡的健康检查配置。 全局检查：全局检查仅支持使用相同协议的端口，无法对多个使用不同协议的端口生效，建议使用“自定义检查”。 自定义检查：在端口配置中对多种不同协议的端口设置健康检查。 表2 健康检查参数 参数 说明 协议 当端口配置协议为TCP时，支持TCP和HTTP协议；当端口配置协议为UDP时，支持UDP协议。 检查路径（仅HTTP健康检查协议支持）：指定健康检查的URL地址。检查路径只能以/开头，长度范围为1-80。 端口 健康检查默认使用业务端口作为健康检查的端口；您也可以重新指定端口用于健康检查，重新指定端口会为服务增加一个名为cce-healthz的服务端口配置。 容器端口：使用独享型负载均衡关联ENI实例时，容器端口作为健康检查的检查端口。取值范围为1-65535。 检查周期（秒） 每次健康检查响应的最大间隔时间，取值范围为1-50。 超时时间（秒） 每次健康检查响应的最大超时时间，取值范围为1-50。 最大重试次数 健康检查最大的重试次数，取值范围为1-10。 端口配置： 协议：请根据业务的协议类型选择。 服务端口：Service使用的端口，端口范围为1-65535。 容器端口：工作负载程序实际监听的端口，需用户确定。例如nginx默认使用80端口。 监听器前端协议：ELB监听器的前端协议，是客户端与负载均衡监听器建立流量分发连接所使用的协议。当选择独享型负载均衡器类型时，包含“应用型（HTTP/HTTPS）”方可支持配置HTTP/HTTPS。 健康检查：健康检查选项设置为“自定义检查”时，可以为不同协议的端口配置健康检查，参数说明请参见表2。 在创建LoadBalancer类型Service时，会自动生成一个随机节点端口号（NodePort）。 注解：LoadBalancer类型Service有一些CCE定制的高级功能，通过注解annotations实现，具体注解的内容请参见使用Annotation配置负载均衡。 单击“确定”，创建Service。

操作场景 负载均衡（LoadBalancer）类型的服务可以通过弹性负载均衡（ELB）从公网访问到工作负载，与弹性IP方式相比提供了高可靠的保障。负载均衡访问方式由公网弹性负载均衡服务地址以及设置的访问端口组成，例如“10.117.117.117:80”。 在使用CCE Autopilot集群 + 独享型ELB实例时，支持ELB直通Pod，使部署在容器中的业务时延降低、性能无损耗。 从集群外部访问时，从ELB直接转发到Pod；集群内部访问可通过Service转发到Pod。 图1 ELB直通容器

通过kubectl命令行创建 Service使用HTTP/HTTPS协议时，需要添加如下annotation： kubernetes.io/elb.protocol-port: "https:443,http:80" protocol-port的取值需要和service的spec.ports字段中的端口对应，格式为protocol:port，port中的端口会匹配service.spec.ports中端口，并将该端口发布成对应的protocol协议。 kubernetes.io/elb.cert-id: "17e3b4f4bc40471c86741dc3aa211379" cert-id内容为ELB证书管理的证书ID，当protocol-port指定了https协议，ELB监听器的证书会设置为服务器证书，当发布多个HTTPS的服务，会使用同一份证书。 以自动创建独享型ELB为例，配置示例如下，其中关键配置通过红色字体标出： 不同的ELB类型以及集群版本对flavor存在不同的要求，详情请参见表1。 spec.ports中两个端口需要与kubernetes.io/elb.protocol-port中对应，本例中将443端口、80端口分别发布成HTTPS、HTTP协议。 apiVersion: v1 kind: Service metadata: annotations: # 在自动创建ELB参数中指定4层和7层的flavor kubernetes.io/elb.autocreate: ' { "type": "public", "bandwidth_name": "cce-bandwidth-1634816602057", "bandwidth_chargemode": "bandwidth", "bandwidth_size": 5, "bandwidth_sharetype": "PER", "eip_type": "5_bgp", "available_zone": [ "cn-north-4b" ], "l7_flavor_name": "L7_flavor.elb.s2.small", "l4_flavor_name": "L4_flavor.elb.s1.medium" }' kubernetes.io/elb.class: performance # 独享型ELB kubernetes.io/elb.protocol-port: "https:443,http:80" # HTTP/HTTPS协议及端口号，需要与spec.ports中的端口号对应 kubernetes.io/elb.cert-id: "17e3b4f4bc40471c86741dc3aa211379" # ELB服务中的证书ID labels: app: nginx name: test name: test namespace: default spec: ports: - name: cce-service-0 port: 443 protocol: TCP targetPort: 80 - name: cce-service-1 port: 80 protocol: TCP targetPort: 80 selector: app: nginx version: v1 sessionAffinity: None type: LoadBalancer 使用上面的示例创建Service，在新建的ELB实例中可以看到创建了443端口和80端口的监听器。

通过控制台创建 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“服务”，在右上角单击“创建服务”。 设置Service参数。本示例中仅列举使用HTTP/HTTPS协议必选参数，其余参数可根据需求参考创建LoadBalancer类型Service进行设置。 Service名称：自定义服务名称，可与工作负载名称保持一致。 访问类型：选择“负载均衡”。 选择器：添加标签，Service根据标签选择Pod，填写后单击“确认添加”。也可以引用已有工作负载的标签，单击“引用负载标签”，在弹出的窗口中选择负载，然后单击“确定”。 负载均衡器：选择弹性负载均衡的类型、创建方式。 类型：“独享型”或“共享型”，其中独享型ELB需选择“应用型（HTTP/HTTPS）”或“网络型（TCP/UDP/TLS）&应用型（HTTP/HTTPS）”，否则监听器端口将无法启用HTTP/HTTPS。 创建方式：本文中以选择已有ELB为例进行说明，关于自动创建的配置参数请参见表1。 端口配置： 协议：请选择TCP协议，选择UDP协议将无法使用HTTP/HTTPS。 服务端口：Service使用的端口，端口范围为1-65535。 容器端口：工作负载程序实际监听的端口，需用户确定。例如nginx默认使用80端口。 监听器前端协议：设置监听器端口是否开启HTTP/HTTPS。当选择独享型负载均衡器类型时，需包含“应用型（HTTP/HTTPS）”方可支持配置HTTP/HTTPS。 监听器配置： SSL解析方式：当监听器端口启用HTTPS时可选择SSL解析方式。 单向认证：仅进行服务器端认证。如需认证客户端身份，请选择双向认证。 双向认证：双向认证需要负载均衡实例与访问用户互相提供身份认证，从而允许通过认证的用户访问负载均衡实例，后端服务器无需额外配置双向认证。 CA证书：SSL解析方式选择“双向认证”时需要添加CA证书，用于认证客户端身份。CA证书又称客户端CA公钥证书，用于验证客户端证书的签发者；在开启HTTPS双向认证功能时，只有当客户端能够出具指定CA签发的证书时，HTTPS连接才能成功。 服务器证书：当监听器端口启用HTTPS时，必须选择一个服务器证书。如果当前无可选证书，需前往弹性负载均衡控制台进行创建，详情请参见创建证书。 SNI：当监听器端口启用HTTPS时，可以选择是否添加SNI证书。如果需要添加SNI证书，证书中必须包含域名。如果当前无可选证书，需前往弹性负载均衡控制台进行创建，详情请参见创建证书。 当发布多个HTTPS的服务，所有监听器会使用相同的证书配置。 图1 配置HTTP/HTTPS协议 单击“确定”，创建Service。

约束与限制 Service使用HTTP/HTTPS协议仅v1.19.16及以上版本集群支持。 表1 ELB支持HTTP/HTTPS协议的场景 ELB类型 使用场景 是否支持HTTP/HTTPS协议 说明 共享型ELB 对接已有ELB 支持 - 自动创建ELB 支持 - 独享型ELB 对接已有ELB 支持（需使用YAML创建） v1.19.16-r50、v1.21.11-r10、v1.23.9-r10、v1.25.4-r10、v1.27.1-r10以下版本：需要同时支持4层和7层的flavor v1.19.16-r50、v1.21.11-r10、v1.23.9-r10、v1.25.4-r10、v1.27.1-r10及以上版本：需要支持7层的flavor 自动创建ELB 支持（需使用YAML创建） v1.19.16-r50、v1.21.11-r10、v1.23.9-r10、v1.25.4-r10、v1.27.1-r10以下版本：需要同时支持4层和7层的flavor v1.19.16-r50、v1.21.11-r10、v1.23.9-r10、v1.25.4-r10、v1.27.1-r10及以上版本：需要支持7层的flavor 请勿将Ingress与使用HTTP/HTTPS的Service对接同一个ELB下的同一个监听器，否则将产生端口冲突。

命名空间类别 命名空间按创建类型分为两大类：集群默认创建的、用户创建的。 集群默认创建的：集群在启动时会默认创建default、kube-public、kube-system、kube-node-lease命名空间。 default：所有未指定Namespace的对象都会被分配在default命名空间。 kube-public：此命名空间下的资源可以被所有人访问（包括未认证用户），使集群中的某些资源可以在整个集群范围内可见可读。 该命名空间为Kubernetes预留的命名空间，其公共属性只是一种约定而并非要求。 kube-system：所有由Kubernetes系统创建的资源都处于这个命名空间。 kube-node-lease：每个节点在该命名空间中都有一个关联的“Lease”对象，该对象由节点定期更新。NodeStatus和NodeLease都被视为来自节点的心跳，在v1.13之前的版本中，节点的心跳只有NodeStatus，NodeLease特性从v1.13开始引入。NodeLease比NodeStatus更轻量级，该特性在集群规模扩展性和性能上有明显提升。 用户创建的：用户可以按照需要创建命名空间，例如开发环境、联调环境和测试环境分别创建对应的命名空间。或者按照不同的业务创建对应的命名空间，例如系统若分为登录和游戏服务，可以分别创建对应命名空间。

创建命名空间 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“命名空间”，在右上角单击“创建命名空间”。 参照表1设置命名空间参数。 表1 命名空间基本信息 参数 参数说明 名称 新建命名空间的名称，命名必须唯一。 描述 输入对命名空间的描述信息。 配额管理 资源配额可以限制命名空间下的资源使用，进而支持以命名空间为粒度的资源划分。 须知： 建议根据需要在命名空间中设置资源配额，避免因资源过载导致集群或节点异常。 例如：在集群中每个节点可以创建的实例（Pod）数默认为110个，如果您创建的是50节点规格的集群，则最多可以创建5500个实例。因此，您可以在命名空间中自行设置资源配额以确保所有命名空间内的实例总数不超过5500个，以避免资源过载。 请输入整型数值，不输入表示不限制该资源的使用。 若您需要限制CPU或内存的配额，则创建工作负载时必须指定CPU或内存请求值。 配置完成后，单击“确定”。

使用kubectl创建Namespace 使用如下方式定义Namespace。 apiVersion: v1 kind: Namespace metadata: name: custom-namespace 使用kubectl命令创建。 $ kubectl create -f custom-namespace.yaml namespace/custom-namespace created 您还可以使用kubectl create namespace命令创建。 $ kubectl create namespace custom-namespace namespace/custom-namespace created

VPC网络模型 VPC网络采用VPC路由方式与底层网络深度整合，适用于高性能场景，节点数量受限于虚拟私有云VPC的路由配额。每个节点将会被分配固定大小的IP地址段。VPC网络由于没有隧道封装的消耗，容器网络性能相对于容器隧道网络有一定优势。VPC网络集群由于VPC路由中配置有容器网段与节点IP的路由，可以支持同一VPC内的云服务器从集群外直接访问容器实例等特殊场景。 图1 VPC网络 说明如下： 节点内Pod间通信：ipvlan子接口分配给节点上的Pod，同节点的Pod间通信直接通过ipvlan直接转发。 跨节点Pod间通信：所有跨节点Pod间的通信通过默认路由到默认网关，借助VPC的路由转发能力，转发到对端节点上。

网段规划建议 在集群网络构成中介绍集群中网络地址可分为节点网络、容器网络、服务网络三块，在规划网络地址时需要从如下方面考虑： 三个网段不能重叠，否则会导致冲突。且集群所在VPC下所有子网（包括扩展网段子网）不能和容器网段、服务网段冲突。 保证每个网段有足够的IP地址可用。 节点网段的IP地址要与集群规模相匹配，否则会因为IP地址不足导致无法创建节点。 容器网段的IP地址要与业务规模相匹配，否则会因为IP地址不足导致无法创建Pod。每个节点上可以创建多少Pod还与其他参数设置相关，具体请参见节点可创建的最大Pod数量说明。 例如集群规模为200节点，容器网络模型为VPC网络。 则此时选择节点子网的可用IP数量需要超过200，否则会因为IP地址不足导致无法创建节点。 容器网段为10.0.0.0/16，可用IP数量为65536，如容器IP地址管理中所述，VPC网络IP分配是分配固定大小的网段（使用掩码实现，确定每个节点最多分配多少容器IP），例如上限为128，则此时集群最多支撑65536/128=512个节点。 图4 容器网段配置（创建集群时配置）

容器IP地址管理 VPC网络按如下规则分配容器IP： 容器网段需单独分配 节点维度划分地址段，集群的所有节点从容器网段中分配一个固定大小（用户自己配置）的IP网段 容器网段依次循环分配IP网段给新增节点 调度到节点上的Pod依次循环从分配给节点的IP网段内分配IP地址 图2 VPC网络IP地址管理 按如上IP分配，VPC网络的集群最多能创建节点数量 = 容器网段IP数量 ÷ 节点从容器网段中分配IP网段的IP数量 比如容器网段为172.16.0.0/16，则IP数量为65536，节点分配容器网段掩码为25，也就是每个节点容器IP数量为128，则最多可创建节点数量为65536/128=512。另外，集群能创建多少节点，还受节点网络和集群规模的影响。 图3 容器网段配置（创建集群时配置）

验证数据持久化 查看部署的应用及云硬盘文件。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep statefulset-evs 预期输出如下： statefulset-evs-0 1/1 Running 0 45s statefulset-evs-1 1/1 Running 0 28s 执行以下命令，查看云硬盘是否挂载至/data路径。 kubectl exec statefulset-evs-0 -- df | grep data 预期输出如下： /dev/sdd 10255636 36888 10202364 0% /data 执行以下命令，查看/data路径下的文件。 kubectl exec statefulset-evs-0 -- ls /data 预期输出如下： lost+found 执行以下命令，在/data路径下创建static文件。 kubectl exec statefulset-evs-0 -- touch /data/static 执行以下命令，查看/data路径下的文件。 kubectl exec statefulset-evs-0 -- ls /data 预期输出如下： lost+found static 执行以下命令，删除名称为web-evs-auto-0的Pod。 kubectl delete pod statefulset-evs-0 预期输出如下： pod "statefulset-evs-0" deleted 删除后，StatefulSet控制器会自动重新创建一个同名副本。执行以下命令，验证/data路径下的文件是否更改。 kubectl exec statefulset-evs-0 -- ls /data 预期输出如下： lost+found static static文件仍然存在，则说明云硬盘中的数据可持久化保存。

使用场景 动态挂载仅可在创建有状态负载时使用，通过卷声明模板（volumeClaimTemplates字段）实现，并依赖于StorageClass的动态创建PV能力。在多实例的有状态负载中，动态挂载可以为每一个Pod关联一个独有的PVC及PV，当Pod被重新调度后，仍然能够根据该PVC名称挂载原有的数据。而在无状态工作负载的普通挂载方式中，当存储支持多点挂载（ReadWriteMany）时，工作负载下的多个Pod会被挂载到同一个底层存储中。

Kubernetes中的域名解析逻辑 DNS策略可以在每个pod基础上进行设置，目前，Kubernetes支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种DNS策略，具体请参见Service与Pod的DNS。这些策略在pod-specific的dnsPolicy字段中指定。 “Default”：如果dnsPolicy被设置为“Default”，则名称解析配置将从pod运行的节点继承。 自定义上游域名服务器和存根域不能够与这个策略一起使用。 “ClusterFirst”：如果dnsPolicy被设置为“ClusterFirst”，任何与配置的集群域后缀不匹配的DNS查询（例如，www.kubernetes.io）将转发到从该节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游DNS服务器。 “ClusterFirstWithHostNet”：对于使用hostNetwork运行的Pod，您应该明确设置其DNS策略“ClusterFirstWithHostNet”。 “None”：它允许Pod忽略Kubernetes环境中的DNS设置。应使用dnsConfigPod规范中的字段提供所有DNS设置 。 Kubernetes 1.10及以上版本，支持Default、ClusterFirst、ClusterFirstWithHostNet和None四种策略；低于Kubernetes 1.10版本，仅支持default、ClusterFirst和ClusterFirstWithHostNet三种。 “Default”不是默认的DNS策略。如果dnsPolicy的Flag没有特别指明，则默认使用“ClusterFirst”。 路由请求流程： 未配置存根域：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游域名服务器。 已配置存根域：如果配置了存根域和上游DNS服务器，DNS查询将基于下面的流程对请求进行路由： 查询首先被发送到coredns中的DNS缓存层。 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的DNS上： 具有集群后缀的名字（例如“.cluster.local”）：请求被发送到coredns。 具有存根域后缀的名字（例如“.acme.local”）：请求被发送到配置的自定义DNS解析器（例如：监听在 1.2.3.4）。 未能匹配上后缀的名字（例如“widget.com”）：请求被转发到上游DNS。 图1 路由请求流程

插件简介 CoreDNS域名解析插件是一款通过链式插件的方式为Kubernetes提供域名解析服务的DNS服务器。 CoreDNS是由CNCF孵化的开源软件，用于Cloud-Native环境下的DNS服务器和服务发现解决方案。CoreDNS实现了插件链式架构，能够按需组合插件，运行效率高、配置灵活。在Kubernetes集群中使用CoreDNS能够自动发现集群内的服务，并为这些服务提供域名解析。同时，通过级联云上DNS服务器，还能够为集群内的工作负载提供外部域名的解析服务。 该插件为系统资源插件，在创建集群时默认安装。 目前CoreDNS已经成为社区Kubernetes集群推荐的DNS服务器解决方案。 CoreDNS官网：https://coredns.io/ 开源社区地址：https://github.com/coredns/coredns DNS详细使用方法请参见DNS。

节点固有标签 节点创建出来会存在一些固有的标签，并且是无法删除的，这些标签的含义请参见表1。 系统自动添加的节点固有标签不建议手动修改，如果手动修改值与系统值产生冲突，将以系统值为准。 表1 节点固有标签 键 说明 新：topology.kubernetes.io/region 旧：failure-domain.beta.kubernetes.io/region 表示节点当前所在区域。 新：topology.kubernetes.io/zone 旧：failure-domain.beta.kubernetes.io/zone 表示节点所在区域的可用区。 新：node.kubernetes.io/baremetal 旧：failure-domain.beta.kubernetes.io/is-baremetal 表示是否为裸金属节点。 例如：false，表示非裸金属节点 node.kubernetes.io/container-engine 表示容器引擎。 例如：docker、containerd node.kubernetes.io/instance-type 节点实例规格。 kubernetes.io/arch 节点处理器架构。 kubernetes.io/hostname 节点名称。 kubernetes.io/os 节点操作系统类型。 node.kubernetes.io/subnetid 节点所在子网的ID。 os.architecture 表示节点处理器架构。 例如：amd64，表示AMD64位架构的处理器 os.name 节点的操作系统名称。 os.version 操作系统节点内核版本。 node.kubernetes.io/container-engine 节点所用容器引擎。 accelerator/huawei-npu NPU节点标签。 accelerator GPU节点标签。 cce.cloud.com/cce-nodepool 节点池节点专属标签。