华为云用户手册

升级方式 表1 升级方式介绍 升级方式 介绍 升级范围 优点 约束 原地升级 节点上升级Kubernetes组件、网络组件和CCE管理组件，升级过程中业务Pod和网络均不受影响。 升级过程中，节点分批进行升级，存量节点将不可调度，升级完成的批次支持调度新业务。 节点操作系统不升级 插件在目标版本集群不兼容时自动升级 K8s组件自动升级 可一键式升级，用户无需迁移业务，可以基本上保证业务不断。 原地升级仅在v1.15及以上版本集群支持。 迁移 将老版本集群的业务迁移到新版本集群，适用于需要大幅度跨版本集群升级的需求。 集群内资源均重新部署。 可避免老版本连续升级导致的版本不兼容问题。 -

集群升级流程 集群升级流程包括升级前检查、备份、升级和升级后验证几个步骤，下面介绍集群升级过程中的相关流程。 图1 集群升级流程 在确定集群的目标版本后，请您仔细阅读升级注意事项，避免升级时出现功能不兼容的问题。 升级前检查 升级集群前，CCE会对您的集群进行必要的检查，包括集群状态、插件状态、节点状态、工作负载兼容性等多方面进行检查，确保集群满足升级的条件，检查项目请参考升级前检查项。如果出现检查异常项，请参考控制台中的提示进行修复。 备份 通过硬盘快照的方式帮您备份集群控制节点，以保存CCE组件镜像、组件配置、Etcd数据等关键数据。建议您在升级前进行备份。如果在升级过程中出现不可预期的情况，可以基于备份为您快速恢复集群。 备份方式 备份对象 备份方式 备份时间 回滚时间 说明 etcd数据备份 etcd数据 升级流程中自动备份 1-5min 2h 必选备份，升级过程中自动进行，用户无需关注 CBR整机备份 Master节点磁盘，包括组件镜像、配置、日志以及etcd数据 通过页面一键备份（手动触发） 20min-2h（受当前区域云备份任务排队情况影响） 20min 该功能逐步由EVS快照备份替代 EVS快照备份 Master节点磁盘，包括组件镜像、配置、日志以及etcd数据 通过页面一键备份（手动触发） 1-5min 20min 该功能上线中 对于已上线的区域，EVS快照备份将替代CBR整机备份 配置与升级 执行升级前，需要对升级参数进行配置，我们已为您提供了默认配置，您也可以根据需要进行配置，升级参数配置完成后，将进入正式升级流程，对插件、控制节点、用户节点依次进行升级。 插件升级配置：此处列出了您的集群中已安装的插件。在集群升级过程中系统会自动升级已选择的插件，以兼容升级后的集群版本，您可以单击插件右侧的“配置”重新定义插件参数。 插件右侧如有标记，表示当前插件不能同时兼容集群升级起始和目标版本，在集群版本升级完成后将为您升级该插件 ，该插件在集群升级过程中可能无法正常使用。 节点升级配置 每批最大升级节点数：您可以设置每批升级的最大节点数量。 升级时节点池之间会依次进行升级。节点池内的节点分批升级，第一批升级1个节点，第二批升级2个节点，后续每批升级节点数以2的幂数增加，直到达到您设置的每批最大升级节点数，并会持续作用在下一个节点池中。默认每批最大升级节点数为20，最高可配置为60。 节点优先级配置：您可以自行定义节点升级的优先级顺序。如不设置该优先级，系统将根据默认策略生成优先级顺序执行升级。 添加节点池优先级：自定义节点池升级的优先级顺序。如不设置，默认策略为节点数量少的节点池优先升级。 添加节点优先级：自定义节点池内节点升级的优先级顺序。如不设置，默认策略为负载较轻(根据节点Pod数量、节点资源请求率、节点PV数量等维度计算负载情况)的节点优先升级。 升级后验证 升级完成后，会自动为集群执行集群状态检查、节点状态检查等，您需要手动进行业务验证、新建节点验证、新建Pod验证等，确保升级后集群功能正常。详情请参见升级后验证。

