命名空间权限 Kubernetes RBAC API定义了四种类型：Role、ClusterRole、RoleBinding与ClusterRoleBinding。当前CCI仅支持ClusterRole、RoleBinding，这两种类型之间的关系和简要说明如下： ClusterRole：描述角色和权限的关系。在Kubernetes的RBAC API中，一个角色定义了一组特定权限的规则。整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。 RoleBinding：描述subjects（包含users，groups）和角色的关系。角色绑定将一个角色中定义的各种权限授予一个或者一组用户，该用户或用户组则具有对应绑定ClusterRole定义的权限。 表1 RBAC API所定义的两种类型 类型名称 说明 ClusterRole ClusterRole对象可以授予整个集群范围内资源访问权限。 RoleBinding RoleBinding可以将同一Namespace中的subject（用户）绑定到某个具有特定权限的ClusterRole下，则此subject即具有该ClusterRole定义的权限。 当前仅支持用户使用ClusterRole在Namespace下创建RoleBinding。

产品架构 云容器实例提供Serverless Container服务，拥有多个异构的Kubernetes集群，并集成网络、存储服务，让您方便地通过控制台、kubectl、Kubernetes API创建和使用容器负载。 图2 产品架构 基于云平台底层网络和存储服务（VPC、ELB、NAT、EVS、OBS、SFS等），提供丰富的网络和存储功能。 提供高性能、异构的基础设施（x86服务器、GPU加速型服务器、Ascend加速型服务器），容器直接运行在物理服务器上。 使用安全容器提供虚拟机级别的安全隔离，结合自有硬件虚拟化加速技术，提供高性能安全容器。 多集群统一管理，容器负载统一调度，使用上无需感知集群存在。 基于Kubernetes的负载模型提供负载快速部署、弹性负载均衡、弹性扩缩容、蓝绿发布等重要能力。

产品功能 一站式容器生命周期管理 使用云容器实例，您无需创建和管理服务器集群即可直接运行容器。您可以通过控制台、kubectl、Kubernetes API创建和使用容器负载，且只需为容器所使用的资源付费。 支持多种类型计算资源 云容器实例提供了多种类型计算资源运行容器，包括CPU，GPU（提供NVIDIA Tesla V100、NVIDIA Tesla T4显卡）。 支持多种网络访问方式 云容器实例提供了丰富的网络访问方式，支持四层、七层负载均衡，满足不同场景下的访问诉求。 支持多种持久化存储卷 云容器实例支持将数据存储在云服务的 云存储 上，当前支持的云存储包括：云硬盘存储卷（EVS）、文件存储卷（SFS）、对象存储卷（OBS）和极速文件存储卷（SFS Turbo）。 支持极速弹性扩缩容 云容器实例支持用户自定义弹性伸缩策略，且能在1秒内实现弹性扩缩容，并可以自由组合多种弹性策略以应对业务高峰期的突发流量浪涌。 全方位容器状态监控 云容器实例支持监控容器运行的资源使用率，包括CPU、内存、GPU和显存的使用率，方便您实时掌控容器运行的状态。

什么是云容器实例 云容器实例（Cloud Container Instance，CCI）服务提供Serverless Container（无服务器容器）引擎，让您无需创建和管理服务器集群即可直接运行容器。 Serverless是一种架构理念，是指不用创建和管理服务器、不用担心服务器的运行状态（服务器是否在工作等），只需动态申请应用需要的资源，把服务器留给专门的维护人员管理和维护，进而专注于应用开发，提升应用开发效率、节约企业IT成本。传统上使用Kubernetes运行容器，首先需要创建运行容器的Kubernetes服务器集群，然后再创建容器负载。 云容器实例的Serverless Container就是从使用角度，无需创建、管理Kubernetes集群，也就是从使用的角度看不见服务器（Serverless），直接通过控制台、kubectl、Kubernetes API创建和使用容器负载，且只需为容器所使用的资源付费。 图1 使用云容器实例

标签 Label（标签）是一组附加在对象上的键值对，用来传递用户定义的属性。 标签常用来从一组对象中选取符合条件的对象，这也是Kubernetes中目前为止最重要的节点分组方法。 比如，您可能创建了一个“tier”和“app”标签，通过Label（tier=frontend，app=myapp）来标记前端Pod容器，使用Label（tier=backend，app=myapp）标记后台Pod。然后可以使用Selectors选择带有特定Label的Pod，并且将Service或者Deployment应用到上面。 详细信息请参见Label。 图2 使用Label组织的Pod

Init容器（Init-Containers） Init-Containers，即初始化容器，顾名思义容器启动的时候，会先启动一个或多个容器，如果有多个，那么这几个Init Container按照定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到。 Init Container可以在多种K8S资源里被使用到如Deployment、Job等，但归根结底都是在Pod启动时，在主容器启动前执行，做初始化工作。 详细信息请参见Init容器。

