InitContainer理解正确的有

InitContainer理解正确的有
A. InitContainer先于普通容器启动执行
B. 多个InitContainer的执行是按定义次序串行执行，而多个普通容器是并行执行
C. InitContainer执行成功后就结束退出，而普通容器可以一直执行
D. Pod重启时，InitContainer会再次执行

选择ABCD

InitContainer是一种特殊的容器，‌它在Pod中的应用容器启动之前运行。‌InitContainer与普通容器类似，‌但有以下几点主要区别：‌

运行方式：‌InitContainer必须先于应用容器执行完成，‌当设置了多个InitContainer时，‌它们会按顺序逐个运行，‌并且只有前一个InitContainer运行成功后才能运行下一个。‌当所有InitContainer都成功运行后，‌Kubernetes才会初始化Pod的各种信息，‌并开始创建和运行应用容器。‌
状态：‌InitContainer总是运行到完成，‌如果成功完成，‌Kubernetes会继续启动应用容器；‌如果失败，‌Kubernetes会不断地重启该Pod，‌直到InitContainer成功为止。‌但是，‌如果Pod的restartPolicy值为Never，‌它不会重新启动。‌
资源管理：‌InitContainer支持应用容器的全部字段和特性，‌包括资源限制、‌数据卷和安全设置。‌然而，‌对资源请求和限制的处理与普通容器略有不同。‌例如，‌如果多个InitContainer都定义了资源请求或资源限制，‌则取最大的值作为所有InitContainer的资源请求值或资源限制值。‌Pod的有效资源请求值或资源限制值取所有应用容器与InitContainer中的较大值。‌这允许为初始化操作预留系统资源，‌即使后续应用容器无须使用这些资源。‌
通过这些特性，‌InitContainer在Kubernetes中扮演着重要的角色，‌尤其是在需要执行一些预安装、‌配置或初始化任务时，‌如设置环境、‌准备数据等。‌它们可以确保应用容器在一个准备好的环境中运行，‌从而提高应用的稳定性和性能。‌

InitContainer与普通容器的不同之处
InitContainer 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同。
同时 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时，Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。

注意事项
Pod重启,会导致initContainer重新执行，检测initContainer的操作or资源,以防重复操作or拉取

Pod 重启的原因
用户更新 Pod 的 Spec 导致 Init 容器镜像发生改变。Init 容器镜像的变更会引起 Pod 重启. 应用容器镜像的变更仅会重启应用容器。
Pod 的基础设施容器 (译者注：如 pause 容器) 被重启。 这种情况不多见，必须由具备 root 权限访问 Node 的人员来完成。
当 restartPolicy 设置为 Always，Pod 中所有容器会终止而强制重启，由于垃圾收集导致 Init 容器的完成记录丢失。你可以在Pod的规格信息中与containers数组同级的位置指定 Init 容器。

在Pod上使用activeDeadlineSeconds，在容器上使用livenessProbe，这样能够避免Init容器一直失败,这就为Init容器活跃设置了一个期限。在Pod中的每个app和Init容器的名称必须唯一，与任何其它容器共享同一个名称，会在验证时抛出错误。
在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。如果由于运行时或失败退出，导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试，在所有的Init容器没有成功之前，
Pod将不会变成Ready状态，如果Pod重启，所有Init容器必须重新执行。
因为Init容器可能会被重启、重试或者重新执行，所以Init容器的代码应该是幂等的（即任意多次执行所产生的影响与一次执行的影响相同）。特别地，被写到EmptyDirs中文件的代码，应该对输出文件可能已经存在做好准备。