步骤3：为工作负载创建Service及Ingress 复制以下YAML内容创建grpc-svc.yaml文件。 apiVersion: v1 kind: Service metadata: name: grpc-hello namespace: default labels: app: grpc-hello spec: ports: - name: cce-service-0 protocol: TCP port: 50051 targetPort: 50051 selector: app: grpc-hello type: NodePort sessionAffinity: None 执行以下命令创建Service： kubectl apply -f grpc-svc.yaml 复制以下YAML内容创建grpc-ingress.yaml文件。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: grpc-hello namespace: default annotations: nginx.ingress.kubernetes.io/backend-protocol: GRPC # 指定后端服务为gRPC服务 spec: ingressClassName: nginx tls: - secretName: grpc-secret rules: - host: grpc.example.com http: paths: - path: / pathType: Prefix backend: service: name: grpc-hello port: number: 50051 执行以下命令创建Ingress路由规则。 kubectl apply -f grpc-ingress.yaml

步骤2：创建gRPC应用的工作负载 在集群中创建使用gRPC协议的工作负载。 复制以下YAML内容创建grpc.yaml文件。本文中使用官方示例应用构建的Docker镜像作为示例。 apiVersion: apps/v1 kind: Deployment metadata: annotations: description: '' labels: appgroup: '' version: v1 name: grpc-hello namespace: default spec: selector: matchLabels: app: grpc-hello version: v1 template: metadata: labels: app: grpc-hello version: v1 spec: containers: - name: container-1 image: swr.cn-east-3.myhuaweicloud.com/container/grpc-hello:latest #本文镜像仅作示例 imagePullPolicy: IfNotPresent imagePullSecrets: - name: default-secret terminationGracePeriodSeconds: 30 dnsPolicy: ClusterFirst replicas: 1 执行以下命令创建工作负载。 kubectl apply -f grpc.yaml

步骤1：创建SSL证书 复制以下内容并保存至openssl.cnf文件中。 [req] distinguished_name = req_distinguished_name attributes = req_attributes [req_distinguished_name] [req_attributes] [test_ca] basicConstraints = critical,CA:TRUE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always keyUsage = critical,keyCertSign [test_server] basicConstraints = critical,CA:FALSE subjectKeyIdentifier = hash keyUsage = critical,digitalSignature,keyEncipherment,keyAgreement subjectAltName = @server_alt_names [server_alt_names] DNS.1 = grpc.example.com [test_client] basicConstraints = critical,CA:FALSE subjectKeyIdentifier = hash keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment extendedKeyUsage = critical,clientAuth 复制以下内容保存至create.sh文件中，create.sh与openssl.cnf文件位于同一目录下。 #!/bin/bash # Create the server CA certs. openssl req -x509 \ -newkey rsa:4096 \ -nodes \ -days 3650 \ -keyout ca_key.pem \ -out ca_cert.pem \ -subj /C=CN/ST=CA/L=SVL/O=gRPC/CN=test-server_ca/ \ -config ./openssl.cnf \ -extensions test_ca \ -sha256 # Create the client CA certs. openssl req -x509 \ -newkey rsa:4096 \ -nodes \ -days 3650 \ -keyout client_ca_key.pem \ -out client_ca_cert.pem \ -subj /C=CN/ST=CA/L=SVL/O=gRPC/CN=test-client_ca/ \ -config ./openssl.cnf \ -extensions test_ca \ -sha256 # Generate a server cert. openssl genrsa -out server_key.pem 4096 openssl req -new \ -key server_key.pem \ -days 3650 \ -out server_csr.pem \ -subj /C=CN/ST=CA/L=SVL/O=gRPC/CN=test-server1/ \ -config ./openssl.cnf \ -reqexts test_server openssl x509 -req \ -in server_csr.pem \ -CAkey ca_key.pem \ -CA ca_cert.pem \ -days 3650 \ -set_serial 1000 \ -out server_cert.pem \ -extfile ./openssl.cnf \ -extensions test_server \ -sha256 openssl verify -verbose -CAfile ca_cert.pem server_cert.pem # Generate a client cert. openssl genrsa -out client_key.pem 4096 openssl req -new \ -key client_key.pem \ -days 3650 \ -out client_csr.pem \ -subj /C=CN/ST=CA/L=SVL/O=gRPC/CN=test-client1/ \ -config ./openssl.cnf \ -reqexts test_client openssl x509 -req \ -in client_csr.pem \ -CAkey client_ca_key.pem \ -CA client_ca_cert.pem \ -days 3650 \ -set_serial 1000 \ -out client_cert.pem \ -extfile ./openssl.cnf \ -extensions test_client \ -sha256 openssl verify -verbose -CAfile client_ca_cert.pem client_cert.pem rm *_csr.pem 执行以下命令生成证书。 chmod +x ./create.sh && ./create.sh 命令执行成功后，可得到server_key.pem私钥文件和server_cert.pem证书文件。 执行以下命令创建名为grpc-secret的TLS Secret。 kubectl create secret tls grpc-secret --key server_key.pem --cert server_cert.pem

