标签：debug sha pods 协同 功能 部署 安装过程 start 个性
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器，这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod中的所有容器是相对紧密的耦合在一起的，会被调度到同一个node节点上。如果选择容器作为k8s的最小可调度单元，那么容器的健康检测，多个耦合性强的容器的调度，多容器之间的资源共享就比较麻烦了。而使用Pod这个虚拟的最小可调度单元，可以完美解决如上问题。具体对比如下：
Pod
临时容器处于早期的 alpha 阶段，不适用于生产环境集群。一种特殊的容器，该容器在现有 Pod 中临时运行，以便完成用户发起的操作，例如故障排查。 你会使用临时容器来检查服务，而不是用它来构建应用程序。
目前，在k8s 1.18上没有成功使用此容器。具体参考文档见：https://kubernetes.io/zh/docs/concepts/workloads/pods/ephemeral-containers/
https://kubernetes.io/zh/docs/tasks/debug-application-cluster/debug-running-pod/
https://www.shogan.co.uk/kubernetes/enabling-and-using-ephemeral-containers-on-kubernetes-1-16/
https://kubernetes.io/zh/docs/tasks/configure-pod-container/share-process-namespace/
在主容器最小化容器镜像构建的基础上，主容器上会缺少很多排查问题的工具。故一旦主容器有问题需要排查，我们可以用临时容器在共享进程空间的基础上来排查问题。
Init 容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。每个 Pod 中可以包含多个容器， 应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe， 因为它们必须在 Pod 就绪之前运行完成。如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问 应用容器不能访问的 Secret 的权限。
在一个Pod中，某个Container运行主要业务的同时，需要另一个Container协同 ——这是一个常见的业务场景，这个协同Container通常称为Sidecar。 主要的Container在运行时，Sidecar需要已经就绪；而当主要的Container停止后，Sidecar也需要停止。
一般有紧密联系的容器会在同一个Pod中运行。目前，最新k8s官方的最新稳定版本还没有原生支持sidecar功能。
Pod中的主容器，主要来运行服务的主要业务逻辑
Pod 内容器的启动顺序按照：初始化容器->Sidecar 容器->业务容器
标签：debug sha pods 协同 功能 部署 安装过程 start 个性
原文地址：https://blog.51cto.com/leejia/2561518
