华为云用户手册

应用场景3：多种高级调度策略 当用户向Kubernetes申请容器所需的计算资源（如CPU、Memory、GPU等）时，调度器负责挑选出满足各项规格要求的节点来部署这些容器。通常，满足各项要求的节点并非唯一，且水位（节点已有负载）各不相同，不同的分配方式最终得到的分配率存在差异，因此，调度器的一项核心任务就是以最终资源利用率最优的目标从众多候选机器中挑出最合适的节点。 下图为Volcano scheduler调度流程，首先将API server中的Pod、PodGroup信息加载到scheduler cache中。Scheduler周期被称为session，每个scheduler周期会经历OpenSession，调用Action，CloseSession三个阶段。其中OpenSession阶段加载用户配置的scheduler plugin中实现的调度策略；调用Action阶段逐一调用配置的action以及在OpenSession阶段加载的调度策略；CloseSession为清理阶段。 Volcano scheduler通过插件方式提供了多种调度Action（例如enqueue，allocate，preempt，backfill）以及调度策略（例如gang，priority，drf，proportion，binpack等），用户可以根据实际业务需求进行配置。通过实现Scheduler提供的接口也可以方便灵活地进行定制化开发。

应用场景4：高精度资源调度 Volcano 在支持AI，大数据等作业的时候提供了高精度的资源调度策略，例如在深度学习场景下计算效率非常重要。以TensorFlow计算为例，配置“ps”和“worker”之间的亲和性，以及“ps”与“ps”之间的反亲和性，可使“ps”和“worker”尽量调度到同一台节点上，从而提升“ps”和“worker”之间进行网络和数据交互的效率，进而提升计算效率。然而Kubernetes默认调度器在调度Pod过程中，仅会检查Pod与现有集群下所有已经处于运行状态Pod的亲和性和反亲和性配置是否冲突或吻合，并不会考虑接下来可能会调度的Pod造成的影响。 Volcano提供的Task-topology算法是一种根据Job内task之间亲和性和反亲和性配置计算task优先级和Node优先级的算法。通过在Job内配置task之间的亲和性和反亲和性策略，并使用task-topology算法，可优先将具有亲和性配置的task调度到同一个节点上，将具有反亲和性配置的Pod调度到不同的节点上。同样是处理亲和性和反亲和性配置对Pod调度的影响，task-topology算法与Kubernetes默认调度器处理的不同点在于，task-topology将待调度的Pods作为一个整体进行亲和性和反亲和性考虑，在批量调度Pod时，考虑未调度Pod之间的亲和性和反亲和性影响，并通过优先级施加到Pod的调度进程中。

应用场景 多云部署、容灾备份 为保证业务高可用，需要将业务同时部署在多个云的容器服务上，在某个云出现事故时，通过统一流量分发的机制，自动地将业务流量切换到其他云上。 流量分发、弹性伸缩 大型企业客户需要将业务同时部署在不同地域的云机房中，并能根据业务的波峰波谷进行自动弹性扩容和缩容，以节约成本。 业务上云、数据本地托管 对于金融、医疗等行业用户，由于安全合规要求，敏感数据要求存储在本地IDC中，而一般业务由于高并发、快响应等方面的特点需要部署在云上，并需要进行统一管理。 开发与部署分离 出于IP安全的考虑，用户希望将生产环境部署在公有云上，而将开发环境部署在本地的IDC。

优势 云上容灾 通过云容器引擎，可以将业务系统同时部署在多个云的容器服务上，统一流量分发，单云故障后能够自动将业务流量切换到其他云上，并能快速自动解决现网事故。 统一架构，高弹性 云上云下同架构平台，可灵活根据流量峰值实现资源在云上云下的弹性伸缩、平滑迁移和扩容。 计算与数据分离，能力共享 通过云容器引擎，用户可以实现敏感业务数据与一般业务数据的分离，可以实现开发环境和生产环境分离，可以实现特殊计算能力与一般业务的分离，并能够实现弹性扩展和集群的统一管理，达到云上云下资源和能力的共享。 降低成本 业务高峰时，利用公有云资源池快速扩容，用户不再需要根据流量峰值始终保持和维护大量资源，节约成本。

应用场景 伴随着互联网技术的不断发展，各大企业的系统越来越复杂，传统的系统架构越来越不能满足业务的需求，取而代之的是微服务架构。微服务是将复杂的应用切分为若干服务，每个服务均可以独立开发、部署和伸缩；微服务和容器组合使用，可进一步简化微服务的交付，提升应用的可靠性和可伸缩性。 随着微服务的大量应用，其构成的分布式应用架构在运维、调试和安全管理等维度变得更加复杂，在管理微服务时，往往需要在业务代码中添加微服务治理相关的代码，导致开发人员不能专注于业务开发，还需要考虑微服务治理的解决方案，并且将解决方案融合到其业务系统中。