gRPC介绍 gRPC是一种高性能、通用的RPC开源软件框架，使用Protocol Buffer作为其接口定义语言（IDL）以及底层消息交换格式。同时GRPC采用HTTP/2标准协议实现，提供了多路复用、头部压缩、流控等特性，极大地提高了客户端与服务端的通信效率。更多信息参见Introduction to gRPC。 图1 gRPC示意图 在gRPC中，客户端应用程序可以直接调用位于不同机器上的服务端应用方法，可以轻松创建分布式应用程序和服务。和许多其他RPC框架一样，使用gRPC需要定义调用服务的方法，包括参数和返回类型等，服务端需要实现被定义的方法，同时运行一个gRPC服务器来处理客户端请求。

gRPC服务示例 在proto文件中定义如下的gRPC服务，客户端可调用helloworld.Greeter服务的SayHello接口。关于gRPC服务示例的源码，请参见gRPC Hello World。 syntax = "proto3"; option go_package = "google.golang.org/grpc/examples/helloworld/helloworld"; option java_multiple_files = true; option java_package = "io.grpc.examples.helloworld"; option java_outer_classname = "HelloWorldProto"; package helloworld; // The greeting service definition. service Greeter { // Sends a greeting rpc SayHello (HelloRequest) returns (HelloReply) {} } // The request message containing the user's name. message HelloRequest { string name = 1; } // The response message containing the greetings message HelloReply { string message = 1; }

创建DNAT网关类型Service 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“服务”，在右上角单击“创建服务”。 设置集群内访问参数。 Service名称：自定义服务名称，可与工作负载名称保持一致。 访问类型：选择“DNAT网关”。 命名空间：工作负载所在命名空间。 服务亲和：详情请参见服务亲和（externalTrafficPolicy）。 集群级别：集群下所有节点的IP+访问端口均可以访问到此服务关联的负载，服务访问会因路由跳转导致一定性能损失，且无法获取到客户端源IP。 节点级别：只有通过负载所在节点的IP+访问端口才可以访问此服务关联的负载，服务访问没有因路由跳转导致的性能损失，且可以获取到客户端源IP。 选择器：添加标签，Service根据标签选择Pod，填写后单击“添加”。也可以引用已有工作负载的标签，单击“引用负载标签”，在弹出的窗口中选择负载，然后单击“确定”。 IPv6：默认不开启，开启后服务的集群内IP地址（ClusterIP）变为IPv6地址，具体请参见如何通过CCE搭建IPv4/IPv6双栈集群？。该功能仅在1.15及以上版本的集群创建时开启了IPv6功能才会显示。 DNAT网关：选择创建NAT网关和弹性公网IP中创建的DNAT网关实例和弹性公网IP。 端口配置： 协议：请根据业务的协议类型选择。 容器端口：工作负载程序实际监听的端口，需用户确定。nginx程序实际监听的端口为80。 服务端口：容器端口映射到集群虚拟IP上的端口，用虚拟IP访问工作负载时使用，端口范围为1-65535，可任意指定。 单击“确定”，创建Service。

