基本概念
云容器实例基于Kubernetes的负载模型增强了容器安全隔离、负载快速部署、弹性负载均衡、弹性扩缩容、蓝绿发布等重要能力。
云容器实例提供Kubernetes原生API，支持使用kubectl，且提供图形化控制台，让您能够拥有完整的端到端使用体验，使用云容器实例前，建议您先了解相关的基本概念。
镜像（Image）
容器镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。
容器（Container）
镜像和容器的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
命名空间（Namespace）
命名空间是一种在多个用户之间划分资源的方法。当您的项目和人员众多的时候可以考虑根据项目属性，例如生产、测试、开发划分不同的namespace。
Pod
Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器、存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。
Pod使用主要分为两种方式：
- Pod中运行一个容器。这是Kubernetes最常见的用法，您可以将Pod视为单个封装的容器，但是Kubernetes是直接管理Pod而不是容器。
- Pod中运行多个需要耦合在一起工作、需要共享资源的容器。
实际使用中很少直接创建Pod，而是使用Kubernetes中称为Controller的抽象层来管理Pod实例，例如Deployment。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。通常，Controller会使用Pod Template来创建相应的Pod。
详细信息请参见Pod。
Init容器（Init-Containers）
Init-Containers，即初始化容器，顾名思义容器启动的时候，会先启动一个或多个容器，如果有多个，那么这几个Init Container按照定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到。
Init Container可以在多种K8S资源里被使用到如Deployment、Job等，但归根结底都是在Pod启动时，在主容器启动前执行，做初始化工作。
详细信息请参见Init容器。
标签
Label（标签）是一组附加在对象上的键值对，用来传递用户定义的属性。
标签常用来从一组对象中选取符合条件的对象，这也是Kubernates中目前为止最重要的节点分组方法。
比如，您可能创建了一个“tier”和“app”标签，通过Label（tier=frontend，app=myapp）来标记前端Pod容器，使用Label（tier=backend，app=myapp）标记后台Pod。然后可以使用Selectors选择带有特定Label的Pod，并且将Service或者Deployment应用到上面。
详细信息请参见Label。
无状态负载（Deployment）
Deployment是Pod Controller的一种。
一个Deployment可以包含一个或多个Pod，每个Pod的角色相同，所以系统会自动为Deployment的多个Pod分发请求。Deployment中的所有Pod共享存储卷。
使用Deployment时，您只需要在Deployment中描述您想要的目标状态是什么，Deployment就会帮您将Pod的状态改变到目标状态。
详细信息请参见Deployment。
短时任务（Job）
Job是用来控制批处理型任务的资源对象。批处理业务与长期伺服业务（Deployment）的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。
Job的这种用完即停止的特性特别适合一次性任务，比如持续集成，配合云容器实例按秒计费，真正意义上做到按需使用、按需付费。
详细信息请参见Job。
服务（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。
Ingress
Service和Pod仅可在内部网络中通过IP地址访问，外部的请求需要通过负载均衡转发到Service在Node上暴露的NodePort上，然后再由kube-proxy将其转发给相关的Pod。
Ingress是授权入站连接到达集群服务的规则集合。您可以给Ingress配置外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。
详细介绍请参见Ingress。
PVC
PersistentVolumeClaim（PVC）是用户存储的请求。 它类似于Pod，Pod申请CPU和内存，PVC申请存储资源。在云容器实例中，您可以通过PVC申请EVS、SFS等存储资源。
详细信息请参见PVC。
ConfigMap
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟Secret很类似，但它可以更方便地处理不包含敏感信息的字符串。
详细信息请参见ConfigMap。
