docker容器生命周期在kubernetes中被扩展和抽象化：底层仍遵循created→running→exited/deleted原生命命周期，kubelet通过cri调用运行时获取状态并映射为pod的containerstatus；上层新增restartpolicy、probe、pod phase等声明式语义，由控制器统一调度与兜底，状态归属从用户手动管理转为系统可观测性的一部分。
docker 容器生命周期在容器编排工具（如 kubernetes）中不是被“替换”，而是被“扩展”和“抽象化”。编排工具不改变容器本身的状态机，而是用更高层的模型去调度、观察、干预和兜底这些状态。
容器状态仍是底层基础
Kubernetes 中的 Pod 会包含一个或多个容器，每个容器依然经历 created → running → exited/paused → deleted 这些原生命命周期阶段。Kubelet（节点上的代理）持续调用 Docker 或其他容器运行时（如 containerd）的 API，读取容器真实状态（比如通过 docker ps -a 或 CRI 接口），再映射为 Pod 的 ContainerStatus 字段。例如：
- 容器进程退出 → 状态变为
terminated，Kubelet 记录 exit code 和原因 - OOM 被杀 → 容器进入
exited，Kubelet 标记为OOMKilled - 镜像拉取失败 → 容器卡在
created，Pod 状态显示ImagePullBackOff
编排层新增语义与控制逻辑
Kubernetes 不直接暴露 docker pause 或 docker restart 这类命令，而是用声明式策略覆盖操作细节：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
-
重启策略（restartPolicy）：决定容器退出后是否重建（
Always/OnFailure/Never）。这对应了docker run --restart=on-failure:3，但由控制器统一管理 -
Liveness/Readiness Probe：探测失败时，Kubelet 主动执行
docker kill或触发重建，而不是等容器自己挂掉 -
Pod 生命周期阶段（Phase）：如
Pending（调度未完成）、Running（至少一个容器就绪）、Succeeded（所有容器成功退出）——这是对底层容器状态的聚合与业务语义增强
关键差异：状态归属与责任边界
在单机 Docker 中，状态属于用户手动管理；在 Kubernetes 中，状态是系统可观测性的一部分，且多数变更由控制器驱动：
- 你执行
kubectl delete pod，Kubelet 收到指令后调用docker rm -f，容器进入deleted状态 - 节点宕机 → 容器实际已消失（
exited或失联），但 Kubernetes 将其标记为Unknown，并由 controller 在超时后驱逐并新建 Pod -
docker pause在 Kubernetes 中没有直接等价操作，因为暂停违反了声明式设计原则；若需冻结行为，通常改用停止 Deployment 或设置副本数为 0
实际调试时的映射线索
遇到问题时，可沿这两层链路排查：
- 看 Pod 状态：
kubectl get pod -o wide→ 关注STATUS列（如CrashLoopBackOff） - 看容器详情：
kubectl describe pod <name></name>→ 查Events和Container Statuses中的state字段（如waiting: CrashLoopBackOff） - 查节点上真实容器：
docker ps -a | grep <pod-id></pod-id>→ 验证是否真处于exited，exit code 是否为 137（OOM）或 143（SIGTERM）