约束与限制 关于NAT网关的使用，您需要注意以下几点： DNAT规则不支持企业项目授权。 集群内容器不支持访问externalTrafficPolicy为Local模式的DNAT Service。 同一个NAT网关下的多条规则可以复用同一个弹性公网IP，不同网关下的规则必须使用不同的弹性公网IP。 每个VPC支持的NAT网关数为1。 用户不能在VPC下手动添加默认路由。 VPC内的每个子网只能添加一条SNAT规则。 SNAT规则和DNAT规则一般面向不同的业务，如果使用相同的EIP，会面临业务相互抢占问题，请尽量避免。SNAT规则不能和全端口的DNAT规则共用EIP。 DNAT规则不支持将弹性公网IP绑定到虚拟IP。 当云主机同时配置弹性公网IP服务和NAT网关服务时，数据均通过弹性公网IP转发。 SNAT规则中添加的自定义网段，对于虚拟私有云的配置，必须是虚拟私有云子网网段的子集，不能相等。 SNAT规则中添加的自定义网段，对于云专线的配置，必须是云专线侧网段，且不能与虚拟私有云侧的网段冲突。 当执行云服务器底层资源操作（如变更规格）时，会导致已配置的NAT规则失效，需要删除后重新配置。 创建service后，如果服务亲和从集群级别切换为节点级别，连接跟踪表将不会被清理，建议用户创建service后不要修改服务亲和属性，如需修改请重新创建service。 当集群的节点子网关联了自定义路由表时，使用DNAT类型service同时需要将NAT的路由加入到自定义路由表中。

监控NGINX Ingress控制器指标 访问Prometheus，在“Graph”页面中，查看NGINX Ingress控制器指标。 图3 查看NGINX Ingress控制器监控指标 表1 NGINX Ingress控制器监控指标 指标 指标类型 说明 nginx_ingress_controller_bytes_sent 基础指标 发送到客户端的字节数 nginx_ingress_controller_connect_duration_seconds 基础指标 与上游服务器建立连接花费的时间 nginx_ingress_controller_header_duration_seconds 基础指标 从上游服务器接收第一个报头所花费的时间 nginx_ingress_controller_ingress_upstream_latency_seconds 基础指标 上游服务时延 nginx_ingress_controller_request_duration_seconds 基础指标 请求处理时间（以毫秒为单位） nginx_ingress_controller_request_size 基础指标 请求长度(包括请求行、请求头和请求体) nginx_ingress_controller_requests 基础指标 客户端请求的总数 nginx_ingress_controller_response_duration_seconds 基础指标 从上游服务器接收响应所花费的时间 nginx_ingress_controller_response_size 基础指标 响应长度(包括请求行、报头和请求体) nginx_ingress_controller_nginx_process_connections 基础指标 当前状态为{活动，读取，写入，等待}的客户端连接数 nginx_ingress_controller_nginx_process_connections_total 基础指标 状态为{已接受，已处理}的连接总数 nginx_ingress_controller_nginx_process_cpu_seconds_total 基础指标 CPU使用率(秒) nginx_ingress_controller_nginx_process_num_procs 基础指标 进程数 nginx_ingress_controller_nginx_process_oldest_start_time_seconds 基础指标 从1970年1月1日开始以秒为单位的开始时间 nginx_ingress_controller_nginx_process_read_bytes_total 基础指标 读取的字节数 nginx_ingress_controller_nginx_process_requests_total 基础指标 客户端请求总数 nginx_ingress_controller_nginx_process_resident_memory_bytes 基础指标 正在使用的内存字节数 nginx_ingress_controller_nginx_process_virtual_memory_bytes 基础指标 正在使用的内存字节数 nginx_ingress_controller_nginx_process_write_bytes_total 基础指标 写入字节数 nginx_ingress_controller_build_info 基础指标 一个带有常量“1”的度量，标记有关于构建的信息。 nginx_ingress_controller_check_success 基础指标 Ingress controller语法检查累计次数 nginx_ingress_controller_config_hash 基础指标 正在运行的Nginx配置hash值 nginx_ingress_controller_config_last_reload_successful 基础指标 最后一次尝试重新加载配置是否成功 nginx_ingress_controller_config_last_reload_successful_timestamp_seconds 基础指标 最后一次成功重新加载配置的时间戳 nginx_ingress_controller_ssl_certificate_info 基础指标 保留与证书相关的所有标签 nginx_ingress_controller_success 基础指标 Ingress controller重新加载操作的累计次数 nginx_ingress_controller_orphan_ingress 基础指标 孤立ingress的状态，1表示孤立ingress。 namespace：是用于标识ingress名称空间的字符串。 ingress：表示ingress名称。 type：表示孤立ingress的状态，取值为no-service或no-endpoint。 nginx_ingress_controller_admission_config_size 基础指标 被测试配置的大小 nginx_ingress_controller_admission_render_duration 基础指标 允许ingress渲染入口的处理持续时间(浮点秒) nginx_ingress_controller_admission_render_ingresses 基础指标 由admission controller渲染的ingress长度 nginx_ingress_controller_admission_roundtrip_duration 基础指标 admission controller在处理新事件时的完整持续时间(浮点秒) nginx_ingress_controller_admission_tested_duration 基础指标 admission controller测试的处理持续时间(浮点秒) nginx_ingress_controller_admission_tested_ingresses 基础指标 admission controller处理的ingress长度 Nginx Ingress在高负载请求下，开启全量指标采集存在内存泄露的问题（详情请参见社区issue）。经过验证，屏蔽以下指标后，能够有效抑制内存增长。为避免内存泄露导致业务受损，Nginx Ingress插件默认屏蔽以下指标。我们将持续关注社区最新动态，及时同步修复该问题。 nginx_ingress_controller_success nginx_ingress_controller_header_duration_seconds nginx_ingress_controller_ingress_upstream_latency_seconds

