Kubernetes 文档 / 概念 / 工作负载 / Pod / Init 容器

此文档从 Kubernetes 官网摘录
中文地址
 英文地址

本页提供了 Init 容器的概览。Init 容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。

你可以在 Pod 的规约中与用来描述应用容器的 containers 数组平行的位置指定 Init 容器。

在 Kubernetes 中，边车容器是在主应用容器之前启动并持续运行的容器。本文介绍 Init 容器：在 Pod 初始化期间完成运行的容器

理解 Init 容器

每个 Pod 中可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

Init 容器与普通的容器非常像，除了如下两点：

它们总是运行到完成。
每个都必须在下一个启动之前成功完成。

如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 "Never"，并且 Pod 的 Init 容器失败，则 Kubernetes 会将整个 Pod 状态设置为失败。

为 Pod 设置 Init 容器需要在 Pod 规约中添加 initContainers 字段，该字段以 Container 类型对象数组的形式组织，和应用的 containers 数组同级相邻。

Init 容器的状态在 status.initContainerStatuses 字段中以容器状态数组的格式返回（类似 status.containerStatuses 字段）。

与普通容器的不同之处

常规的 Init 容器（即不包括边车容器）不支持 lifecycle、livenessProbe、readinessProbe 或 startupProbe 字段。Init 容器必须在 Pod 准备就绪之前完成运行；而边车容器在 Pod 的生命周期内继续运行，它支持一些探针。有关边车容器的细节请参阅边车容器。

如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行

与边车容器的不同之处

Init 容器在主应用容器启动之前运行并完成其任务。与边车容器不同， Init 容器不会持续与主容器一起运行。

Init 容器按顺序完成运行，等到所有 Init 容器成功完成之后，主容器才会启动。

Init 容器不支持 lifecycle、livenessProbe、readinessProbe 或 startupProbe，而边车容器支持所有这些探针以控制其生命周期。

Init 容器与主应用容器共享资源（CPU、内存、网络），但不直接与主应用容器进行交互。不过这些容器可以使用共享卷进行数据交换。

使用 Init 容器

因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
与同一 Pod 中的多个应用容器相比，Init 容器能以不同的文件系统视图运行。因此，Init 容器可以被赋予访问应用容器不能访问的 Secret 的权限。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod 内的所有的应用容器会并行启动。
Init 容器可以安全地运行实用程序或自定义代码，而在其他方式下运行这些实用程序或自定义代码可能会降低应用容器镜像的安全性。通过将不必要的工具分开，你可以限制应用容器镜像的被攻击范围。

示例

等待一个 Service 完成创建，通过类似如下 Shell 命令：

bash 复制代码

for i in {1..100}; do sleep 1; if nslookup myservice; then exit 0; fi; done; exit 1

注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下：

bash 复制代码

curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'

在启动应用容器之前等一段时间，使用类似命令：

bash 复制代码

sleep 60

克隆 Git 仓库到卷中
将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主应用配置文件。

使用 Init 容器的情况

下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。第一个等待 myservice 启动，第二个等待 mydb 启动。一旦这两个 Init 容器都启动完成，Pod 将启动 spec 节中的应用容器。

myapp.yaml

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

services.yaml

yaml 复制代码

---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

具体行为

每个 Init 容器成功退出后才会启动下一个 Init 容器。如果某容器因为容器运行时的原因无法启动，或以错误状态退出，kubelet 会根据 Pod 的 restartPolicy 策略进行重试。然而，如果 Pod 的 restartPolicy 设置为 "Always"，Init 容器失败时会使用 restartPolicy 的 "OnFailure" 策略。

如果 Pod 重启，所有 Init 容器必须重新执行。

对 Init 容器规约的修改仅限于容器的 image 字段。更改 Init 容器的 image 字段，等同于重启该 Pod。

因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。特别地，基于 emptyDirs 写文件的代码，应该对输出文件可能已经存在做好准备.

容器内的资源共享

在给定的 Init、边车和应用容器执行顺序下，资源使用适用于如下规则：

所有 Init 容器上定义的任何特定资源的 limit 或 request 的最大值，作为 Pod 有效初始 request/limit。如果任何资源没有指定资源限制，这被视为最高限制。
Pod 对资源的有效 limit/request 是如下两者中的较大者：
- 所有应用容器对某个资源的 limit/request 之和
- 对某个资源的有效初始 limit/request
基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源，这些资源在 Pod 生命周期过程中并没有被使用。
Pod 的有效 QoS 层，与 Init 容器和应用容器的一样。

配额和限制适用于有效 Pod 的请求和限制值。

Init 容器和 Linux cgroup

在 Linux 上，Pod 级别的 CGroup 资源分配基于 Pod 的有效请求和限制值，与调度程序相同。

Pod 重启的原因

Pod 重启会导致 Init 容器重新执行，主要有如下几个原因：

Pod 的基础设施容器 (译者注：如 pause 容器) 被重启。这种情况不多见，必须由具备 root 权限访问节点的人员来完成。
当 restartPolicy 设置为 Always，Pod 中所有容器会终止而强制重启。由于垃圾回收机制的原因， Init 容器的完成记录将会丢失。