计费项 云容器引擎的计费项由集群费用和其他云服务资源费用组成。了解每种计费项的计费因子、计费公式等信息，请参考计费项。 集群：控制节点资源费用，按照每个集群的类型（虚拟机或裸金属、控制节点数）、集群规模（最大支持的节点数）的差异收取不同的费用。 控制节点资源的价格目录请参见：云容器引擎价格目录。 其他云服务资源：集群所使用的IaaS基础设施费用，包括集群创建使用过程中自动创建或手动加入的相关资源，如云服务器、云硬盘、弹性IP/带宽、负载均衡等，价格参照相应产品价格表。 更多价格目录请参见：产品价格详情。 如需了解实际场景下的计费样例以及各计费项在不同计费模式下的费用计算过程，请参见计费样例。

计费模式 云容器引擎提供包年/包月、按需计费两种计费模式，以满足不同场景下的用户需求。关于计费模式的详细介绍请参见计费模式概述。 包年/包月是一种预付费模式，即先付费再使用，按照订单的购买周期进行结算，因此在购买之前，您必须确保账户余额充足。 按需计费是一种后付费模式，即先使用再付费，按照实际使用时长计费。 在购买集群或集群内资源后，如果发现当前计费模式无法满足业务需求，您还可以变更计费模式。详细介绍请参见变更计费模式概述。

什么是区域、可用区？ 区域和可用区用来描述数据中心的位置，您可以在特定的区域、可用区创建资源。 区域（Region）：从地理位置和网络时延维度划分，同一个Region内共享弹性计算、块存储、对象存储、VPC网络、弹性公网IP、镜像等公共服务。Region分为通用Region和专属Region，通用Region指面向公共租户提供通用云服务的Region；专属Region指只承载同一类业务或只面向特定租户提供业务服务的专用Region。 可用区（AZ，Availability Zone）：一个AZ是一个或多个物理数据中心的集合，有独立的风火水电，AZ内逻辑上再将计算、网络、存储等资源划分成多个集群。一个Region中的多个AZ间通过高速光纤相连，以满足用户跨AZ构建高可用性系统的需求。 图1阐明了区域和可用区之间的关系： 图1 区域和可用区 目前，全球多个地域均已开放云服务，您可以根据需求选择适合自己的区域和可用区。更多信息请参见华为云全球站点。

如何选择区域？ 选择区域时，您需要考虑以下因素： 地理位置 一般情况下，建议就近选择靠近您或者您的目标用户的区域，这样可以减少网络时延，提高访问速度。 不过，在基础设施、BGP网络品质、资源的操作与配置等方面，中国大陆各个区域间区别不大，如果您或者您的目标用户在中国大陆，可以不用考虑不同区域造成的网络时延问题。 在除中国大陆以外的亚太地区有业务的用户，可以选择“中国-香港”、“亚太-曼谷”或“亚太-新加坡”区域。 在非洲地区有业务的用户，可以选择“南非-约翰内斯堡”区域。 在欧洲地区有业务的用户，可以选择“欧洲-巴黎”区域。 资源的价格 不同区域的资源价格可能有差异，请参见华为云服务价格详情。

云容器引擎与其他服务的关系 表1 云容器引擎与其他服务的关系 服务名称 云容器引擎与其他服务的关系 主要交互功能 弹性云服务器 E CS 在云容器引擎中具有多个云硬盘的一台弹性云服务器就是一个节点，您可以在创建节点时指定弹性云服务器的规格。 购买节点 纳管已有节点到集群 虚拟私有云 VPC 在云容器引擎中创建的集群需要运行在虚拟私有云中，您在集群中创建节点池时，节点将会从VPC网段内分配私网IP地址，为您的集群提供相对隔离的网络环境。 购买CCE集群 弹性负载均衡 ELB 云容器引擎支持将创建的应用对接到弹性负载均衡，弹性负载均衡可以将外部访问流量分发到不同的后端容器应用中。 您可以通过弹性负载均衡，从外部网络访问容器负载。 创建无状态负载(Deployment) 创建有状态负载(StatefulSet) 负载均衡(LoadBalancer) NAT网关 NAT网关能够为VPC内的容器实例提供 网络地址转换 （Network Address Translation）服务，SNAT功能通过绑定弹性公网IP，实现私有IP向公有IP的转换，可实现VPC内的容器实例共享弹性公网IP访问Internet。 您可以通过NAT网关设置SNAT规则，使得容器能够访问Internet。 创建无状态负载(Deployment) 创建有状态负载(StatefulSet) DNAT网关(DNAT) 容器镜像服务 SWR 容器 镜像服务 提供的镜像仓库是用于存储、管理docker容器镜像的场所，可以让使用人员轻松存储、管理、部署docker容器镜像。 您可以使用容器镜像服务中的镜像创建负载。 创建无状态负载(Deployment) 创建有状态负载(StatefulSet) 云容器实例 CCI 云容器实例的Serverless Container是从使用角度，无需创建、管理Kubernetes集群，也就是从使用的角度看不见服务器（Serverless），直接通过控制台、kubectl、Kubernetes API创建和使用容器负载，且只需为容器所使用的资源付费。 当CCE集群资源不足时，支持将Pod弹性部署到CCI集群。 virtual kubelet插件 CCE容器实例弹性伸缩到CCI服务 云硬盘 EVS 可以将云硬盘挂载到云服务器，并可以随时扩容云硬盘容量。 在云容器引擎中一个节点就是具有多个云硬盘的一台弹性云服务器，您可以在创建节点时指定云硬盘的大小。 使用云硬盘存储卷 对象存储服务 OBS 对象存储服务是一个基于对象的海量存储服务，为客户提供海量、安全、高可靠、低成本的数据存储能力，包括：创建、修改、删除桶，上传、下载、删除对象等。 云容器引擎支持创建OBS对象存储卷并挂载到容器的某一路径下。 使用对象存储卷 弹性文件服务 SFS 弹性文件服务提供托管的共享文件存储，符合标准文件协议（NFS），能够弹性伸缩至PB规模，具备可扩展的性能，为海量数据、高带宽型应用提供有力支持。 您可以使用弹性文件服务作为容器的持久化存储，在创建任务负载的时候挂载到容器上。 使用文件存储卷 应用运维管理 AOM 云容器引擎对接了AOM，AOM会采集容器日志存储中的“.log”等格式日志文件，转储到AOM中，方便您查看和检索；并且云容器引擎基于AOM进行资源监控，为您提供弹性伸缩能力。 容器日志 云审计 服务 CTS 云审计服务提供云服务资源的操作记录，记录内容包括您从公有云管理控制台或者开放API发起的云服务资源操作请求以及每次请求的结果，供您查询、审计和回溯使用。 云审计服务支持的CCE操作列表

