更新时间:2023-02-06 GMT+08:00

基本概念

云容器实例基于Kubernetes的负载模型增强了容器安全隔离、负载快速部署、弹性负载均衡、弹性扩缩容、蓝绿发布等重要能力。

云容器实例提供Kubernetes原生API,支持使用kubectl,且提供图形化控制台,让您能够拥有完整的端到端使用体验,使用云容器实例前,建议您先了解相关的基本概念。

镜像(Image)

容器镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的配置参数(如匿名卷、环境变量、用户等)。镜像不包含任何动态数据,其内容在构建之后也不会被改变。

容器(Container)

镜像和容器的关系,就像是面向对象程序设计中的类和实例一样,镜像是静态的定义,容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

命名空间(Namespace)

命名空间是一种在多个用户之间划分资源的方法。当你的项目和人员众多的时候可以考虑根据项目属性,例如生产、测试、开发划分不同的namespace。

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

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

图2 使用Label组织的Pod

无状态负载(Deployment)

Deployment是Pod Controller的一种。

一个Deployment可以包含一个或多个Pod,每个Pod的角色相同,所以系统会自动为Deployment的多个Pod分发请求。Deployment中的所有Pod共享存储卷。

使用Deployment时,您只需要在Deployment中描述您想要的目标状态是什么,Deployment就会帮您将Pod的状态改变到目标状态。

详细信息请参见Deployment

短时任务(Job)

Job是用来控制批处理型任务的资源对象。批处理业务与长期伺服业务(Deployment)的主要区别是批处理业务的运行有头有尾,而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。

Job的这种用完即停止的特性特别适合一次性任务,比如持续集成,配合云容器实例按秒计费,真正意义上做到按需使用、按需付费。

详细信息请参见Job

定时任务(CronJob)

定时任务是基于时间控制的短时任务(Job),类似于Linux系统的crontab文件中的一行,在指定的时间周期运行指定的短时任务。

详细信息请参见CronJob

服务(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

Secret

Secret是Kubernetes中一种加密存储的资源对象,用户可以将认证信息、证书、私钥等保存在密钥中,在容器启动时以环境变量等方式加载到容器中。

详细信息请参见Secret