K8S-特殊容器文章目录K8S-特殊容器一、init初始化容器1、init初始化概述1.1、Init容器与普通容器区别1.2、Init容器的优势1.3、Init容器应用场景2、Init容器使用案例3、init初始化容器说明二、临时容器 Ephemeral Containers1、概述2、用途3、使用临时容器一、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 注册到一个中央数据库、配置中心Nacos等。2、Init容器使用案例[rootk8s-master01 ~]# cat init-test.yamlapiVersion: v1# 核心 API 组Pod 属于核心资源kind: Pod# 资源类型Podmetadata:# 元数据开始name: init-demo# Pod 名称用于标识labels:# Pod 标签demo: init-demo# 标签键值对用于选择器匹配spec:# Pod 规格开始containers:# 主容器列表主应用容器- name: init-demo# 主容器名称image: busybox:1.28# 使用 busybox 镜像imagePullPolicy: IfNotPresent# 镜像拉取策略本地有则不拉取command:[sh,-c,echo The app is running! sleep 3600]# 启动命令输出信息并睡眠1小时initContainers:# 初始化容器列表在主容器启动前按顺序执行- name: init-demo1# 第一个初始化容器名称image: busybox:1.28# 使用 busybox 镜像imagePullPolicy: IfNotPresent# 镜像拉取策略本地有则不拉取command:[sh,-c,until nslookup myservice; do echo waiting for myservice; sleep 2; done;]# 循环检测 myservice DNS 解析直到成功- name: init-demo2# 第二个初始化容器名称image: busybox:1.28# 使用 busybox 镜像imagePullPolicy: IfNotPresent# 镜像拉取策略本地有则不拉取command:[sh,-c,until nslookup mysql; do echo waiting for mysql; sleep 2; done;]# 循环检测 mysql DNS 解析直到成功--- apiVersion: v1# 核心 API 组Service 属于核心资源kind: Service# 资源类型Service服务metadata:# 元数据开始name: myservice# Service 名称用于其他资源如 Pod通过名称访问spec:# Service 规格开始ports:# 端口映射列表- port:5566# Service 对外暴露的端口其他 Pod 或集群内部访问时使用的端口targetPort:6655# 流量转发到后端 Pod 的目标端口Pod 实际监听的端口protocol: TCP# 使用的网络协议TCP / UDP--- apiVersion: v1# 核心 API 组Service 属于核心资源kind: Service# 资源类型Service服务metadata:# 元数据开始name: mysql# Service 名称用于其他资源通过名称访问如 mysql:8899spec:# Service 规格开始ports:# 端口映射列表- port:8899# Service 对外暴露的端口集群内访问时使用的端口targetPort:9988# 流量转发到后端 Pod 的目标端口后端 Pod 实际监听的端口protocol: TCP# 使用的网络协议TCP / UDP##验证[rootk8s-master01 ~]# kubectl get podsNAME READY STATUS RESTARTS AGE init-demo0/1 Init:0/206s[rootk8s-master01 ~]# kubectl get podsNAME READY STATUS RESTARTS AGE init-demo1/1 Running04m24s[rootk8s-master01 ~]# kubectl get serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE kubernetes ClusterIP10.10.0.1none443/TCP 13m myservice ClusterIP10.10.202.229none5566/TCP 40s mysql ClusterIP10.10.222.227none8899/TCP 39s[rootk8s-master01 ~]# kubectl logs init-demo -c init-demo13、init初始化容器说明在Pod启动过程中Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出如果由于运行时或失败退出将导致容器启动失败它会根据 PodrestartPolicy指定的策略进行重试。然而如果Pod的restartPolicy设置为AlwaysInit容器失败时会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 Containers1、概述临时容器与其他容器的不同之处在于它们缺少对资源或执行的保证并且永远不会自动重启因此不适用于构建应用程序。临时容器使用与常规容器相同的 Container.Spec字段进行描述但许多字段是不允许使用的。临时容器没有端口配置因此像 portslivenessProbereadinessProbe 这样的字段是不允许的。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[rootk8s-master01 ~]# vim pod-nginx.yamlapiVersion: v1# 核心 API 组Pod 属于核心资源kind: Pod# 资源类型Podmetadata:# 元数据开始name: nginx-test# Pod 名称用于标识namespace: default# Pod 所在的命名空间默认命名空间labels:# Pod 标签用于选择器匹配app: nginx# 标签键值对appnginxspec:# Pod 规格开始containers:# 容器列表- name: nginx# 容器名称ports:# 容器端口声明说明性不强制创建规则- containerPort:80# 容器监听的端口80image: nginx# 使用 nginx 官方镜像imagePullPolicy: IfNotPresent# 镜像拉取策略本地存在则不拉取##提交[rootk8s-master01 ~]# kubectl apply -f pod-nginx.yaml##查看[rootk8s-master01 ~]# kubectl get pod pod-nginx.yaml创建临时容器[rootk8s-master01 ~]# kubectl debug -it nginx-test --imagebusybox:1.28 --targetnginxDefaulting debug container name to debugger-6m2s8. If you dont see acommandprompt, try pressing enter. /#ps -ef | grep nginx查看nginx-test这个pod是否已经有临时容器[rootk8s-master01 ~]# kubectl describe pods nginx-test2s8.If you don’t see a command prompt, try pressing enter./ #ps -ef | grep nginx查看nginx-test这个pod是否已经有临时容器 shell [rootk8s-master01 ~]# kubectl describe pods nginx-test