K8S-特殊容器 - 技术栈

一、init初始化容器

1、init初始化概述

Init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行 ，只有所有的Init Container执行完后，主容器才会被启动。一个Pod里面的所有容器是共享数据卷和网络命名空间的，所以Init Container里面产生的数据可以被主容器使用到的。

Init Container和之前的钩子函数有点类似，只是是在容器执行前来做一些工作，从直观的角度看上去的话，初始化容器的确有点像PreStart，但是钩子函数和我们的InitContainer是处在不同的阶段的，我们可以通过下面的图来了解：

从上面这张图我们可以直观的看到PostStart和PreStop包括liveness和readiness是属于主容器的生命周期范围内的，而Init Container是独立于主容器之外的，当然他们都属于Pod的生命周期范畴之内的。

另外我们可以看到上面我们的Pod右边还有一个infra的容器，我们可以在集群环境中去查看下任意一个Pod对应的运行的Docker容器，可以发现每一个Pod下面都包含了一个pause-amd64的镜像，这个就是我们的infra镜像，我们知道Pod下面的所有容器是共享同一个网络命名空间的，这个镜像就是来做这个事情的，所以每一个Pod当中都会包含一个这个镜像。很多 Pod 启动不起来就是因为这个 infra 镜像没有被拉下来，所以需要提前拉取到节点上面。

1.1、Init容器与普通容器区别

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

如果Pod的Init容器失败，Kubenetes会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的restartPolicy为Never，它不会重新启动

1.2、Init容器的优势

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

1.3、Init容器应用场景

等待其他模块Ready：可以用来解决服务之间的依赖问题，比如我们有一个 Web服务，该服务又依赖于另外一个数据库服务，但是在我们启动这个 Web服务的时候我们并不能保证依赖的这个数据库服务就已经启动起来了，所以可能会出现一段时间内 Web服务连接数据库异常。要解决这个问题的话我们就可以在 Web 服务的 Pod 中使用一个init Container，在这个初始化容器中去检查数据库是否已经准备好了，准备好了过后初始化容器就结束退出，然后我们的主容器 Web服务被启动起来，这个时候去连接数据库就不会有问题了。
做初始化配置：比如集群里检测所有已经存在的成员节点，为主容器准备好集群的配置信息，这样主容器起来后就能用这个配置信息加入集群。
其它场景：如将 pod 注册到一个中央数据库、配置中心等。

2、Init容器使用案例

$root@k8s-master01 \~\]# cat init-test.yaml apiVersion: v1 kind: Pod metadata: name: init-demo labels: demo: init-demo spec: containers: - name: init-demo image: busybox:1.28 imagePullPolicy: IfNotPresent command: \['sh', '-c', 'echo The app is running! \&\& sleep 3600'$
initContainers:

name: init-demo1
image: busybox:1.28
imagePullPolicy: IfNotPresent
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice;sleep 2; done;']

name: init-demo2
image: busybox:1.28
imagePullPolicy: IfNotPresent
command: ['sh', '-c', 'until nslookup mysql; do echo waiting for mysql; sleep 2;done;']

apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:

port: 5566
targetPort: 6655
protocol: TCP

apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:

port: 8899
targetPort: 9988
protocol: TCP
##验证

$root@k8s-master01 \~\]# kubectl get pods NAME READY STATUS RESTARTS AGE init-demo 0/1 Init:0/2 0 6s \[root@k8s-master01 \~\]# kubectl get pods NAME READY STATUS RESTARTS AGE init-demo 1/1 Running 0 4m24s \[root@k8s-master01 \~\]# kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.10.0.1 \ 443/TCP 13m myservice ClusterIP 10.10.202.229 \ 5566/TCP 40s mysql ClusterIP 10.10.222.227 \ 8899/TCP 39s \[root@k8s-master01 \~\]# kubectl logs init-demo -c init-demo1$

3、init初始化容器说明

在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出
如果由于运行时或失败退出，将导致容器启动失败，它会根据 PodrestartPolicy指定的策略进行重试。然而，如果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容器名称必须唯一；与任何其他容器共享同一个名称，会在验证时抛出错误。

二、临时容器 Ephemeral Containers

1、概述

临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启，因此不适用于构建应用程序。临时容器使用与常规容器相同的 Container.Spec字段进行描述，但许多字段是不允许使用的。

临时容器没有端口配置，因此像 ports，livenessProbe，readinessProbe 这样的字段是不允许的。
Pod 资源分配是不可变的，因此 resources 配置是不允许的。

临时容器是使用 API 中的一种特殊的 ephemeralcontainers处理器进行创建的，而不是直接添加到 pod.spec段，因此无法使用 kubectl edit来添加一个临时容器。

与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器。

2、用途

当由于容器崩溃或容器镜像不包含调试工具而导致 kubectl exec 无用时，临时容器对于交互式故障排查很有用。
尤其是，Distroless 镜像允许用户部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。由于 distroless镜像不包含 Shell 或任何的调试工具，因此很难单独使用 kubectl exec 命令进行故障排查。
使用临时容器时，启用进程名称空间共享 很有帮助，可以查看其他容器中的进程。

什么是distroless镜像

K8s distroless 是一个 Kubernetes 发行版，它专注于提供轻量级的 Kubernetes 环境，删除了许多默认的工具和组件，以减小 Kubernetes 的存储空间和资源占用。

K8s distroless 使用 Go 语言编写，并使用原生 Kubernetes API 进行集群管理。它删除了许多 Kubernetes 中的默认工具，例如 kubectl、kube-proxy、kubelet 等，并提供了自己的命令行工具来管理集群。

K8s distroless 的主要特点包括：

轻量化：K8s distroless 删除了许多默认的工具和组件，以减小 Kubernetes 的存储空间和资源占用。
易于部署：K8s distroless 可以轻松地在各种平台上部署，包括云端、本地和容器环境中。
高效能：K8s distroless 使用原生 Kubernetes API 进行集群管理，提供了高效的资源利用和管理。
安全性：K8s distroless 提供了高度的安全性，包括自动更新、自动补丁和严格的安全策略。

K8s distroless 适合那些想要使用 Kubernetes 进行容器编排，但不想安装大量默认工具和组件的用户。它提供了一种简单、高效和安全的 Kubernetes 解决方案。

3、使用临时容器

创建一个部署nginx的pod

$root@k8s-master01 \~\]# cat pod-nginx.yaml apiVersion: v1 kind: Pod metadata: name: nginx-test namespace: default labels: app: nginx spec: containers: - name: nginx ports: - containerPort: 80 image: nginx imagePullPolicy: IfNotPresent ##提交 \[root@k8s-master01 \~\]# kubectl apply -f pod-nginx.yaml ##查看 \[root@k8s-master01 \~\]# kubectl get pod pod-nginx.yaml$

创建临时容器

$root@k8s-master01 \~\]# kubectl debug -it nginx-test --image=busybox:1.28 --target=nginx Defaulting debug container name to debugger-6m2s8. If you don't see a command prompt, try pressing enter. / #ps -ef \| grep nginx$

查看nginx-test这个pod是否已经有临时容器

$root@k8s-master01 \~\]# kubectl describe pods nginx-test$