无状态负载（Deployment） Deployment是Pod Controller的一种。 一个Deployment可以包含一个或多个Pod，每个Pod的角色相同，所以系统会自动为Deployment的多个Pod分发请求。Deployment中的所有Pod共享存储卷。 使用Deployment时，您只需要在Deployment中描述您想要的目标状态是什么，Deployment就会帮您将Pod的状态改变到目标状态。 详细信息请参见Deployment。

服务（Service） Pod是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。通过Pod Controller能够动态地创建和销毁Pod（例如，需要进行扩缩容，或者执行滚动升级）。每个Pod都会获取它自己的IP地址，但这些IP地址不总是稳定可依赖的。 这会导致一个问题：如果一组Pod（称为backend）为其它Pod（称为frontend）提供服务，那么那些frontend该如何发现，并连接到这组Pod中的哪些backend呢？ Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们的策略（通常称为微服务）。 这一组Pod能够被Service访问到，通常是通过Label Selector实现的。 举个例子，考虑一个图片处理backend，它运行了3个Pod副本。这些副本是可互换的（frontend不需要关心它们调用了哪个backend副本）。 然而组成这一组backend的Pod实际上可能会发生变化，frontend不应该也没必要知道，而且也不需要跟踪这一组backend的状态。Service定义的抽象就是用来解耦这种关联。 详细信息请参见Service。

Pod Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器、存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。 图1 Pod Pod使用主要分为两种方式： Pod中运行一个容器。这是Kubernetes最常见的用法，您可以将Pod视为单个封装的容器，但是Kubernetes是直接管理Pod而不是容器。 Pod中运行多个需要耦合在一起工作、需要共享资源的容器。 实际使用中很少直接创建Pod，而是使用Kubernetes中称为Controller的抽象层来管理Pod实例，例如Deployment。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。通常，Controller会使用Pod Template来创建相应的Pod。 详细信息请参见Pod。

CCI权限 默认情况下，管理员创建的 IAM 用户没有任何权限，需要将其加入用户组，并给用户组授予策略或角色，才能使得用户组中的用户获得对应的权限，这一过程称为授权。授权后，用户就可以基于被授予的权限对云服务进行操作。 CCI部署时通过物理区域划分，为项目级服务。授权时，“作用范围”需要选择“区域级项目”，然后在指定区域（如华北-北京四）对应的项目（cn-north-4）中设置相关权限，并且该权限仅对此项目生效；如果在“所有项目”中设置权限，则该权限在所有区域项目中都生效。访问CCI时，需要先切换至授权区域。 根据授权精细程度分为角色和策略。 角色：IAM最初提供的一种根据用户的工作职能定义权限的粗粒度授权机制。该机制以服务为粒度，提供有限的服务相关角色用于授权。由于云平台各服务之间存在业务依赖关系，因此给用户授予角色时，可能需要一并授予依赖的其他角色，才能正确完成业务。角色并不能满足用户对精细化授权的要求，无法完全达到企业对权限最小化的安全管控要求。 策略：IAM最新提供的一种细粒度授权的能力，可以精确到具体服务的操作、资源以及请求条件等。基于策略的授权是一种更加灵活的授权方式，能够满足企业对权限最小化的安全管控要求。例如：针对CCI服务，管理员能够控制IAM用户仅能对某一类云容器实例资源进行指定的管理操作。

策略授权系统权限 CCI服务支持基于策略授权的授权模型。如表4所示，包括了CCI基于策略授权中的所有系统策略。策略授权的系统策略与角色授权的系统策略并不互通。 表4 CCI系统策略 系统策略名称 描述 策略类别 CCIFullAccessPolicy 云容器实例服务所有权限 系统策略 CCIReadOnlyPolicy 云容器实例服务只读访问权限 系统策略 表5列出了CCI常用操作与系统策略的授权关系，您可以参照该表选择合适的系统策略。 表5 常用操作与系统策略的关系 操作 CCIFullAccessPolicy CCIReadOnlyPolicy 创建Pod √ x 删除Pod √ x 查看Pod √ √ 查看资源使用率 √ √ 创建文件存储卷 x x 删除文件存储卷 x x 查看文件存储卷 √ √ 创建ConfigMap √ x 删除ConfigMap √ x 查看ConfigMap √ √ 创建Secret √ x 删除Secret √ x 查看Secret √ √ 查看日志 √ √ 获取指定namespace √ √ 创建namespace √ x 删除namespace √ x

