容器

每个运行的容器都是可重复的；包含依赖环境在内的标准，意味着无论您在哪里运行它，您都会得到相同的行为。
容器将应用程序从底层的主机设施中解耦。这使得在不同的云或 OS 环境中部署更加容易。

一、容器镜像

容器镜像是一个随时可以运行的软件包，包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。
根据设计，容器是不可变的：你不能更改已经运行的容器的代码。如果有一个容器化的应用程序需要修改，则需要构建包含更改的新镜像，然后再基于新构建的镜像重新运行容器。

容器镜像（Image）所承载的是封装了应用程序及其所有软件依赖的二进制数据。容器镜像是可执行的软件包，可以单独运行；该软件包对所处的运行时环境具有良定（Well Defined）的假定。
你通常会创建应用的容器镜像并将其推送到某仓库，然后在 Pod 中引用它。

1.1 镜像名称

容器镜像通常会被赋予 pause、example/mycontainer 或者 kube-apiserver 这类的名称。镜像名称也可以包含所在仓库的主机名。例如：fictional.registry.example/imagename。还可以包含仓库的端口号，例如：fictional.registry.example:10443/imagename。

如果你不指定仓库的主机名，Kubernetes 认为你在使用 Docker 公共仓库。

在镜像名称之后，你可以添加一个标签（Tag）（就像在 docker 或 podman 中也在用的那样）。使用标签能让你辨识同一镜像序列中的不同版本。

镜像标签可以包含小写字母、大写字符、数字、下划线（）、句点（.）和连字符（-）。关于在镜像标签中何处可以使用分隔字符（、- 和 .）还有一些额外的规则。如果你不指定标签，Kubernetes 认为你想使用标签 latest。

1.2 更新镜像

默认的镜像拉取策略是 IfNotPresent：在镜像已经存在的情况下， kubelet 将不再去拉取镜像。如果希望强制总是拉取镜像，你可以执行以下操作之一：

设置容器的 imagePullPolicy 为 Always。
省略 imagePullPolicy，并使用 :latest 作为要使用的镜像的标签。
省略 imagePullPolicy 和要使用的镜像标签。
启用 AlwaysPullImages 准入控制器（Admission Controller）。

如果 imagePullPolicy 未被定义为特定的值，也会被设置为 Always。

1.3 带镜像索引的多架构镜像（arm或x86 CPU架构）

除了提供二进制的镜像之外，容器仓库也可以提供容器镜像索引。镜像索引可以根据特定于体系结构版本的容器指向镜像的多个镜像清单。这背后的理念是让你可以为镜像命名（例如：pause、example/mycontainer、kube-apiserver）的同时，允许不同的系统基于它们所使用的机器体系结构取回正确的二进制镜像。

Kubernetes 自身通常在命名容器镜像时添加后缀 -$(ARCH)。为了向前兼容，请在生成较老的镜像时也提供后缀。这里的理念是为某镜像（如 pause）生成针对所有平台都适用的清单时，生成 pause-amd64 这类镜像，以便较老的配置文件或者将镜像后缀影编码到其中的 YAML 文件也能兼容。

1.4 使用私有仓库

从私有仓库读取镜像时可能需要密钥。凭证可以用以下方式提供:

配置节点向私有仓库进行身份验证
- 所有 Pod 均可读取任何已配置的私有仓库
- 需要集群管理员配置节点
预拉镜像
- 所有 Pod 都可以使用节点上缓存的所有镜像
- 需要所有节点的 root 访问权限才能进行设置
在 Pod 中设置 ImagePullSecrets
- 只有提供自己密钥的 Pod 才能访问私有仓库
特定于厂商的扩展或者本地扩展
- 如果你在使用定制的节点配置，你（或者云平台提供商）可以实现让节点向容器仓库认证的机制

具体如何配置参见文档https://kubernetes.io/zh/docs/concepts/containers/images/

二、容器环境

Kubernetes 的容器环境给容器提供了几个重要的资源：

文件系统，其中包含一个镜像和一个或多个的卷
容器自身的信息
集群中其他对象的信息

2.1 容器信息

容器的 hostname 是它所运行在的 pod 的名称。它可以通过 hostname 命令或者调用 libc 中的 gethostname 函数来获取。

Pod 名称和命名空间可以通过下行 API 转换为环境变量。

Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 Docker 镜像中静态指定的任何环境变量一样。

2.2 集群信息

创建容器时正在运行的所有服务的列表都可用作该容器的环境变量。这些环境变量与 Docker 链接的语法匹配。

对于名为 foo 的服务，当映射到名为 bar 的容器时，以下变量是被定义了的：

FOO_SERVICE_HOST=
FOO_SERVICE_PORT=

服务具有专用的 IP 地址。如果启用了 DNS插件，可以在容器中通过 DNS 来访问服务。

三、容器运行时

容器运行环境是负责运行容器的软件。
Kubernetes 支持多个容器运行环境: Docker、 containerd、CRI-O 以及任何实现 Kubernetes CRI (容器运行环境接口)。

容器运行时类（Runtime Class）
RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器。

你可以在不同的 Pod 设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。例如，如果你的部分工作负载需要高级别的信息安全保证，你可以决定在调度这些 Pod 时尽量使它们在使用硬件虚拟化的容器运行时中运行。这样，你将从这些不同运行时所提供的额外隔离中获益，代价是一些额外的开销。
你还可以使用 RuntimeClass 运行具有相同容器运行时但具有不同设置的 Pod。

设置方法

3.1. 在节点上配置 CRI 实现

RuntimeClass 的配置依赖于运行时接口（CRI）的实现。根据你使用的 CRI 实现，查阅相关的文档（下方）来了解如何配置。

说明： RuntimeClass 假设集群中的节点配置是同构的（换言之，所有的节点在容器运行时方面的配置是相同的）。如果需要支持异构节点，配置方法请参阅下面的调度。

所有这些配置都具有相应的 handler 名，并被 RuntimeClass 引用。 handler 必须符合 DNS-1123 命名规范（字母、数字、或 -）。

3.2. 创建相应的 RuntimeClass 资源

在上面步骤 1 中，每个配置都需要有一个用于标识配置的 handler。针对每个 handler 需要创建一个 RuntimeClass 对象。

RuntimeClass 资源当前只有两个重要的字段：RuntimeClass 名 (metadata.name) 和 handler (handler)。对象定义如下所示：

apiVersion: node.k8s.io/v1  # RuntimeClass 定义于 node.k8s.io API 组
kind: RuntimeClass
metadata:
  name: myclass  # 用来引用 RuntimeClass 的名字
  # RuntimeClass 是一个集群层面的资源
handler: myconfiguration  # 对应的 CRI 配置的名称

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler，那么 pod 将会进入 Failed 终止阶段。你可以查看相应的事件，获取出错信息。

如果未指定 runtimeClassName ，则将使用默认的 RuntimeHandler，相当于禁用 RuntimeClass 功能特性。

四、容器生命周期回调

类似于许多具有生命周期回调组件的编程语言框架，例如 Angular、Kubernetes 为容器提供了生命周期回调。回调使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期回调时运行在处理程序中实现的代码。

Kubernetes容器

容器