应用场景 CCE集群支持管理X86和ARM资源，能够轻松创建Kubernetes集群、部署容器化应用，并方便地进行管理和维护。 容器化Web应用：使用CCE集群，能帮助用户快速部署Web业务应用，对接华为云中间件（如 GaussDB 、Redis），并支持配置高可用容灾、自动弹性伸缩、发布公网、灰度升级等。 中间件部署平台：CCE集群可以作为中间件的部署平台，使用StatefulSet、PVC等资源配置，能够实现应用的有状态化，同时配套弹性负载均衡实例，可实现中间件服务的对外发布。 执行普通任务、定时任务：使用容器化方式运行Job、CronJob类型应用，帮助业务降低对主机系统配置的依赖，全局的资源调度既保证任务运行时资源量，也提高集群下整体资源利用率。 图1 CCE集群

云容器引擎对比自建Kubernetes集群 表1 云容器引擎和自建Kubernetes集群对比 对比项 自建Kubernetes集群 云容器引擎 易用性 自建Kubernetes集群管理基础设施通常涉及安装、操作、扩展自己的集群管理软件、配置管理系统和监控解决方案，管理复杂。每次升级集群的过程都是巨大的调整，带来繁重的运维负担。 简化集群管理，简单易用 借助云容器引擎，您可以一键创建和升级Kubernetes容器集群，无需自行搭建Docker和Kubernetes集群。您可以通过云容器引擎自动化部署和一站式运维容器应用，使得应用的整个生命周期都在容器服务内高效完成。 您可以通过云容器引擎轻松使用深度集成的应用服务网格和Helm标准模板，真正实现开箱即用。 您只需启动容器集群，并指定想要运行的任务，云容器引擎帮您完成所有的集群管理工作，让您可以集中精力开发容器化的应用程序。 可扩展性 自建Kubernetes集群需要根据业务流量情况和健康情况人工确定容器服务的部署，可扩展性差。 灵活集群托管，轻松实现扩缩容 云容器引擎可以根据资源使用情况轻松实现集群节点和工作负载的自动扩容和缩容，并可以自由组合多种弹性策略，以应对业务高峰期的突发流量浪涌。 可靠性 自建Kubernetes集群操作系统可能存在安全漏洞和配置错误，这可能导致未经授权的访问、数据泄露等安全问题。 企业级的安全可靠 云容器引擎提供容器优化的各类型操作系统镜像，在原生Kubernetes集群和运行时版本基础上提供额外的稳定测试和安全加固，减少管理成本和风险，并提高应用程序的可靠性和安全性。 高效性 自建Kubernetes集群需要自行搭建镜像仓库或使用第三方镜像仓库，镜像拉取方式多采用串行传输，效率低。 镜像快速部署 云容器引擎配合容器镜像服务，镜像拉取方式采用并行传输，确保高并发场景下能获得更快的下载速度，大幅提升容器交付效率。 成本 自建Kubernetes集群需要投入资金构建、安装、运维、扩展自己的集群管理基础设施，成本开销大。 云容器引擎成本低 您只需支付用于存储和运行应用程序的基础设施资源（例如云服务器、云硬盘、弹性IP/带宽、负载均衡等）费用和容器集群控制节点费用。