networking.k8s.io/v1版本Ingress说明 CCE在v1.23版本集群开始Ingress切换到networking.k8s.io/v1版本。 v1版本参数相较v1beta1参数有如下区别。 ingress类型由annotations中kubernetes.io/ingress.class变为使用spec.ingressClassName字段。 backend的写法变化。 每个路径下必须指定路径类型pathType，支持如下类型。 ImplementationSpecific: 对于这种路径类型，匹配方法取决于具体Ingress Controller的实现。在CCE中会使用ingress.beta.kubernetes.io/url-match-mode指定的匹配方式，这与v1beta1方式相同。 Exact：精确匹配 URL 路径，且区分大小写。 Prefix：基于以 / 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个匹配。 路径元素指的是由 / 分隔符分隔的路径中的标签列表。

前提条件 集群必须已安装NGINX Ingress 控制器，具体操作可参考安装插件。 Ingress为后端工作负载提供网络访问，因此集群中需提前部署可用的工作负载。若您无可用工作负载，可参考创建无状态负载（Deployment）、创建有状态负载（StatefulSet）或创建守护进程集（DaemonSet）部署工作负载。 为上述工作负载配置ClusterIP类型或NodePort类型的Service，可参考集群内访问（ClusterIP）或节点访问（NodePort）配置示例Service。

排查方案 CCE提供以下排查方式供用户参考（CCE 1.21及以上版本的集群均涉及）： 排查集群中使用的插件版本。 若用户集群中有使用2.23.34及以下版本Prometheus 插件，则需升级至2.23.34以上版本。 若用户集群中有使用1.15.0及以下版本npd插件，则需升级至最新版本。 通过kubectl连接集群，并通过kubectl get --raw "/metrics" | grep stale查询，可以看到一个名为serviceaccount_stale_tokens_total的指标。 如果该值大于0，则表示当前集群可能存在某些负载正在使用过低的client-go版本情况，此时请您排查自己部署的应用中是否有该情况出现。如果存在，则尽快将client-go版本升级至社区指定的版本之上（至少不低于CCE集群的两个大版本，如部署在1.23集群上的应用需要使用1.19版本以上的Kubernetes依赖库）。

事件 事件搜索 事件页面的主要功能是展示按照一定条件搜索出的指定资源的事件信息，包括Normal/Warning事件趋势和详情。这样，用户可以更加方便地查看与该资源相关的事件信息。 您可以按照如下几种方式进行事件搜索。 在输入框里输入要搜索的事件名称，选择命名空间或者事件类型，单击“搜索”按钮进行搜索。 单击“高级搜索”，按照工作负载、节点、Pod名称、事件内容、资源类型或者资源名称进行搜索。 也可以在左上角选择事件发生的时间范围，包括近1小时、近1天、近1周和自定义。 图4 搜索事件 事件列表 您可以在列表中查看满足搜索条件的事件详情，包括最近发生时间、事件名称、资源类型、资源名称、事件内容、事件类型和发生次数。单击操作列的“历史事件”，在弹出的对话框中将展示当前资源类型和资源名称下的所有事件。 图5 事件列表

概览 “概览”页面默认展示集群中所有命名空间的事件统计信息，您也可以在右上角的下拉框中切换命名空间，以查看指定命名空间下的事件数据。 根据图1的事件统计数据，您可以清晰地了解到Normal和Warning事件的数量分布情况，呈现为一个圆环图；Warning事件资源维度TOP5指的是排名前五的Warning事件数量所对应的资源信息；Warning事件环比指近24小时Warning事件数与前24小时之间的比较。 图1 事件统计 通过图2中的柱状图，您可以观察24小时内Normal事件和Warning事件的数量变化趋势。 图2 Warning/Normal事件趋势 图3展示了24小时内事件数量排名前十的事件名称。 图3 24小时事件数量TOP 10

开通Region视角的成本洞察 登录CCE控制台，单击左侧导航栏中的“云原生成本治理”。 图1 云原生成本治理 单击“立即开通”选择要开通的集群后，单击“确认开通”。 开通过程中系统将自动执行如下步骤：安装云原生监控插件、成本标签激活、创建默认租户OBS桶、订阅账单数据。等待3-5分钟，即可进入洞察界面。 安装云原生监控插件：为成本洞察功能提供基础监控数据。 成本标签激活：成本标签激活后费用中心导出的账单会增加集群的标签，成本洞察后台将按照集群进行分类。该步骤完成后，可在云原生成本治理的成本标签界面，看到CCE-Cluster-ID、CCE-Dynamic-Provisioning-Node标签被激活。 创建默认租户OBS桶：创建名称为cce-cost-{region}-{domain_id}的默认OBS桶，该OBS桶用来存储从费用中心导出的账单数据。 订阅账单数据：订阅账单后，费用中心会定期将账单推送到OBS桶中，供成本洞察使用。 图2 开通集群 （可选）单击“创建部门”，进行部门的配置。部门的配置包含如下步骤： 图3 创建部门 自定义部门：为贴合实际的业务场景，一般会按照实际业务部门设立该成本单元，并关联业务部门使用的集群或者命名空间。 部门名称：建议使用实际的业务部门名称，支持中文； 部门范围：该部门使用的集群或者命名空间。如下按照命名空间粒度，配置部门department1、department2。 图4 自定义部门 分摊公共成本：将集群中的公共成本分摊到部门。默认集群中的管理成本和未被分配成本，在其关联的部门中进行平均分摊。支持修改分摊比例。 图5 分摊公共成本 基于部门进行成本管理：部门配置完成后，单击“提交配置”，便可以在部门管理界面看到配置的结果。部门配置结果如下： 图6 部门配置

前提条件 开通云原生成本治理前，用户需要使用具有admin用户组的账户完成对CCE及其依赖服务的委托授权。 授权方式：用户进入云原生成本治理页面，界面会自动弹出“确认授权”页面，用户单击“确认授权”按钮后系统自动完成授权。所授予的权限类型请参考表1。 表1 资源权限 授权类型 权限名称 描述 CCE IAM ReadOnlyAccess 云原生成本治理获得该权限后，支持子用户进行访问云原生成本治理，因此需要获得该权限。 CCE Tenant Guest 云原生成本治理支持对集群关联的 OBS、DNS 等全局资源配置进行检查，提前发现配置问题，因此需要获得该权限。 CCE CCE Administrator 云原生成本治理在运行过程中需要访问 CCE 获取集群、节点、工作负载等信息，以此来检测对应资源的健康状态，因此需要获得该权限。 CCE AOM Administrator 云原生成本治理在运行过程中需要访问 AOM 获取监控指标信息，因此需要获得该权限。 CCE OBS Administrator 云原生成本治理的成本可视化需要结合实际账单，账单信息需要放入用户OBS桶中，需要访问用户OBS桶，因此需要获得该权限。 CCE CBC Finance 云原生成本治理需要帮用户订阅用户的CBC账单信息。订阅后，CBC会定期将用户账单信息放入用户OBS桶中，供云原生成本治理使用，因此需要获得该权限。 AOM DMS UserAccess AOM 支持用户通过 DMS 获取数据订阅的功能，因此需要获得该权限。 AOM ECS CommonOperations AOM 支持通过在 ECS 上安装 UniAgent 和 ICAgent 获取系统指标、日志数据，因此需要获得该权限。 AOM CES ReadOnlyAccess AOM 支持从 CES 同步监控指标数据，因此需要获得该权限。 AOM CCE FullAccess AOM 支持从 CCE 同步容器监控指标数据，因此需要获得访问权限。 AOM RMS ReadOnlyAccess AOM 的 CMDB 支持管理云服务实例数据，因此需要获得该权限。 AOM ECS ReadOnlyAccess AOM支持通过在 ECS 上安装 UniAgent 和 ICAgent 获取系统指标、日志数据，因此需要获得该权限。 AOM LTS FullAccess AOM 支持访问 LTS 数据，因此需要获得该权限。 AOM CCI FullAccess AOM 支持从 CCI 同步容器监控指标数据，因此需要获得该权限。

