云原生 | Kubernetes - Init详解

目录

理论

试验

---

理论

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

• Init 容器总是运行到成功完成为止
• 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

如果Pod的Init失败，K8s会不断地重启该Pod，直到Init成功为止。但是如果Pod对应的 restartPolicy 为 Never ，将不会重新启动。

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

• 可以包含并运行实用工具，但是出于安全考虑，不建议在应用程序容器镜像中包含这些实用工具。
• 可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具。
• 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
• Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
• 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。

试验

手动添加了两个init（init.yaml）：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 360']
  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 waiting for mydb; sleep 2; done;']

kubectl apply -f init.yaml

此时的pod是起不来的，他会在init时一直循环去 nslookup myservice ，但是我们还没有去创建：

创建svc（myservice.yaml）：

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

kubectl create -f myservice.yaml

Pod会去找dns，问他有没有这里的 myservice ： 

继续（mydb.yaml）：

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

kubectl create -f mydb.yaml

试验成功：

其它说明

• 在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动（pause容器）。每个容器必须在下一个容器启动之前成功退出
• 如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略
• 在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true
• 如果Pod重启，所有Init容器必须重新执行
• 对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod
• Init容器具有应用容器的所有字段。除了readinessProbe，因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
• 在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误