免费发布网页的网站,哪些网站才能具备完整的八项网络营销功能,wordpress 昵称留链接,好男人社区Init 容器
v ljx97609760 一起沟通学习
Init 容器是一种特殊容器#xff0c;在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本
理解 Init 容器
每个 Pod 中可以包含多个容器#xff0c; 应用运行在这些容器里面#xff0c;…Init 容器
v ljx97609760 一起沟通学习
Init 容器是一种特殊容器在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本
理解 Init 容器
每个 Pod 中可以包含多个容器 应用运行在这些容器里面同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像除了如下两点
它们总是运行到完成每个都必须在下一个启动之前成功完成
如果 Pod 的 Init 容器失败kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而如果 Pod 对应的 restartPolicy 值为 “Never”并且 Pod 的 Init 容器失败 则 Kubernetes 会将整个 Pod 状态设置为失败。
为 Pod 设置 Init 容器需要在 Pod 规约中添加 initContainers 字段 该字段以 Container 类型对象数组的形式组织和应用的 containers 数组同级相邻。 参阅 API 参考的容器章节了解详情 Init 容器的状态在 status.initContainerStatuses 字段中以容器状态数组的格式返回 类似 status.containerStatuses 字段
与普通容器的不同之处
Init 容器支持应用容器的全部字段和特性包括资源限制、 数据卷和安全设置。 然而Init 容器对资源请求和限制的处理稍有不同在下面资源节有说明
同时 Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe 因为它们必须在 Pod 就绪之前运行完成
如果为一个 Pod 指定了多个 Init 容器这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功下一个才能够运行。当所有的 Init 容器运行完成时 Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行
使用 Init 容器
因为 Init 容器具有与应用容器分离的单独镜像其启动相关代码具有如下优势 Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像 应用镜像的创建者和部署者可以各自独立工作而没有必要联合构建一个单独的应用镜像 与同一 Pod 中的多个应用容器相比Init 容器能以不同的文件系统视图运行。因此Init 容器可以被赋予访问应用容器不能访问的 Secret 的权限 由于 Init 容器必须在应用容器启动之前运行完成因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动直到满足了一组先决条件。 一旦前置条件满足Pod 内的所有的应用容器会并行启动 Init 容器可以安全地运行实用程序或自定义代码而在其他方式下运行这些实用程序或自定义代码可能会降低应用容器镜像的安全性。 通过将不必要的工具分开你可以限制应用容器镜像的被攻击范围
例子
下面是一些如何使用 Init 容器的想法
等待一个 Service 完成创建通过类似如下 Shell 命令
for i in {1..100}; do sleep 1; if nslookup myservice; then exit 0; fi; done; exit 1注册这个 Pod 到远程服务器通过在命令中调用 API类似如下
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d instance$(POD_NAME)ip$(POD_IP)在启动应用容器之前等一段时间使用类似命令
sleep 60克隆 Git 仓库到卷中将配置值放到配置文件中运行模板工具为主应用容器动态地生成配置文件。 例如在配置文件中存放 POD_IP 值并使用 Jinja 生成主应用配置文件
使用 Init 容器的情况
下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动 第二个等待 mydb 启动。 一旦这两个 Init 容器都启动完成Pod 将启动 spec 节中的应用容器
apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app.kubernetes.io/name: MyApp
spec:containers:- name: myapp-containerimage: busybox:1.28command: [sh, -c, echo The app is running! sleep 3600]initContainers:- name: init-myserviceimage: busybox:1.28command: [sh, -c, until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done]- name: init-mydbimage: busybox:1.28command: [sh, -c, until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done]通过运行下面的命令启动 Pod
kubectl apply -f myapp.yaml输出类似于
pod/myapp-pod created使用下面的命令检查其状态
kubectl get -f myapp.yaml输出类似于
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 6m如果要查看 Pod 内 Init 容器的日志请执行
kubectl logs myapp-pod -c init-myservice # 查看第一个 Init 容器
kubectl logs myapp-pod -c init-mydb # 查看第二个 Init 容器Init 容器将会等待至发现名称为 mydb 和 myservice 的服务。 如下为创建这些 Service 的配置文件
apiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377创建 mydb 和 myservice 服务的命令
kubectl apply -f services.yaml输出类似于
service/myservice created
service/mydb created这样你将能看到这些 Init 容器执行完毕随后 my-app 的 Pod 进入 Running 状态
kubectl get -f myapp.yaml输出类似于
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m具体行为
在 Pod 启动过程中每个 Init 容器会在网络和数据卷初始化之后按顺序启动。 kubelet 运行依据 Init 容器在 Pod 规约中的出现顺序依次运行之。
每个 Init 容器成功退出后才会启动下一个 Init 容器。 如果某容器因为容器运行时的原因无法启动或以错误状态退出kubelet 会根据 Pod 的 restartPolicy 策略进行重试。 然而如果 Pod 的 restartPolicy 设置为 “Always”Init 容器失败时会使用 restartPolicy 的 “OnFailure” 策略。
在所有的 Init 容器没有成功之前Pod 将不会变成 Ready 状态。 Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 Pending 状态 但会将状况 Initializing 设置为 false。
如果 Pod 重启所有 Init 容器必须重新执行。
对 Init 容器规约的修改仅限于容器的 image 字段。 更改 Init 容器的 image 字段等同于重启该 Pod。
因为 Init 容器可能会被重启、重试或者重新执行所以 Init 容器的代码应该是幂等的。 特别地基于 emptyDirs 写文件的代码应该对输出文件可能已经存在做好准备。
Init 容器具有应用容器的所有字段。然而 Kubernetes 禁止使用 readinessProbe 因为 Init 容器不能定义不同于完成态Completion的就绪态Readiness。 Kubernetes 会在校验时强制执行此检查。
在 Pod 上使用 activeDeadlineSeconds 和在容器上使用 livenessProbe 可以避免 Init 容器一直重复失败。 activeDeadlineSeconds 时间包含了 Init 容器启动的时间。 但建议仅在团队将其应用程序部署为 Job 时才使用 activeDeadlineSeconds 因为 activeDeadlineSeconds 在 Init 容器结束后仍有效果。 如果你设置了 activeDeadlineSeconds已经在正常运行的 Pod 会被杀死。
在 Pod 中的每个应用容器和 Init 容器的名称必须唯一 与任何其它容器共享同一个名称会在校验时抛出错误。
Pod 重启的原因
Pod 重启会导致 Init 容器重新执行主要有如下几个原因
Pod 的基础设施容器 (译者注如 pause 容器) 被重启这种情况不多见 必须由具备 root 权限访问节点的人员来完成当 restartPolicy 设置为 AlwaysPod 中所有容器会终止而强制重启。 由于垃圾回收机制的原因 Init 容器的完成记录将会丢失当 Init 容器的镜像发生改变或者 Init 容器的完成记录因为垃圾收集等原因被丢失时 Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本