容器化的优势 Docker使用Google公司推出的Go语言进行开发实现，基于Linux内核的cgroup，namespace，以及AUFS类的Union FS等技术，对进程进行封装隔离，属于操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。 Docker在容器的基础上，进行了进一步的封装，从文件系统、网络互联到进程隔离等，极大的简化了容器的创建和维护。 传统虚拟机技术通过Hypervisor将宿主机的硬件资源（如内存、CPU、网络、磁盘等）进行了虚拟化分配，然后通过这些虚拟化的硬件资源组成了虚拟机，并在上面运行一个完整的操作系统，每个虚拟机需要运行自己的系统进程。而容器内的应用进程直接运行于宿主机操作系统内核，没有硬件资源虚拟化分配的过程，避免了额外的系统进程开销，因此使得Docker技术比虚拟机技术更为轻便、快捷。 图2 传统虚拟化和容器化方式的对比 作为一种新兴的虚拟化方式，Docker跟虚拟机相比具有众多的优势： 更高效的利用系统资源 由于容器不需要进行硬件虚拟化分配以及运行完整操作系统等额外开销，Docker对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。因此，相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用。 更快速的启动时间 传统的虚拟机技术启动应用服务往往需要数分钟，而Docker容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。 一致的运行环境 开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境、生产环境不一致，导致有些bug并未在开发过程中被发现。而Docker的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性。 持续交付和部署 对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。 使用Docker可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过Dockerfile来进行镜像构建，并结合持续集成（Continuous Integration）系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合持续部署（Continuous Delivery/Deployment） 系统进行自动部署。 而且使用Dockerfile使镜像构建透明化，不仅开发团队可以理解应用运行环境，也方便运维团队理解应用运行所需条件，帮助更好的生产环境中部署该镜像。 更轻松的迁移 由于Docker确保了执行环境的一致性，使得应用的迁移更加容易。Docker可以在很多平台上运行，无论是物理机、虚拟机、公有云、私有云，甚至是笔记本，其运行结果是一致的。因此用户可以很轻易地将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。 更轻松的维护和扩展 Docker使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。此外，Docker团队同各个开源项目团队一起维护了一大批高质量的官方镜像，既可以直接在生产环境使用，又可以作为基础进一步定制，大大的降低了应用服务的镜像制作成本。 表2 容器对比传统虚拟机总结 特性 容器 虚拟机 启动 秒级 分钟级 硬盘使用 一般为MB 一般为GB 性能 接近原生 弱 系统支持量 单机支持上千个容器 一般几十个

云容器引擎的优势 云容器引擎是基于业界主流的Docker和Kubernetes开源技术构建的容器服务，提供众多契合企业大规模容器集群场景的功能，在系统可靠性、高性能、开源社区兼容性等多个方面具有独特的优势，满足企业在构建容器云方面的各种需求。 简单易用 通过WEB界面一键创建CCE Standard、 CCE Turbo 、CCE Autopilot三种集群，支持管理虚拟机节点或裸金属节点，支持虚拟机与物理机混用场景。 一站式自动化部署和运维容器应用，整个生命周期都在容器服务内一站式完成。 通过Web界面轻松实现集群节点和工作负载的扩容和缩容，自由组合策略以应对多变的突发浪涌。 通过Web界面一键完成Kubernetes集群的升级。 深度集成应用服务网格、Helm标准模板和插件中心，真正实现开箱即用。 高性能 基于在计算、网络、存储、异构等方面多年的行业技术积累，提供高性能的容器集群服务，支撑业务的高并发、大规模场景。 采用高性能裸金属NUMA架构和高速IB网卡，AI计算性能提升3-5倍以上。 安全可靠 高可靠：集群管理面支持3 Master HA高可用，3个Master节点可以处于不同可用区，保障您的业务高可用。集群内节点和工作负载支持跨可用区（AZ）部署，帮助您轻松构建多活业务架构，保证业务系统在主机故障、机房中断、自然灾害等情况下可持续运行，获得生产环境的高稳定性，实现业务系统零中断。 图1 集群高可用 高安全：私有集群，完全由用户掌控，并深度整合 IAM 和Kubernetes RBAC能力，支持用户在界面为子用户设置不同的RBAC权限。 提供安全运行时，为每个容器（准确地说是Pod）都运行在一个单独的微型虚拟机中，拥有独立的操作系统内核，以及虚拟化层的安全隔离。 开放兼容 云容器引擎在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。 云容器引擎基于业界主流的Kubernetes实现，完全兼容Kubernetes/Docker社区原生版本，与社区最新版本保持紧密同步，完全兼容Kubernetes API和Kubectl。

命名空间权限（kubernetes RBAC授权） 命名空间权限是基于Kubernetes RBAC能力的授权，通过权限设置可以让不同的用户或用户组拥有操作不同Kubernetes资源的权限。Kubernetes RBAC API定义了四种类型：Role、ClusterRole、RoleBinding与ClusterRoleBinding，这四种类型之间的关系和简要说明如下： Role：角色，其实是定义一组对Kubernetes资源（命名空间级别）的访问规则。 RoleBinding：角色绑定，定义了用户和角色的关系。 ClusterRole：集群角色，其实是定义一组对Kubernetes资源（集群级别，包含全部命名空间）的访问规则。 ClusterRoleBinding：集群角色绑定，定义了用户和集群角色的关系。 Role和ClusterRole指定了可以对哪些资源做哪些动作，RoleBinding和ClusterRoleBinding将角色绑定到特定的用户、用户组或ServiceAccount上。如下图所示。 图1 角色绑定 在CCE控制台可以授予用户或用户组命名空间权限，可以对某一个命名空间或全部命名空间授权，CCE控制台默认提供如下ClusterRole。 view（只读权限）：对全部或所选命名空间下大多数资源的只读权限。 edit（开发权限）：对全部或所选命名空间下多数资源的读写权限。当配置在全部命名空间时能力与运维权限一致。 admin（运维权限）：对全部命名空间下大多数资源的读写权限，对节点、存储卷，命名空间和配额管理的只读权限。 cluster-admin（管理员权限）：对全部命名空间下所有资源的读写权限。 drainage-editor：节点排水操作权限，可执行节点排水。 drainage-viewer：节点排水只读权限，仅可查看节点排水状态，无法执行节点排水。 geip-editor-role：该权限用于在集群中使用全域弹性公网IP资源，仅对资源geips具有读写权限。 icagent-clusterRole：该权限用于生成Kubernetes事件日志上报到LTS。

