spec:
containers:
- image: wangyanglinux/myapp:v1.0
imagePullPolicy: IfNotPresent
name: myapp-1
readinessProbe:
failureThreshold: 3
httpGet:
path: /index1.html
port: 80
scheme: HTTP
initialDelaySeconds: 1
periodSeconds: 3
successThreshold: 1
timeoutSeconds: 1
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: kube-api-access-29fwr
readOnly: true
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: k8s-node02
preemptionPolicy: PreemptLowerPriority
priority: 0
restartPolicy: Always
1. 什么是“主进程（PID 1）”？
在 Linux 系统（容器底层就是 Linux）中，当一个容器被启动时，它会运行你在 YAML 中配置的 command （或者 Dockerfile 中的 ENTRYPOINT ）。
● 这个启动命令在容器内部产生的第一个进程，就是主进程（PID 1）。
● 核心铁律：只要这个 PID 1 还在运行，容器就处于 Running 状态；一旦这个 PID 1 退出了，K8s 就认为这个容器“死”了。
2. 多容器 Pod 中， restartPolicy 是如何工作的？
假设你的 Pod 里有 3 个容器（A、B、C）。 restartPolicy: Always 是作用在 Pod 级别的，但 Kubelet 在执行时，是分别盯着每一个容器的：
● 如果容器 A 的 PID 1 崩溃退出了：Kubelet 发现 A 死了，就会只重启容器 A。容器 B 和 C 完全不受影响，继续正常运行。
● 如果容器 B 的 PID 1 也崩溃了：Kubelet 就会去重启容器 B。
● 如果 A、B、C 全都崩溃退出了：Kubelet 会把它们挨个重启。
所以， restartPolicy 就像是 Kubelet 给每个容器派发的“独立监工”，谁挂了，Kubelet 就重启谁。
3. 一个常见的致命误区
很多初学者会认为：“Pod 里只要有一个容器挂了，整个 Pod 就会重启。” 这是完全错误的。
Kubernetes 的设计哲学是：容器是独立的执行单元，Pod 只是它们的逻辑外壳。
● 容器 A 挂了，Kubelet 只拉起 A。
● 只有当整个 Pod 被外部指令（如 kubectl delete pod 、节点宕机、被驱逐等）销毁时，所有的容器才会一起被销毁。
总结来说：
你提到的 mainc （我猜你想说的是 Pod 里的某一个 container），它里面确实有自己的主进程。但 restartPolicy 并不是“只盯着某一个容器”，而是盯着 Pod 里的【所有】容器。谁的主进程（PID 1）退出了，Kubelet 就按策略重启谁。
● restartPolicy: Always 的作用：负责“存活”。只要主进程挂了，立刻重启容器。
● livenessProbe (存活探针) 的作用：负责“健康”。如果应用卡死（比如死锁、内存泄漏但进程还在）， Always 是不知道的（因为进程没退出），这时候 livenessProbe 会通过 restartPolicy 触发重启。
● readinessProbe (就绪探针) 的作用：负责“流量”。这是你问题的关键。 就算 restartPolicy 是 Always ，就算容器运行得好好的，如果 readinessProbe 失败，Kubelet 只会把该 Pod 从 Service 的 Endpoints 列表中剔除（即不给它发流量），而不会重启容器。