概览 单击工作负载名称，您可以方便地查看资源概况，包括负载状态、Pod数量（异常/总数）以及异常事件。此外，还可以浏览近一小时的监控概览，其中包括CPU使用率、内存使用率和网络流入/流出速率这些常见的监控指标。 图2 资源概况和监控概览 同时，概览页面还提供了Pod使用趋势功能，您可以从中了解工作负载中各Pod的CPU使用率、CPU使用量、内存使用率和内存使用量（在图表右上角切换对应指标），并且支持查看降序Top5和升序Top5数据（在图表左上角进行切换）。 图3 Pod使用趋势 如需了解更多指标，请前往监控页面查看。

监控 在此处，您可以方便地查看工作负载在近1小时、近8小时、近24小时以及自定义时间段内各维度资源的使用情况。如需查看更多监控信息，请单击“查看全部仪表盘”，跳转至“仪表盘”页面，相应指导请参见使用仪表盘。 图5 工作负载监控 CPU相关指标 CPU：负载的所有 Pod 的容器在不同的时间段使用的 CPU 总量占负载的所有 Pod 的容器的 CPU Limit 总量的比例。 CPU 受限（CPU Throttled）：负载的所有 Pod 的容器在不同的时间段的 CPU 受限时间所占的平均比例。 内存相关指标 内存使用率：负载的所有 Pod 的容器在不同的时间段使用的内存总量占负载的所有 Pod 的容器的内存 Limit 总量比例。 网络相关指标 网络总流出速率：负载的所有 Pod 的容器在不同的时间段的每秒钟发送的总字节数。 网络总流入速率：负载的所有 Pod 的容器在不同的时间段的每秒钟接收的总字节数。 网络发送丢包率：负载的所有 Pod 的容器在不同的时间段的发送丢失的数据包总量占发送的数据包总量的比例。 网络接收丢包率：负载的所有 Pod 的容器在不同的时间段的接收丢失的数据包总量占接收的数据包总量的比例。 Pod相关指标 Pod CPU使用率：负载的每个 Pod 在不同的时间段的CPU使用量除以它们的 CPU Limit 量。 Pod内存使用率：负载的每个 Pod 在不同的时间段的内存使用量除以它们的内存 Limit 量。 Pod状态数量趋势：负载在不同的时间段分别处于不可用、未就绪、运行中、已完成或其他的状态 Pod 数量之和。 Pod数量变化趋势：负载的 Pod（副本）在不同的时间段的数量。

Pod列表 Pod列表中包含了Pod名称、状态、命名空间、Pod IP、所在节点、重启次数、CPU申请/限制、内存申请/限制，以及CPU和内存使用率等详细信息。 图4 Pod列表 您可以通过在列表上方按照Pod名称、状态、命名空间、Pod IP和所在节点进行筛选，快速找到需要的Pod。您也可以单击“导出”按钮来导出全部Pod数据，或者选择部分Pod进行导出，此时仅导出所选中的数据。导出的文件为“.xlsx”格式，文件命名中包含时间戳。 单击实例名称可以查看实例的详细监控数据。更多相关内容，请参见Pod。

工作负载列表 工作负载列表中包含工作负载名称、状态、Pod个数（正常/全部）、命名空间、镜像名称、CPU使用率，以及内存使用率等信息。 图1 工作负载列表 您可以利用页面右上角的工作负载类型，以及列表上方的工作负载名称、状态和命名空间进行筛选，快速定位所需的工作负载。 您也可以单击“导出”按钮来导出全部工作负载数据，或者选择部分工作负载进行导出，此时仅导出所选中的数据。导出的文件为“.xlsx”格式，文件命名中包含时间戳。