集群权限（IAM系统策略授权） 默认情况下，管理员创建的IAM用户没有任何权限，需要将其加入用户组，并给用户组授予策略或角色，才能使得用户组中的用户获得对应的权限，这一过程称为授权。授权后，用户就可以基于被授予的权限对云服务进行操作。 CCE部署时通过物理区域划分，为项目级服务。授权时，“作用范围”需要选择“区域级项目”，然后在指定区域对应的项目中设置相关权限，并且该权限仅对此项目生效；如果在“所有项目”中设置权限，则该权限在所有区域项目中都生效。访问CCE时，需要先切换至授权区域。 权限根据授权精细程度分为角色和策略。 角色：IAM最初提供的一种根据用户的工作职能定义权限的粗粒度授权机制。该机制以服务为粒度，提供有限的服务相关角色用于授权。由于云各服务之间存在业务依赖关系，因此给用户授予角色时，可能需要一并授予依赖的其他角色，才能正确完成业务。角色并不能满足用户对精细化授权的要求，无法完全达到企业对权限最小化的安全管控要求。 策略：IAM最新提供的一种细粒度授权的能力，可以精确到具体服务的操作、资源以及请求条件等。基于策略的授权是一种更加灵活的授权方式，能够满足企业对权限最小化的安全管控要求。例如：针对CCE服务，租户（Domain）能够控制用户仅能对某一类集群和节点资源进行指定的管理操作。多数细粒度策略以API接口为粒度进行权限拆分，CCE支持的API授权项请参见权限策略和授权项。 如表1所示，包括了CCE的所有系统权限。 表1 CCE系统权限 系统角色/策略名称 描述 类别 依赖关系 CCE Administrator 具有CCE集群及集群下所有资源（包含集群、节点、工作负载、任务、服务等）的读写权限。 系统角色 拥有该权限的用户必须同时拥有以下权限： 全局服务：OBS Buckets Viewer、OBS Administrator。 区域级项目：Tenant Guest、Server Administrator、ELB Administrator、SFS Administrator、SWR Admin、 APM FullAccess。 说明： 如果同时拥有NAT Gateway Administrator权限，则可以在集群中使用NAT网关的相关功能。 如果IAM子用户需要对其他用户或用户组进行集群命名空间授权，则该用户需要拥有IAM只读权限。 CCE FullAccess CCE服务集群相关资源的普通操作权限，不包括集群（启用Kubernetes RBAC鉴权）的命名空间权限，不包括委托授权、生成集群证书等管理员角色的特权操作。 策略 无 CCE ReadOnlyAccess CCE服务集群相关资源的查看权限，不包括集群（启用Kubernetes RBAC鉴权）的命名空间权限。 策略 无 表2 CCE常用操作与系统权限的关系 操作 CCE ReadOnlyAccess CCE FullAccess CCE Administrator 创建集群 x √ √ 删除集群 x √ √ 更新集群，如后续允许集群支持RBAC，调度参数更新等 x √ √ 升级集群 x √ √ 唤醒集群 x √ √ 休眠集群 x √ √ 查询集群列表 √ √ √ 查询集群详情 √ √ √ 添加节点 x √ √ 删除节点/批量删除节点 x √ √ 更新节点，如更新节点名称 x √ √ 查询节点详情 √ √ √ 查询节点列表 √ √ √ 查询任务列表（集群层面的job） √ √ √ 删除任务/批量删除任务（集群层面的job） x √ √ 查询任务详情（集群层面的job） √ √ √ 创建存储 x √ √ 删除存储 x √ √ 操作所有kubernetes资源。 √（需Kubernetes RBAC授权） √（需Kubernetes RBAC授权） √ 容器智能分析所有资源查看权限 √ √ √ 容器智能分析所有资源操作权限 x √ √ 告警助手所有资源查看权限 √ √ √ 告警助手所有资源操作权限 x √ √ ECS（弹性云服务器）服务的所有权限。 x √ √ EVS（云硬盘）的所有权限。 可以将云硬盘挂载到云服务器，并可以随时扩容云硬盘容量 x √ √ VPC（虚拟私有云）的所有权限。 创建的集群需要运行在虚拟私有云中，创建命名空间时，需要创建或关联VPC，创建在命名空间的容器都运行在VPC之内。 x √ √ ECS（弹性云服务器）所有资源详情的查看权限。 CCE中的一个节点就是具有多个云硬盘的一台弹性云服务器 √ √ √ ECS（弹性云服务器）所有资源列表的查看权限。 √ √ √ EVS（云硬盘）所有资源详情的查看权限。可以将云硬盘挂载到云服务器，并可以随时扩容云硬盘容量 √ √ √ EVS（云硬盘）所有资源列表的查看权限。 √ √ √ VPC（虚拟私有云）所有资源详情的查看权限。 创建的集群需要运行在虚拟私有云中，创建命名空间时，需要创建或关联VPC，创建在命名空间的容器都运行在VPC之内 √ √ √ VPC（虚拟私有云）所有资源列表的查看权限。 √ √ √ ELB（弹性负载均衡）服务所有资源详情的查看权限。 x x √ ELB（弹性负载均衡）服务所有资源列表的查看权限。 x x √ SFS（弹性文件服务）服务所有资源详情的查看权限。 √ √ √ SFS（弹性文件服务）服务所有资源列表额查看权限。 √ √ √ AOM（应用运维管理）服务所有资源详情的查看权限。 √ √ √ AOM（应用运维管理）服务所有资源列表的查看权限。 √ √ √ AOM（应用运维管理）服务自动扩缩容规则的所有操作权限。 √ √ √

