Kubernetes init container

目录

• 简介
• 配置
• init container与应用容器的区别

简介

在很多应用场景中，应用在启动之前都需要进行如下初始化操作：

• 等待其他关联组件正确运行（例如数据库或某个后台服务）
• 基于环境变量或配置模板生成配置文件
• 从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中
• 下载相关依赖包，或者对系统进行一些预配置操作

kubernetes v1.3引入了一些alpha版本的新特性init container（在v1.5版本时被更新为beta版本），用于在启动应用容器之前 启动一个或多个“初始化”容器，完成应用容器所需的预置条件。init container与应用容器本质上是一样的，但它们是仅运行一次就结束的任务，并且必须在成功执行完成后，系统才能继续执行下一个容器。根据pod的重启策略，当init container执行失败，在设置了RestartPolicy=Never时，pod将自动启动失败；而设置RestartPolicy=Always时，Pod将会被系统自动重启。

配置

下面以一个nginx应用为例，在启动nginx之前，通过初始化容器busybox为nginx创建一个index.html的主页文件。这里为init container和nginx设置了一个共享的volume，以供nginx访问init container设置的index.html文件：

nginx-init-containers.yaml内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  annotations:
spec:
  initContainers:
  - name: install
    image: busybox
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - "http://kubernetes.io"
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  containers:
  - name: workdir
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  dnsPolicy: Default
    volumes:
    - name: workdir
      emptyDir: {}

init container与应用容器的区别

简单的说明一下两者的区别：

• init container的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后，kubernetes才会初始化pod的各种信息，并开始创建和运行应用容器。
• 在init container的定义中也可以设置资源限制、volume的使用和安全策略等等。但资源限制的设置与应用容器不同：
  • 如果多个init container都定义了资源请求/资源限制，则取最大的值作为所有init container的资源请求值/资源限制值。
  • pod的有效资源请求值/资源限制值取以下二者中的较大值：
    • 所有应用容器的资源请求值/限制值之和
    • init container的有效资源请求值/限制值
  • 调度算法将基于pod的有效资源请求值/限制值进行计算，也就是说init container可以为初始化操作预留系统资源，即使后续应用容器无须使用这些资源。
  • pod的有效QoS等级适用于init container和应用容器。
  • 资源配额和限制将根据pod的有效资源请求/限制，与调度机制一致。
• init container不能设置readinessProbe探针，因为必须在它们成功运行以后才能继续运行pod中定义的普通容器。将pod重启时，init container将会重新运行，常见的pod重启场景如下：
  • init container的镜像被更新时，init container将重新运行，导致pod重启，仅更新应用容器的镜像只会使得应用容器被重启。
  • pod的infrastructure容器更新时，pod将会重启。
  • 或pod中的所有应用容器都终止了，并且RestartPolicy=Always时，则pod将会重启。