4-初始化容器（Init_Container）

概述

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

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

init_container的作用

用于在启动应用容器（app container）之前启动一个或多个初始化容器，完成应用容器所需的预置条件

init容器与普通容器的不同

• init容器必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建和运行应用容器

• 在init container的定义中也可以设置资源限制、Volume的使用和安全策略，等等。但资源限制的设置与应用容器略有不同。

• 如果多个init container都定义了资源请求/资源限制，则取最大的值作为所有init container的资源请求值/资源限制值。

• Pod的有效（effective）资源请求值/资源限制值取以下二者中的较大值。
      * 所有应用容器的资源请求值/资源限制值之和。
      * init container的有效资源请求值/资源限制值。

• 调度算法将基于Pod的有效资源请求值/资源限制值进行计算，也就是说init container可以为初始化操作预留系统资源，即使后续应用容器无须使用这些资源。

• Pod的有效QoS等级适用于init container和应用容器。

• 资源配额和限制将根据Pod的有效资源请求值/资源限制值计算生效。

• Pod级别的cgroup将基于Pod的有效资源请求/限制，与调度机制一致。

• init container不能设置readinessProbe探针，因为必须在它们成功运行后才能继续运行在Pod中定义的普通容器

特殊说明

1.在pod启动过程中，init C会按照顺序在网络和数据卷初始化之后启动，pause容器用来初始化网络和数据卷，第一个init C启动完成并成功退出后才能启动第二个init C
2.如果init C由于运行或失败退出，将导致容器启动失败，它会根据pod的redtartpolicy指定的策略进行重试
3.在所有的init C没有成功之前，pod将不会变成ready状态，init C的端口将会不在serverce的调度队列中出现，正在初始化中的pod处于pending状态，但会将initializing状态设置为true
4.如果pod重启，所有的init C必须重新执行
5.修改init容器的image字段，会重启该pod。修改其他字段都不会生效，
6.init C具有应用容器的所有字段，除了readness 和liveness 有了也不生效
7.在pod中每个app和init容器的名称必须唯一，不可重复，否则报错

因为init容器具有与应用程序容器分离的单独镜像，所以有如下优势

1. 自定义初始化。init 容器中可以包含并运行一些实用的工具，但是出于安全考虑，不建议在应用程序镜像中包含这些实用工具，
   即，如果我们在主容器启动之前有一些文件被创建，有一些数据要被梳理，但是如果把这些工具放到main C中，又会造成main C的冗余，随着工具的增多稳定性也得不到保障，所以，把这些工具写到init C 中，让他在初始化过程中把main C 需要的文件创建出来
2. 他们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中，例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed awk python这样的工具         没懂
3. 角色分离。应用程序镜像可以分离出创建和部署两个角色，创建这个角色归属于init C 部署这个角色归属于main C
4. 权限隔离。init容器使用linux namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此。他们能够具有访问secret的权限，而应用程序容器则不能
   例如，有一些处于高权限目录的文件，这些文件是main C需要的，但是main C没有权限访问该目录，所以将权限赋予init C ，让init C将文件写入到main C
5. 顺序启动。因为init C必须在应用容器启动之前运行完成，而应用容器是并行启动的，所以initC能够提供一种简单的阻塞或延迟应用程序启动的方法

init容器应用示例

示例环境说明

假如Pod中运行着apache和mysql两个容器，如果apache启动快于mysql，就会出现apache连不上mysql，pod就会重启，可能会出现apache的启动一致快于mysql，pod一直重启的现象，所以，在apache容器处添加init探测mysql是否正常，如果正常就启动apache

示例逻辑说明

示例中 main C 是 myapp-container ，init C有两个init-myservice和init-mydb，main C 执行后输出"the app is runnting"。init-myservice 执行后解析myservice解析不成功输出"waiting for myservice"然后继续解析，直到解析成功。init-mydb执行后解析mydb解析不成功输出"waiting for mydb"然后继续解析，直到解析成功。until 条件为真退出循环。

vim ini-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod1
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waitind for mydb; sleep 2; done;']

因为还没创建，所以会报错，用如下模板创建svc
vim mysvc.yaml

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

vim mydb,yaml

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

根容器（Pause Container）

作用就是占用一个Linux的network namespace