使用示例 例如某用户作业提交较多，流程耗时、繁琐、复杂，使用组件客户端完成作业提交效率低下。不想使用大数据组件客户端提交大数据作业，可以安装JobGateway组件，使用JobGateway服务完成作业的提交；只需要构建基于rest风格的http/https的url即可完成作业提交。 MRS 3.3.1-LTS及之后版本：JobGateway提供租户侧作业提交接口，以Hive作业提交为例，示例如下： curl --location --request POST 'https://{host}:{port}/v2/job-executions --header 'JobServerAuthorization: {AuthorizationInfo}' --header 'Content-Type: application/json' --data-raw '{ "job_name":"{job-name}", "job_type":"HiveSql", "arguments":["SHOW TABLES"] }' 返回值： { "job_submit_result": { "job_id":"84261052-c47b-4691-ae0b-95bff3191c90", "state":"COMPLETE" } }

场景三：系统表过大导致VACUUM FULL执行慢 在排除I/O和网络问题后，对空表执行VACUUM FULL，即使是空表执行VACUUM FULL也比较慢，则说明是系统表较大导致。因为VACUUM FULL任意一张表时，都会扫描pg_class、pg_partition、pg_proc三张系统表，当这三个系统表过大时，也会导致VACUUM FULL执行较慢。 处理方法：GaussDB(DWS)支持对系统表执行VACUUM FULL，但是会产生八级锁，涉及相关系统表的业务会被阻塞，注意要在业务空闲时间窗或停止业务期间且没有DDL操作时清理系统表。 有关清理系统表的操作，请参考哪些系统表不能做VACUUM FULL。

场景四：列存表使用了局部聚簇（PCK）时，VACUUM FULL执行慢 对列存表执行VACUUM FULL时，如果存在PCK，就会将PARTIAL_CLUSTER_ROWS中多条记录全都加载到内存中再进行排序，如果表较大或GUC参数psort_work_mem设置较小，会导致PCK排序时产生下盘（数据库选择将临时结果暂存到磁盘），进行外部排序；一旦进行外部排序，时间消耗就会增加很多。 处理方法：根据表中数据的tuple length，合理调整PARTIAL_CLUSTER_ROWS和psort_work_mem的大小。 执行以下语句查看表定义。回显中存在“PARTIAL CLUSTER KEY”信息，表示存在PCK。 1 SELECT * FROM pg_get_tabledef('table name'); 查看psort_work_mem是否设置过小，根据业务情况适当调大psort_work_mem。 1 show psort_work_mem; 再重新执行VACUUM FULL操作。

