Kubernetes 核心三层关系：Namespace / Deployment / Pod（k9s 实战视角）

​ 在使用 Kubernetes（尤其是用 k9s 做运维或排障）时，很多人会卡在一个问题上：namespace、deployment、pod 到底是什么关系？为什么我切了 ns 之后还要找 deployment？

​ 其实这三个概念不是并列的，而是分层结构 + 职责分工。

一、先给结论（非常重要）

​ 可以先用一句话理解：Namespace 决定“在哪个环境”，Deployment 决定“怎么管理应用”，Pod 是真正运行的实例。

Namespace  = 环境隔离（dev / test / prod）
Deployment = 应用控制器（负责版本与更新）
Pod        = 运行中的容器实例

二、三者完整关系图

​ 在 Kubernetes 里，真实结构是这样的：

Cluster（集群）
└── Namespace（环境隔离）
    └── Deployment（应用控制器）
        └── ReplicaSet（版本副本控制）
            └── Pod（实际运行的容器）

​ 你在 k9s 里看到的一切，本质都是在这棵树上切不同层级。

三、Namespace：你“在哪个环境操作”

3.1 作用

​ Namespace 的本质是：资源隔离 + 环境划分。

​ 常见划分：

• dev（开发环境）
• test（测试环境）
• prod（生产环境）

3.2 为什么必须有 ns？

​ 因为 Kubernetes 是“共享集群”：

• 同一个服务可以在不同 ns 同名存在

• 资源不会互相影响

  例如：

dev/user-service
prod/user-service

​

3.3 在 k9s 中的作用

​ 在 k9s 输入：

:ns

​ 这样可以切换“当前查看的环境”

​ 注意：ns 不改变资源，只改变“你看的范围”。

四、Deployment：真正的“管理者”

4.1 作用

​ Deployment 的职责是：管理 Pod 的生命周期 + 版本更新 + 副本数控制。

(1) 控制副本数量

​ 比如：

replicas: 3

​ 永远保证 3 个 Pod 在运行

(2) 管理版本更新（Rolling Update）

​ 当你更新镜像：

旧 Pod → 新 Pod 逐步替换

(3) 自动修复

​ Pod 挂了会自动拉起新的

4.2 k9s 中的位置

:deploy

​ 你看到的是：

• 应用整体状态
• rolling update 进度
• replica 状态

4.3 rollout restart 本质

kubectl rollout restart deployment xxx

​ 其实是给 Deployment 触发一次“版本更新事件”，然后 Kubernetes 自动：

新 ReplicaSet → 新 Pod → 替换旧 Pod

• rollout和rollingupdate容易混淆

  rollout 是“管理发布过程的对象”，rollingupdate时滚动发布更新策略。

  概念	是什么
  Rollout	发布过程（状态/历史）
  RollingUpdate	更新策略（行为方式）

五、Pod：真正运行的东西

​ Pod 是Kubernetes 中最小运行单位（容器的封装）

5.1 特点

• 一个 Pod = 一个或多个容器

• Pod 是“短生命周期”的

• 名字通常是自动生成的

  例如：

user-service-7c9f6b8d5-x8k2p

5.2 Pod 什么时候重要？

​ 你会直接操作 Pod：

• 看日志
• 进容器
• 排查问题

kubectl logs pod-name
kubectl exec -it pod-name -- sh

六、三者如何协作（核心理解）

​ 举一个真实场景，当我们执行 rollout restart时：

kubectl rollout restart deployment user-service

​ 实际发生：

1. Deployment 发生变更
2. 创建新的 ReplicaSet
3. 逐步创建新 Pod
4. 逐步删除旧 Pod
5. 保持副本数不变（例如 3）

​ 最关键点就是我们操作的是 Deployment，但变化的是 Pod。rollout restart 并不是“重启 Pod”，而是触发 Deployment 重新创建 ReplicaSet，从而逐步替换 Pod。

七、在 k9s 中的真实操作逻辑

Step 1：选择环境

:ns

​ 选namespace

Step 2：查看应用

:deploy

​ 看服务整体状态

Step 3：查看运行实例

:pod

​ 看具体容器是否正常

Step 4：排查问题

• 选 Pod → l 看日志
• d 看详情
• s shell 进入容器

八、最常见误区

8.1 误区1：ns 是“进入某个页面”

​ 错，ns 只是“过滤范围”

8.2 误区2：Pod 是你要操作的主体

​ 错，Pod 是结果，不是入口

8.3 误区3：rollout restart 是重启 Pod

​ 不准确，实际是触发 Deployment 更新 → Pod 被重建

九、总结

​ Namespace 决定你在哪个环境，Deployment 决定如何管理应用，Pod 才是真正运行的实例，而所有操作最终都会通过 Deployment 影响 Pod。