Kubernetes pod
Pod是Kubernetes中最小的单元，它由一组、一个或多个容器组成，它只是一个逻辑概念，每个pod中都包含一个pause容器；
Pod内的容器都是平等的关系，共享Network Namespace、共享文件；
pause容器的最主要的作用：创建共享的网络名称空间，以便于其它容器以平等的关系加入此网络名称空间；
pause进程是pod中所有容器的父进程（即第一个进程）；
initContainers：在正式运行的容器之前运行的初始化容器，一般用来做初始化使用的；
imagePullPolicy：镜像拉去策略；
command：容器启动执行的命令；
restartPolicy：重启策略；
nodeSelector：指定pod调度节点；
k8s中查看资源定义字段描述：
kubectl explain Pods
kubectl explain Pods.spec
容器的配置存活、就绪和启动探测器
https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
容器配置活跃（Liveness）
livenessProbe 周期性检测
许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。 Kubernetes 提供了存活探测器来发现并处理这种情况。
就绪（Readiness）
readinessProbe 就绪探测器在容器的整个生命周期中保持运行状态，周期性检测
有时候，应用会暂时性地无法为请求提供服务。 例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 在这种情况下，既不想杀死应用，也不想给它发送请求。 Kubernetes 提供了就绪探测器来发现并缓解这些情况。 容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
启动（Startup）
startupProbe 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。
有时候，会有一些现有的应用在启动时需要较长的初始化时间。 要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间。
探测方式：探测执行是由 kubele t发起的
http接口探测：返回大于或等于 200 并且小于 400 的任何代码都标示成功，其它返回代码都标示失败；
TCP探测：kubelet 会尝试在指定端口和容器建立套接字链接。 如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。
exec命令探测：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
grpc： gRPC 探针是一个 alpha 特性；
pod终止：
preStop
体面的终止pod：在pod终止之前，通过回调执行一些中之前的清理工作，或者容器中存在多个进程，关闭时需要按照顺序进行关闭和清理，此时可以通过容器声明周期回调处理，而非直接kill掉进程为1的容器内部进程；
注意：如果 preStop 回调所需要的时间长于默认的体面终止限期，你必须修改 terminationGracePeriodSeconds 属性值来使其正常工作。
PostStart 一般不使用，这个回调在容器被创建之后立即被执行。 但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。 没有参数传递给处理程序。
回调处理程序的实现：
容器可以通过实现和注册该回调的处理程序来访问该回调。 针对容器，有两种类型的回调处理程序可供实现：
Exec - 在容器的 cgroups 和名称空间中执行特定的命令（例如 pre-stop.sh）。 命令所消耗的资源计入容器的资源消耗。
HTTP - 对容器上的特定端点执行 HTTP 请求
参考：
https://kubernetes.io/zh/docs/concepts/containers/container-lifecycle-hooks/
https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination
