# 基本概念
云容器实例围绕Kubernetes生态，提供了Kubernetes Like APIs，支持通过控制台、API创建关联资源。为了更好的理解云容器实例，建议您在使用云容器实例前，先了解相关的基本概念。
#### 镜像（Image）
容器镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。
#### 容器（Container）
镜像和容器的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
#### 命名空间（Namespace）
**什么是命名空间**
命名空间（Namespace）是一种将单一云容器集群在逻辑上划分为多个独立虚拟集群的隔离机制，旨在解决多团队、多环境在同一计算资源池下的命名冲突与资源抢占问题，是一种在多个用户之间划分资源的方法。其核心价值在于实现资源的可见性管控和精细化的容量配额管理。当你的项目和人员众多的时候可以考虑根据项目属性，例如生产、测试、开发划分不同的namespace。
**为什么需要命名空间**
随着云原生业务的扩大，企业的开发、测试、生产环境往往部署在同一套云设施上，多个业务部门也会共享计算网络池。如果不加以隔离，A团队很容易不小心修改或删除B团队的应用，且不同环境中的服务名称极易发生冲突；同时，某个突发流量的测试应用可能会耗尽所有的底层配额，影响核心生产业务。Namespace通过提供"逻辑隔离的虚拟空间"，有效化解了多租户资源混用的风险。
**命名空间的优势是什么**
- **名称与可见性隔离**：不同的Namespace拥有独立的作用域，在Namespace A中创建的资源（如名为 frontend 的Pod）与Namespace B中同名资源互不干扰。
- **资源配额硬性控制**：支持为每个Namespace绑定资源配额（ResourceQuota），限制该空间内允许使用的CPU和内存上限，防止劣质应用无限消耗系统资源。
**命名空间的使用场景**
- **多环境生命周期管理**：运维管理团队在规划业务系统时，Namespace提供了划分"Dev（开发）"、"Test（测试）"、"Prod（生产）"空间的能力，以实现在一套基础设施下各阶段环境的有序隔离。
- **多租户与部门成本分摊**：大型企业在管理内部IT资源时，Namespace提供了按部门隔离资源池的能力，以实现安全边界划分并便于后续的资源使用度量。
**命名空间的工作原理**
Namespace的底层原理是利用Kubernetes API服务器在对象元数据层面进行过滤和隔离。当用户通过接口查询或操作资源时，必须指定或默认处于某个Namespace上下文。系统会首先校验用户对该Namespace是否具有权限，然后在执行创建操作前，调用准入控制器（Admission Controller）核对该Namespace下剩余的CPU、内存等配额是否充足，若配额不足则拒绝请求。通过这种逻辑层面的软隔离，系统保障了全局资源的有序利用。
**与命名空间相关的操作和特性**
在CCI控制台创建命名空间时，您需要为其关联具体的虚拟私有云（VPC）和子网。这意味着，在CCI中通过Namespace不仅实现了应用定义和配额的逻辑隔离，还能借助VPC能力实现坚实的底层网络隔离。您可以在CCI的"命名空间"管理页面，直观地管理各个空间的网段分配和CPU/内存使用限额。
#### 容器组（Pod）
**什么是实例 (Pod)**
容器组是创建或部署的最小单位。一个容器组封装一个或多个容器、存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。
图1Pod   
![](https://support.huaweicloud.com/productdesc-cci2/zh-cn_image_0197841641.png)
容器组使用主要分为两种方式：
- 容器组中运行一个容器。这是最常见的用法，你可以将容器组视为单个封装的容器，是直接管理容器组而不是容器。
- 容器组中运行多个需要耦合在一起工作、需要共享资源的容器。
实际使用中很少直接创建容器组，而是通过基础负载创建和管理Pod，例如Deployment。基础负载可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。通常，基础负载会使用Pod Template来创建相应的Pod。
**为什么需要Pod**
在现代云原生架构中，应用通常由多个辅助进程共同协作完成复杂业务。如果将主程序、日志采集、流量代理等进程打包在同一个容器内，会导致镜像臃肿且违背容器的"单一职责"原则；若将它们分别部署为独立的容器，它们之间的网络通信和共享存储配置又会变得极为复杂。如何既保证容器解耦，又实现高效协同？Pod提供了一种将多个紧密相关的容器"绑定"在一起的解决方案。
**Pod的优势是什么**
- **生命周期一致性**：Pod内的所有容器同生共死，保证了辅助容器与主业务容器始终在同一个节点上协同运行。
- **网络无缝共享**：同一个Pod内的所有容器共享同一个网络命名空间（包括IP地址和端口空间），它们之间可以通过 localhost 直接进行高性能通信。
- **存储资源共享**：Pod级别可以定义共享的存储卷（Volume），内部各容器均可挂载并访问该存储卷中的数据，实现数据的低延迟交互。
**Pod的使用场景**
- **业务主进程与日志采集旁路协同**：运维团队在部署Web服务时，Pod提供了将Nginx容器和LTS（云日志服务）采集容器部署在一起的能力，以实现低延迟的日志提取与集中化上报。
- **服务网格架构代理（Service Mesh）**：微服务架构中，Pod提供了向业务容器无侵入注入Envoy等网络代理（Sidecar）的能力，以实现流量治理和安全管控。
**Pod的工作原理**
Pod的运行通常从接收到用户声明的YAML配置文件开始。在CCI的运行机制中，系统首先会为Pod分配运行所需的底层计算资源。接着，系统会拉起一个特殊的根容器（Pause容器），由它负责初始化该Pod的网络命名空间并挂载基础存储卷。随后，系统会根据用户定义，依次启动初始化容器（Init Container）和主业务容器，这些容器均自动加入Pause容器构建的网络和存储环境中。最终，这些容器作为一个整体向外提供服务。
**与Pod相关的特性和操作**
在CCI中，您可以直接创建和管理Pod，无需关注底层虚拟机的分配。在创建Pod时，您可以在CCI控制台或通过API，为Pod挂载高性能弹性文件服务（SFS Turbo）或并行文件系统（OBS）等作为共享数据卷，同时CCI支持直接为Pod分配VPC内的弹性网卡，保证网络通信的高效与安全。
#### Init容器（Init-Containers）
Init-Containers，即初始化容器，顾名思义容器启动的时候，会先启动一个或多个容器，如果有多个，那么这几个Init Container按照定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到。
Init Container可以在多种K8S资源里被使用到如Deployment、Job等，但归根结底都是在Pod启动时，在主容器启动前执行，做初始化工作。
详细信息请参见[Init容器](https://kubernetes.io/zh/docs/concepts/workloads/pods/init-containers/#resources)。
#### 标签
Label（标签）是一组附加在对象上的键值对，用来传递用户定义的属性。
标签常用来从一组对象中选取符合条件的对象，这也是Kubernetes中目前为止最重要的节点分组方法。
比如，你可能创建了一个"tier"和"app"标签，通过Label（tier=frontend，app=myapp）来标记前端Pod容器，使用Label（tier=backend，app=myapp）标记后台Pod。然后可以使用Selectors选择带有特定Label的Pod，并且将Service或者Deployment应用到上面。
详细信息请参见[Label](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)。
图2使用Label组织的Pod   
![](https://support.huaweicloud.com/productdesc-cci2/zh-cn_image_0197831172.png)
#### 无状态负载（Deployment）
**什么是无状态工作负载**
无状态工作负载（Deployment）是一种用于自动化管理Pod副本期望运行状态的控制器对象，旨在解决应用实例版本升级、扩缩容及故障恢复时人工干预慢且易出错的问题。其核心价值在于确保指定数量的实例持续稳定运行，并支持业务层面的平滑滚动发布。Deployment是基础负载的一种。
一个Deployment可以包含一个或多个Pod，每个Pod的角色相同，所以系统会自动为Deployment的多个Pod分发请求。Deployment中的所有Pod共享存储卷。
使用Deployment时，您只需要在Deployment中描述您想要的目标状态是什么，Deployment就会帮您将Pod的状态改变到目标状态。
详细信息请参见[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)。
**为什么需要无状态工作负载**
企业业务为了保障高可用性，通常需要同时运行多个相同的应用实例。然而，由于硬件故障或网络波动，个别应用实例可能会崩溃退出。此外，业务快速迭代时，全量替换旧版本实例会导致业务短暂中断。Deployment提供了声明式的自动控制机制，不仅能实现实例故障的"自动愈合"，还能在不中断服务的情况下完成版本更迭。
**无状态工作负载的优势是什么**
- **故障自愈能力**：当某个Pod实例出现异常或被意外删除时，控制器会自动感知并拉起新的Pod补充，始终维持期望的副本总数。
- **平滑的滚动升级**：支持按设定比例（如每次替换25%）逐步替换旧版本Pod实例，一旦新版本验证失败，支持一键回滚到上一稳定版本。
- **灵活的弹性伸缩**：支持根据业务压力快速手动增加/减少实例数量，或配合HPA（水平Pod自动伸缩）实现完全自动化的资源调整。
**无状态工作负载的使用场景**
- **前端网页与API网关服务部署**：网站平台在应对日常的海量用户访问时，Deployment提供了多副本部署和负载均衡的能力，以实现请求的高并发处理和单点故障的自动规避。
- **微服务应用持续交付（CI/CD）**：研发团队在频繁发布新功能时，Deployment提供了滚动发布的能力，以实现用户无感知的平滑版本切换。
**无状态工作负载的工作原理**
从架构看，Deployment并非直接管理Pod，而是通过控制ReplicaSet（副本集）来实现对Pod的管理。 其关键机制在于"声明式状态调和"。用户向系统提交期望状态（例如：需要3个Nginx应用的Pod副本）。集群控制面会通过不断运行的控制循环（Control Loop），对比当前实际运行的Pod数量与用户的期望状态。如果发现实际数量少于期望值（如某个实例宕机），控制器会向调度系统下发创建新Pod的指令；若在升级过程中，控制器则会按照预设步长，创建新版本ReplicaSet并逐步缩容旧版本ReplicaSet。通过这种机制，系统能够自主完成复杂的可用性保障任务。
**与无状态工作负载相关的特性和操作**
在CCI服务中，您可以前往"工作负载 \> 无状态（Deployment）"页面快速创建您的应用。CCI控制台提供了图形化的向导，您只需指定容器镜像地址、所需的CPU/内存限制、实例数量以及网络访问策略，CCI即可为您自动化部署该应用。升级业务时，只需在控制台更新镜像版本即可触发滚动升级。
#### 服务（Service）
Pod是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。通过Pod Controller能够动态地创建和销毁Pod（例如，需要进行扩缩容，或者执行滚动升级）。每个Pod都会获取它自己的IP地址，但这些IP地址不总是稳定可依赖的。 这会导致一个问题：如果一组Pod（称为backend）为其它Pod（称为frontend）提供服务，那么那些frontend该如何发现，并连接到这组Pod中的哪些backend呢？
Service是将运行在一个或一组Pod上的网络应用程序公开为网络服务的方法。每个Service对象定义端点的一个逻辑集合（通常这些端点就是Pod）以及如何访问这些Pod的策略。
举个例子，考虑一个图片处理backend，它运行了3个Pod副本。这些副本是可互换的（frontend不需要关心它们调用了哪个backend副本）。 然而组成这一组backend的Pod实际上可能会发生变化，frontend不应该也没必要知道，而且也不需要跟踪这一组backend的状态。Service定义的抽象就是用来解耦这种关联。
详细信息请参见[Service](https://kubernetes.io/docs/concepts/services-networking/service/)。
#### ConfigMap
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟Secret很类似，但它可以更方便地处理不包含敏感信息的字符串。
详细信息请参见[ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/)。
#### Secret
Secret是一种加密存储的资源对象，用户可以将认证信息、证书、私钥等保存在密钥中，在容器启动时以环境变量等方式加载到容器中。
详细信息请参见[Secret](https://kubernetes.io/docs/concepts/configuration/secret/)。