场景一：存在锁等待导致VACUUM FULL执行慢 8.1.x及以上集群版本的处理方法： 通过查询pgxc_lock_conflicts视图查看锁冲突情况。 1 SELECT * FROM pgxc_lock_conflicts; 在查询结果中查看granted字段为“f”，表示VACUUM FULL语句正在等待其他锁。granted字段为“t”，表示INSERT语句是持有锁。nodename，表示锁产生的位置，即CN或DN位置，例如cn_5001，继续执行2。 如果查询结果为0 rows，则表示不存在锁冲突。则需排查其它场景。 根据语句内容判断是终止持锁语句后继续执行VACUUM FULL还是在业务低峰期选择合适的时间执行VACUUM FULL。 如果要终止持锁语句，则执行以下语句。pid从上述步骤1获取，cn_5001为所查询到的nodename。 1 execute direct on (cn_5001) 'SELECT PG_TERMINATE_BACKEND(pid)'; 语句终止后，再重新执行VACUUM FULL。 1 VACUUM FULL table_name; 8.0.x及以前版本的处理方法： 在数据库中执行语句，获取VACUUM FULL操作对应的query_id。 1 SELECT * FROM pgxc_stat_activity WHERE query LIKE '%vacuum%'AND waiting = 't'; 根据1获取的query_id，执行以下语句查看是否存在锁等待。 1 SELECT * FROM pgxc_thread_wait_status WHERE query_id = {query_id}; 查询结果中“wait_status”存在“acquire lock”表示存在锁等待。同时查看“node_name”显示在对应的CN或DN上存在锁等待，记录相应的CN或DN名称，例如cn_5001或dn_600x_600y，继续执行3。 查询结果中“wait_status”不存在“acquire lock”，排除锁等待情况，继续排查其它场景。 执行以下语句，到等锁的对应CN或DN上从pg_locks中查看VACUUM FULL操作在等待哪个锁。以cn_5001为例，如果在DN上等锁，则改为相应的DN名称。pid为2获取的tid。 回显中记录relation的值。 1 execute direct on (cn_5001) 'SELECT * FROM pg_locks WHERE pid = {tid} AND granted = ''f'''; 根据获取的relation，从pg_locks中查看当前持有锁的pid。relation从3获取。 1 execute direct on (cn_5001) 'SELECT * FROM pg_locks WHERE relation = {relation} AND granted = ''t'''; 根据pid，执行以下语句查到对应的SQL语句。pid从4获取。 1 execute direct on (cn_5001) 'SELECT query FROM pg_stat_activity WHERE pid ={pid}'; 根据语句内容判断是终止持锁语句后继续执行VACUUM FULL还是在业务低峰期选择合适的时间执行VACUUM FULL。 如果要终止持锁语句，则执行以下语句。pid从上述4获取，cn_5001为所查询到的nodename。 1 execute direct on (cn_5001) 'SELECT PG_TERMINATE_BACKEND(pid)'; 语句终止后，再执行VACUUM FULL。 1 VACUUM FULL table_name;

场景10：小文件多IOPS高 某业务执行过程中，整个集群IOPS飙高，另外当出现集群故障后，长期Building不成功，IOPS飙高，相关表信息如下： SELECT relname,reloptions,partcount FROM pg_class c INNER JOIN ( SELECT parentid,count(*) AS partcount FROM pg_partition GROUP BY parentid ) s ON c.oid = s.parentid ORDER BY partcount DESC; 触发因素：某业务库大量列存多分区（3000+）的表，导致小文件巨多（单DN文件2000w+），访问效率低，故障恢复Building极慢，同时Building也消耗大量IOPS，反向影响业务性能。 解决办法： 整改列存分区间隔，减少分区个数来降低文件个数。 列存表修改为行存表，行存的存储特征决定其文件个数不会像列存般膨胀严重。

场景8：大量数据带索引导入 某业务场景数据往DWS同步时，延迟严重，集群整体I/O压力大。 后台查看等待视图有大量wait wal sync和WALWriteLock状态，均为xlog同步状态。 触发因素：大量数据带索引（一般超过3个）导入（insert/copy/merge into）会产生大量xlog，导致主备同步慢，备机长期Catchup，整体I/O利用率飙高。 解决方案： 严格控制每张表的索引个数，建议3个以内。 大量数据导入前先将索引删除，导入完成后再重新建索引。

场景9：行存大表首次查询 某业务场景出现备DN持续catchup，I/O压力大，观察某个SQL等待视图在wait wal sync。 排查业务发现某查询语句执行时间较长，执行kill命令后恢复。 触发因素：行存表大量数据入库后，首次查询触发page hint产生大量X LOG ，触发主备同步慢及大量I/O消耗。 解决措施： 对该类一次性访问大量新数据的场景，修改行存表为列存表。 可关闭wal_log_hints和enable_crc_check参数（不推荐该方式，因故障期间有数据丢失风险）。

场景4：无索引、有索引不走 某一次点查询，Seq Scan扫描需要3767ms，因涉及从4096000条数据中获取8240条数据，符合索引扫描的场景（海量数据中寻找少量数据），在对过滤条件列增加索引后，计划依然是Seq Scan而没有走Index Scan。 对目标表ANALYZE后，计划能够自动选择索引，性能从3s+优化到2ms+，极大降低I/O消耗。 常见场景：行存大表的查询场景，从大量数据中访问极少数据，没走索引扫描而是走顺序扫描，导致I/O效率低，不走索引常见有两种情况： 过滤条件列上没建索引。 有索引但是计划没选索引扫描。 触发因素： 常用过滤条件列没有建索引。 表中数据因执行DML操作后产生数据变化未及时ANALYZE，导致优化器无法选择索引扫描计划，ANALYZE介绍参见ANALYZE。 处理方式： 对行存表常用过滤列增加索引，索引基本设计原则： 索引列选择distinct值多，且常用于过滤条件，过滤条件多时可以考虑建组合索引，组合索引中distinct值多的列排在前面，索引个数不宜超过3个。 大量数据带索引导入会产生大量I/O，如果该表涉及大量数据导入，需严格控制索引个数，建议导入前先将索引删除，导入完成后再重新建索引。 对频繁做DML操作的表，业务中加入及时ANALYZE，主要场景： 表数据从无到有。 表频繁进行INSERT/UPDATE/DELETE。 表数据即插即用，需要立即访问且只访问刚插入的数据。

