k8s_网络&&存储

一、 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 把存储分成了三层：

角色	对象	类比	职责
底层资源	PV (Persistent Volume)	一块硬盘	由管理员配置的真实存储资源（NFS, Ceph, 云硬盘等）。
需求声明	PVC (Persistent Volume Claim)	申请单	开发人员定义的“需求”（我要 10G 空间，读写权限）。
自动化生产	StorageClass	自动售货机	自动根据 PVC 的需求创建对应的 PV，无需人工介入。

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 架构的完整拼图