华为云用户手册

查看告警列表 您可以在“告警列表”页面查看最近发送的历史记录。 登录CCE控制台。 在集群列表页面，单击目标集群名称进入详情页。 在左侧导航栏选择“告警中心”，选择“告警列表”页签。 列表中默认展示全部待解决告警，支持按照告警关键字、告警等级，以及告警发生的时间范围筛选。同时支持查看指定筛选条件的告警在不同时间段的分布情况。 如果确认某条告警已排除，可以单击操作列的“清除”，清除后可在历史告警中查询。 图1 告警列表

操作步骤 登录CCE控制台，在左侧导航栏中选择“集群管理”。 单击集群名称，查看总览页面。 在“网络信息”中单击“节点默认安全组”后的按钮。 图1 节点默认安全组 选择一个已有的安全组，并确认安全组规则满足集群要求后，单击“确定”。 请确认选择的安全组设置了正确的端口规则，否则将无法成功创建节点。安全组需要满足的端口规则根据集群类别存在差异，详情请参见集群安全组规则配置。 新安全组只对新创建或纳管的节点生效，存量节点需要手动修改节点安全组规则，即使对存量节点进行重置，也仍会使用原安全组。如需批量修改存量节点的安全组设置，请参考如何批量修改集群node节点安全组？。 图2 编辑节点默认安全组

Pod标签 在控制台创建工作负载时，会默认为Pod添加如下标签，其中app的值为工作负载名称。 YAML示例如下： ... spec: selector: matchLabels: app: nginx version: v1 template: metadata: labels: app: nginx version: v1 spec: ...

Pod注解 CCE提供一些使用Pod的高级功能，这些功能使用时可以通过给YAML添加注解Annotation实现。具体的Annotation如下表所示。 表1 Pod Annotation 注解 说明 默认值 kubernetes.io/ingress-bandwidth Pod的入口带宽 具体使用请参见为Pod配置QoS。 - kubernetes.io/egress-bandwidth Pod的出口带宽 具体使用请参见为Pod配置QoS。 - node.cce.io/node-az-list Pod亲和的可用区列表。 具体使用请参见设置可用区亲和性。 -

Binpack功能介绍 Binpack调度算法的目标是尽量把已有的节点填满（即尽量不往空白节点分配）。具体实现上，Binpack调度算法为满足调度条件的节点打分，节点的资源利用率越高得分越高。Binpack算法能够尽可能填满节点，将应用负载靠拢在部分节点，这非常有利于集群节点的自动扩缩容功能。 Binpack为调度器的多个调度插件之一，与其他插件共同为节点打分，用户可以自定义该插件整体权重和各资源维度打分权重，用以提高或降低Binpack在整体调度中的影响力。调度器在计算Binpack策略得分时，会考虑Pod请求的各种资源，如：CPU、Memory和GPU等扩展资源，并根据各种资源所配置的权重做平均。

Binpack算法原理 Binpack在对一个节点打分时，会根据Binpack插件自身权重和各资源设置的权重值综合打分。首先，对Pod请求资源中的每类资源依次打分，以CPU为例，CPU资源在待调度节点的得分信息如下： CPU.weight * (request + used) / allocatable 即CPU权重值越高，得分越高，节点资源使用量越满，得分越高。Memory、GPU等资源原理类似。其中： CPU.weight为用户设置的CPU权重 request为当前pod请求的CPU资源量 used为当前节点已经分配使用的CPU量 allocatable为当前节点CPU可用总量 通过Binpack策略的节点总得分如下： binpack.weight * (CPU.score + Memory.score + GPU.score) / (CPU.weight+ Memory.weight+ GPU.weight) * 100 即binpack插件的权重值越大，得分越高，某类资源的权重越大，该资源在打分时的占比越大。其中： binpack.weight为用户设置的装箱调度策略权重 CPU.score为CPU资源得分，CPU.weight为CPU权重 Memory.score为Memory资源得分，Memory.weight为Memory权重 GPU.score为GPU资源得分，GPU.weight为GPU权重 图1 Binpack策略示例

通过控制台创建 登录CCE控制台，单击集群名称进入集群。 在左侧导航栏中选择“服务”，在右上角单击“创建服务”。 设置Service参数。本示例中仅列举必选参数，其余参数可根据需求参考创建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端口。 监听器前端协议：本例中Service使用HTTP/2需选择开启HTTPS。当选择独享型负载均衡器类型时，需包含“应用型（HTTP/HTTPS）”方可支持配置HTTP/HTTPS。 监听器配置： SSL解析方式： 单向认证：仅进行服务器端认证。如需认证客户端身份，请选择双向认证。 双向认证：双向认证需要负载均衡实例与访问用户互相提供身份认证，从而允许通过认证的用户访问负载均衡实例，后端服务器无需额外配置双向认证。 CA证书：SSL解析方式选择“双向认证”时需要添加CA证书，用于认证客户端身份。CA证书又称客户端CA公钥证书，用于验证客户端证书的签发者；在开启HTTPS双向认证功能时，只有当客户端能够出具指定CA签发的证书时，HTTPS连接才能成功。 服务器证书：使用HTTPS协议时需要选择一个服务器证书。如果当前无可选证书，需前往弹性负载均衡控制台进行创建，详情请参见创建证书。 SNI：选择添加SNI证书，证书中必须包含 域名 。如果当前无可选证书，需前往弹性负载均衡控制台进行创建，详情请参见创建证书。 高级配置：单击“添加自定义容器网络配置”，选择“开启HTTP/2”，并将状态设置为“开启”。 图1 开启HTTP/2 单击“确定”，创建Service。

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

升级方式 表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 E CS 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共享一个存储卷。