一、 K8s 网络架构：让万物互联

在 K8s 中，网络的设计哲学是：扁平化。它要求所有 Pod 即使不在同一台物理机上，也能像在局域网内一样直接通信。

1. 三层通信逻辑

K8s 网络解决的是四个层面的对话：

• 容器间通信： 同一个 Pod 内的容器共享网络栈（通过 localhost 访问）。

• Pod 到 Pod： 跨节点的 Pod 通过 CNI（容器网络接口） 插件（如 Calico, Flannel）打通的隧道直接互访。

• Pod 到 Service： 通过 iptables 或 IPVS 规则，将流量均衡到后端 Pod。

• 外部到内部： 通过 Ingress 或 LoadBalancer 接入流量。

2. 核心组件：CNI (Container Network Interface)

CNI 是 K8s 网络的标准接口。

• 实际应用： 当部署一个新 Pod 时，Kubelet 会调用 CNI 插件。插件会为 Pod 分配一个唯一的集群 IP，并配置好路由，确保这个 IP 在全集群范围内可达。

二、 K8s 存储架构：从“临时”到“永恒”

容器天生是“无状态”的，重启后数据就会消失。为了保存数据库或日志，K8s 设计了一套极其精妙的解耦存储体系：PV / PVC / StorageClass。

1. 存储三剑客的关系

为了让“开发人员”不关心底层的存储细节，K8s 把存储分成了三层：

2. 实际应用场景：部署一个 MySQL

1. 管理员配置一个 StorageClass（对接阿里云或 AWS 磁盘）。

2. 开发者提交一个 PVC，声明需要 50GB 存储。

3. K8s 自动创建 PV 并将其“挂载”到 MySQL Pod 的 /var/lib/mysql 目录。

4. 结果： 即使 MySQL Pod 挂了，新拉起的 Pod 只要挂载同一个 PVC，数据依然完好无损。

思考： 在大型公司里，有几十个团队共用一个 K8s 集群。如何保证 A 团队的开发人员不会误删 B 团队的 Pod？如何限制某个应用只能使用 2GB 内存？

三、RBAC 权限控制与资源隔离

1. Namespace（命名空间）：逻辑上的“隔断墙”

在 K8s 中，Namespace 是实现多租户隔离的第一步。它就像是公司里不同的部门办公室。

• 默认状态： 你部署的所有东西都在 default 空间。

• 实际应用： * 按环境划分：dev（开发）、test（测试）、prod（生产）。

  • 按团队划分：order-team（订单组）、payment-team（支付组）。

• 隔离效果： 在 dev 空间下执行 kubectl get pods，你看不到 prod 空间里的任何资源。

2. RBAC（基于角色的访问控制）：集群的“门禁卡”

RBAC 决定了“谁（Subject）”能对“什么资源（Resource）”做“什么操作（Verb）”。

核心四要素

1. Subject（主体）： 谁在操作？（是一个开发人员，还是一个自动化的程序 ServiceAccount）。

2. Role（角色）： 能干什么？（比如：只能查看 Pod，不能删除 Pod）。

3. Resource（资源）： 对谁操作？（Pod、Deployment、Service）。

4. RoleBinding（绑定）： 把“人”和“角色”关联起来。

实际应用场景

• 场景 A： 给实习生发一张“只读卡”。他只能看日志排查问题，但没有任何修改权限。

• 场景 B： 给 Jenkins 自动化流水线发一张“发布卡”。它只能更新 Deployment 的镜像，不能修改网络配置。

3. Resource Quotas（资源配额）：防止“独占资源”

在一个共享集群中，最怕某个应用出现内存泄漏，把整台宿主机的资源吃光，导致其他应用崩溃。K8s 通过两个层面来管控：

• ResourceQuota（部门限额）： 限制一个 Namespace 总共能用多少 CPU 和内存。

  例子：给“开发组”分配总共 16 核 CPU 和 32GB 内存。一旦超标，新 Pod 将无法启动。

• LimitRange（个人限额）： 限制单个 Pod 最小和最大能申请多少资源。

  例子：强制要求每个 Java 应用必须设置 request（保障值）和 limit（限制值）。

总结：K8s 架构的完整拼图