角色授权系统权限 CCI服务支持基于角色授权的授权模型。默认情况下，管理员创建的IAM用户没有任何权限，需要将其加入用户组，并给用户组授予策略或角色，才能使得用户组中的用户获得对应的权限，这一过程称为授权。授权后，用户就可以基于被授予的权限对云服务进行操作。 CCI部署时通过物理区域划分，为项目级服务。授权时，“授权范围”需要选择“指定区域项目资源”，然后在指定区域（如华北-北京四）对应的项目（cn-north-4）中设置相关权限，并且该权限仅对此项目生效；如果“授权范围”选择“所有资源”，则该权限在所有区域项目中都生效。访问CCI时，需要先切换至授权区域。 如表2所示，包括了CCI的所有系统权限。基于角色授权场景的系统策略与基于策略授权场景的并不互通。 表2 CCI系统权限 系统策略名称 描述 类别 CCI FullAccess 云容器实例所有权限，拥有该权限的用户可以执行云容器实例所有资源的创建、删除、查询、更新操作。 说明： 对象存储服务 OBS为全局级服务，若需要使用对象存储服务请为其单独授予权限，授权操作请参见对象存储服务权限控制。 系统策略 CCI ReadOnlyAccess 云容器实例只读权限，拥有该权限的用户仅能查看云容器实例资源。 系统策略 CCI CommonOperations 云容器实例普通用户，拥有该权限的用户可以执行除RBAC、network和namespace子资源创建、删除、修改之外的所有操作。 系统策略 CCI Administrator 云容器实例管理员权限，拥有该权限的用户可以执行云容器实例所有资源的创建、删除、查询、更新操作。 系统角色 表3列出了CCI常用操作与系统权限的授权关系，您可以参照该表选择合适的系统权限。 表3 常用操作与系统策略的关系 操作 CCI FullAccess CCI ReadOnlyAccess CCI CommonOperations 创建无状态负载 √ x √ 删除无状态负载 √ x √ 查看无状态负载 √ √ √ 升级负载 √ x √ 伸缩负载 √ x √ 删除Pod √ x √ 查看Pod √ √ √ 创建任务 √ x √ 删除任务 √ x √ 查看任务 √ √ √ 创建定时任务 √ x √ 删除定时任务 √ x √ 查看定时任务 √ √ √ 查看资源使用率 √ √ √ 添加云硬盘卷 √ x √ 删除云硬盘卷 √ x √ 查看云硬盘卷 √ √ √ 创建文件存储卷 √ x √ 删除文件存储卷 √ x √ 查看文件存储卷 √ √ √ 创建ConfigMap √ x √ 删除ConfigMap √ x √ 查看ConfigMap √ √ √ 创建Secret √ x √ 删除Secret √ x √ 查看Secret √ √ √ 添加SSL证书 √ x √ 删除SSL证书 √ x √ 查看SSL证书 √ √ √ 添加日志存储 √ x √ 查看日志 √ √ √ 安装插件 √ x √ 删除插件 √ x √ 查看插件 √ √ √ 查看授权 √ √ √ 新增授权 √ x x 删除授权 √ x x 获取指定namespace √ √ √ 创建namespace √ x x 删除namespace √ x x 创建network √ x x 删除network √ x x 查询network列表 √ √ √ 查询network详情 √ √ √

Pod规格限制 云容器实例当前支持使用GPU，您可以根据需要选择，实例收费详情请参见产品价格详情。 当不使用GPU时，Pod规格需满足如下要求： 表1 Pod规格限制要求 Pod规格限制项 限制取值范围 Pod的CPU 0.25核-32核，或者自定义选择48核、64核。 CPU必须为0.25核的整数倍。 Pod的内存 1GiB-512GiB。 内存必须为1GiB的整数倍。 Pod的CPU/内存配比值 在1:2至1:8之间。 Pod的容器 一个Pod内最多支持5个容器。 Pod中所有容器和InitContainer（启动容器） 两者规格中的request和limit相等。 InitContainer是一种特殊容器，在 Pod 内的应用容器启动之前运行。

Kubernetes应用限制 基于华为云的安全性带来的限制，CCI目前还不支持Kubernetes中HostPath、DaemonSet等功能，具体如下表所示。 不支持的功能 说明 推荐替代方案 HostPath 挂载本地宿主机文件到容器中 使用云盘或者SFS文件系统 HostNetwork 将宿主机端口映射到容器上 使用type=LoadBalancer的负载均衡 DaemonSet DaemonSet（守护进程集）在集群的每个节点上运行一个Pod，且保证只有一个Pod 通过sidecar形式在Pod中部署多个容器 Privileged权限 容器拥有privileged权限 使用Security Context为Pod添加Capability type=NodePort的Service 将宿主机端口映射到容器上 使用type=LoadBalancer的负载均衡

简介 本章节主要指导用户在CCE集群上使用bursting插件，快速帮助用户将负载通过插件从CCE集群弹性到CCI上。 CCE突发弹性引擎（对接 CCI）作为一种虚拟的kubelet用来连接Kubernetes集群和其他平台的API。Bursting的主要场景是将Kubernetes API扩展到无服务器的容器平台（如CCI）。 基于该插件，支持用户在短时高负载场景下，将部署在云容器引擎CCE上的无状态负载（Deployment）、有状态负载（StatefulSet）、普通任务（Job）、定时任务（CronJob）四种资源类型的容器实例（Pod），弹性创建到云容器实例CCI服务上，以减少集群扩容带来的消耗。