一、独立 Pod 应用程序的挑战
1. Pod 是基本实体
- Pod 是 Kubernetes 中运行应用程序的最小可部署单元，是容器的封装体。pods/)
- 所有高级控制器（如 Deployment、DaemonSet、StatefulSet）底层都是以 Pod 为单位来实现实例管理和调度。
2. 独立 Pod 作为应用程序的运行方式
- 独立创建的 Pod 不受控制器管理，不具备自动恢复机制。Pod 故障后需人工重新创建，集群不会自动处理。
- 因此，不建议在生产环境中使用独立 Pod 进行应用部署。
3. Pod 与节点调度的关系
- Pod 默认情况下不绑定具体节点，调度由调度器决定，Pod 删除后重建可能被调度到不同的节点。
- 若需绑定指定节点，可通过
nodeName、nodeSelector或nodeAffinity来实现。
4. Pod 生命周期的局限性
- Kubernetes 不会自动管理独立 Pod 的生命周期，Pod 一旦失败或被删除，除非手动操作，否则不会恢复。
- 缺乏自动恢复能力使得独立 Pod 不适合高可用应用部署场景。
5. 高可用部署的推荐方式
- 应使用 Deployment、ReplicaSet、DaemonSet 等控制器来管理 Pod，提高可用性与容错能力。
- 就实践而言，在 Kubernetes 集群中 几乎不会直接部署独立 Pod。Deployment 等控制器可以自动处理 Pod 重启、扩容与滚动更新。(https://stackoverflow.com/questions/41325087/what-is-the-difference-between-a-pod-and-a-deployment)
6. 保持定义连续性
- 为了避免信息紊乱，应将不同独立应用部署在各自的 Pod 中，不要在一个 Pod 内堆叠多个无关容器。
- 容器编排应以应用的依赖关系为导向，而不是简单地把多个服务集中于单个 Pod。
7. 清理失败 Pod 的必要性
- 失败或终止状态的 Pod 会占用有限资源，应及时清理，不依赖系统垃圾回收机制（如超过
terminatedPodGCThreshold才触发）。 - 使用
kubectl delete pod或通过 API 删除后，Pod 会进入 Terminating 状态，再逐步被释放。
8. 节点故障对 Pod 的影响
- 若节点发生故障，其上的 Pod 会被标记为删除，不会自动迁移到其他节点。
- 恢复流程需人工干预，例如通过控制器（Deployment 等）或重新创建 Pod 来恢复工作负载。
总结
独立 Pod 具有以下局限与挑战：
- 无自动恢复：Pod 故障无法自动重启；
- 调度不确定：无法保证 Pod 重建后仍在原节点运行；
- 难以维护高可用性：容易成为单点故障；
- 资源占用不可控：需主动清理失败 Pod；
- 操作繁琐：管理效率低，不适合生产环境。
推荐使用控制器（Deployment、ReplicaSet、DaemonSet）来部署、管理和维护应用，实现自动扩容、Rolling Update 和高可用保障。