场景5：无分区、有分区不剪枝 例如某业务表经常使用createtime时间列作为过滤条件获取特定时间数据，对该表设计为分区表后没有走分区剪枝（Selected Partitions数量多），Scan花了701785ms，I/O效率极低。 在增加分区键createtime作为过滤条件后，Partitioned scan走分区剪枝（Selected Partitions数量极少），性能从700s优化到10s，I/O效率极大提升。 常见场景：按照时间存储数据的大表，查询特征大多为访问当天或者某几天的数据，这种情况应该通过分区键进行分区剪枝（只扫描对应少量分区）来极大提升I/O效率，不走分区剪枝常见的情况有： 未设计成分区表。 设计了分区没使用分区键做过滤条件。 分区键做过滤条件时，对列值有函数转换。 触发因素：未合理使用分区表和分区剪枝功能，导致扫描效率低。 处理方式： 对按照时间特征存储和访问的大表设计成分区表。 分区键一般选离散度高、常用于查询过滤条件中的时间类型的字段。 分区间隔一般参考高频的查询所使用的间隔，需要注意的是针对列存表，分区间隔过小（例如按小时）可能会导致小文件过多的问题，一般建议最小间隔为按天。

场景6：行存表求count值 某行存大表频繁全表count（指不带过滤条件或者过滤条件过滤很少数据的count），其中Scan花费43s，持续占用大量I/O，此类作业并发起来后，整体系统I/O持续100%，触发I/O瓶颈，导致整体性能慢。 对比相同数据量的列存表（A-rows均为40960000），列存的Scan只花费14ms，I/O占用极低。 触发因素：行存表因其存储方式的原因，全表scan的效率较低，频繁的对大表全表扫描，导致I/O持续占用。 解决办法： 业务侧审视频繁全表count的必要性，降低全表count的频率和并发度。 如果业务类型符合列存表，则将行存表修改为列存表，提高I/O效率。

场景7：行存表求max值 计算某行存表某列的max值，花费了26772ms，此类作业并发起后，整体系统I/O持续100%，触发I/O瓶颈，导致整体性能慢。 针对max列增加索引后，语句耗时从26s优化到32ms，极大减少I/O消耗。 触发因素：行存表max值逐个scan符合条件的值来计算max，当scan的数据量很大时，会持续消耗I/O。 解决办法：给max列增加索引，凭借btree索引数据有序存储的特征，加速扫描过程，降低I/O消耗。

场景1：列存小CU膨胀 某业务SQL查询出390871条数据需43248ms，分析计划主要耗时在Cstore Scan。 Cstore Scan的详细信息中，每个DN扫描出2w左右的数据，但是扫描了有数据的CU（CUSome）155079个，没有数据的CU（CUNone）156375个，说明当前小CU、未命中数据的CU极多，即CU膨胀严重。 触发因素：对列存表（尤其是分区表）进行高频小批量导入会造成CU膨胀。 处理方法 列存表的数据入库方式修改为攒批入库，单分区单批次入库数据量需大于DN个数*6W。 如果因业务原因无法攒批入库，则需定期VACUUM FULL此类高频小批量导入的列存表。 当小CU膨胀很快时，频繁VACUUM FULL也会消耗大量I/O，甚至加剧整个系统的I/O瓶颈，此场景建议修改列存表为行存表（CU长期膨胀严重的情况下，列存的存储空间优势和顺序扫描性能优势将不复存在）。

场景3：表存储倾斜 例如表Scan的A-time中，max time DN执行耗时6554ms，min time DN耗时0s，DN之间扫描差异超过10倍以上，这种集合Scan的详细信息，基本可以确定为表存储倾斜导致。 通过table_distribution发现所有数据倾斜到了dn_6009单个DN，修改分布列使得表存储分布均匀后，max dn time和min dn time基本维持在相同水平400ms左右，Scan时间从6554ms优化到431ms。 触发因素：分布式场景，表分布列选择不合理会导致存储倾斜，同时导致DN间压力失衡，单DN I/O压力大，整体I/O效率下降。 解决办法：修改表的分布列使表的存储分布均匀，分布列选择原则参见选择分布列。

场景2：脏数据&数据清理 某业务SQL总执行时间2.519s，其中Scan占了2.516s，同时该表的扫描最终只扫描到0条符合条件数据，过滤了20480条数据，即总共扫描了20480+0条数据却消耗了2s+，扫描时间与扫描数据量严重不符，此现象可判断为由于脏数据多从而影响扫描和I/O效率。 查看表脏页率为99%，VACUUM FULL后性能优化到100ms左右。 触发因素：表频繁执行UPDATE/DELETE导致脏数据过多，且长时间未VACUUM FULL清理。 处理方法 对频繁UPDATE/DELETE产生脏数据的表，定期VACUUM FULL，因大表的VACUUM FULL也会消耗大量I/O，因此需要在业务低峰时执行，避免加剧业务高峰期I/O压力。 当脏数据产生很快，频繁VACUUM FULL也会消耗大量I/O，甚至加剧整个系统的I/O瓶颈，这时需要考虑脏数据的产生是否合理。针对频繁DELETE的场景，可以考虑如下方案： 全量DELETE修改为TRUNCATE或者使用临时表替代。 定期DELETE某时间段数据，使用分区表并使用TRUNCATE或DROP分区替代。