验证数据持久化及共享性 查看部署的应用及文件。 执行以下命令，查看已创建的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共享一个存储卷。

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

切流至ELB Ingress 流量切换前，假设您已将业务域名通过A记录解析的方式指向了自建Nginx Ingress的公网地址。您可以使用DNS的流量权重分配，逐步将访问原Nginx Ingress的流量切换至新的ELB Ingress。 图1 使用DNS切流 您可以通过以下步骤完成流量的切换。 进入公网域名列表页面。 在“公网域名”页面的域名列表中，单击域名example.com的名称。 进入“解析记录”页面。此时已存在一个A记录，对应Nginx Ingress的公网IP。修改Nginx Ingress的A记录的权重为9。 单击“添加记录集”，添加A记录，地址为待迁移的ELB公网IP，并将权重设置为1。 图2 修改DNS记录集 在观察业务没有影响的情况下，逐步调整ELB实例解析记录的权重值至100%。

场景示例 下图场景为例。某企业在华为云使用CCE集群，并通过自建Nginx Ingress Controller配置Ingress转发规则，配置域名和路径的转发策略，且对外通过DNS域名提供服务。客户端访问域名example.com时，Nginx Ingress接收到请求会根据对应的转发策略将流量转发至对应Service的Pod上。 由于业务发展需要，该企业需要将自建Nginx Ingress迁移到ELB Ingress上。为了保持业务稳定，希望不改变对外提供服务的DNS域名及后端服务器的IP地址。您可以通过在 CCE集群上配置 ELB Ingress 规则，使ELB提供的转发策略与之前一致，然后利用DNS域名解析的权重设置完成流量的迁移。 建议在业务低谷期进行流量的切换。 使用ELB会产生计费信息，具体计费详情请参见计费概述。

集群的网络 集群的网络可以分成三个部分： 节点网络：为集群内节点分配IP地址。 容器网络：为集群内容器分配IP地址，负责容器的通信，当前支持多种容器网络模型，不同模型有不同的工作机制。 服务网络：服务（Service）是用来解决访问容器的Kubernetes对象，每个Service都有一个固定的IP地址。 在创建集群时，您需要为各个网络选择合适的网段，确保各网段之间不存在冲突，每个网段下有足够的IP地址可用。集群创建后不支持修改容器网络模型，您需要在创建前做好规划和选择。 强烈建议您在创建集群前详细了解集群的网络以及容器网络模型，具体请参见容器网络模型。

HPA工作原理 HPA（Horizontal Pod Autoscaler）是用来控制Pod水平伸缩的控制器，HPA周期性检查Pod的度量数据，计算满足HPA资源所配置的目标数值所需的副本数量，进而调整目标资源（如Deployment）的replicas字段。 想要做到自动弹性伸缩，先决条件就是能感知到各种运行数据，例如集群节点、Pod、容器的CPU、内存使用率等等。而这些数据的监控能力Kubernetes也没有自己实现，而是通过其他项目来扩展Kubernetes的能力，CCE提供Metrics Server插件来实现该能力： Metrics Server是Kubernetes集群范围资源使用数据的聚合器。Metrics Server从kubelet公开的Summary API中采集度量数据，能够收集包括了Pod、Node、容器、Service等主要Kubernetes核心资源的度量数据，且对外提供一套标准的API。 使用HPA（Horizontal Pod Autoscaler）配合Metrics Server可以实现基于CPU和内存的自动弹性伸缩。 HPA主要流程如图1所示。 图1 HPA流程图

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

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

监控 您可以通过CCE控制台查看工作负载和容器组的CPU和内存占用情况，以确定需要的资源规格。本文以无状态工作负载为例说明如何使用监控功能。 登录CCE控制台，进入一个已有的集群，在左侧导航栏中选择“工作负载”。 选择“无状态负载”页签，单击已创建工作负载后的“监控”。在监控页面，可查看工作负载的CPU利用率和物理内存使用率。 图1 查看无状态工作负载监控 单击工作负载名称，可在“实例列表”中单击某个实例的“监控”按钮，查看相应实例的CPU使用率、内存使用率。