📚 课程目录第4章 K8s网络模型与鉴权

4. K8s 网络模型与鉴权：CNI 插件、网络策略(NetworkPolicy)、ServiceAccount 与 RBAC 基础

在 Kubernetes 环境中排查分布式事务鉴权拦截故障，必须首先理解两个基础支柱：网络模型（决定流量如何路由）与鉴权模型（决定谁可以做什么）。本章将拆解 CNI 插件、NetworkPolicy、ServiceAccount 与 RBAC 的核心机制，为后续故障定位打下基础。

4.1 Kubernetes 网络模型与 CNI 插件

K8s 网络模型要求每个 Pod 拥有独立的 IP，且 Pod 之间无需 NAT 即可直接通信。这一模型由 CNI（Container Network Interface） 插件实现。

4.1.1 CNI 插件核心职责

IP 地址管理（IPAM）：为 Pod 分配集群内唯一的 IP 地址。
网络连通性：确保同一节点或跨节点的 Pod 可以二层/三层互通。
网络策略执行：部分 CNI 插件（如 Calico、Cilium）直接支持 NetworkPolicy 的强制实施。

4.1.2 主流 CNI 插件对比

插件	数据面技术	NetworkPolicy 支持	典型场景
Flannel	VXLAN / host-gw	不支持（需额外组件）	小型集群、快速部署
Calico	BGP / eBPF	原生支持（iptables / eBPF）	生产环境、策略严格
Cilium	eBPF	原生支持（eBPF 高效）	高性能、可观测性要求高
Weave Net	VXLAN / fastdp	支持	多云、混合环境

故障排查提示： 如果分布式事务的 Pod 之间出现间歇性连接失败，首先检查 CNI 插件的 IPAM 是否出现地址冲突，以及节点间的底层网络（如 VXLAN 隧道）是否健康。

4.2 网络策略（NetworkPolicy）

NetworkPolicy 是 K8s 原生的防火墙规则，用于控制 Pod 组之间的流量。它工作在 L3/L4 层（IP + 端口），部分 CNI 插件（如 Cilium）可扩展至 L7。

4.2.1 NetworkPolicy 核心要素

Pod 选择器：通过 label 选定策略作用的 Pod 组。
入站规则（Ingress）：允许哪些来源访问选定的 Pod。
出站规则（Egress）：允许选定的 Pod 访问哪些目标。
策略类型：默认拒绝所有未显式允许的流量。

4.2.2 典型策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: transaction-deny-all
  namespace: tx-system
spec:
  podSelector:
    matchLabels:
      app: transaction-service
  policyTypes:
  - Ingress
  - Egress
  ingress: []   # 拒绝所有入站
  egress: []    # 拒绝所有出站

常见故障点： 分布式事务协调器与参与者之间需要双向通信。如果 NetworkPolicy 只配置了 Ingress 规则而遗漏了 Egress 规则，或者 label 选择器写错，会导致事务提交请求被静默丢弃，表现为“事务超时”或“鉴权失败”。

4.3 ServiceAccount 与 RBAC 基础

K8s 鉴权体系分为三个步骤：认证（Authentication） → 授权（Authorization） → 准入控制（Admission Control）。ServiceAccount 负责 Pod 的身份认证，RBAC 负责授权。

4.3.1 ServiceAccount（服务账户）

定义：为 Pod 提供身份标识，用于向 API Server 发起请求。
自动挂载：每个命名空间默认有一个 default ServiceAccount，Pod 创建时自动挂载其 Token。
Token 类型：K8s 1.24+ 默认使用 Projected Service Account Token（时间绑定、受众绑定），不再自动生成 Secret。

4.3.2 RBAC（基于角色的访问控制）

RBAC 通过四个核心对象控制权限：

对象	作用	示例
Role	定义命名空间内的权限集合	`get pods, create deployments`
ClusterRole	定义集群级别的权限（如 nodes、persistentvolumes）	`get nodes, list namespaces`
RoleBinding	将 Role 绑定到 User/Group/ServiceAccount（命名空间内）	`role: pod-reader → sa: tx-sa`
ClusterRoleBinding	将 ClusterRole 绑定到 User/Group/ServiceAccount（集群范围）	`clusterrole: view → user: alice`

4.3.3 鉴权拦截故障典型链路

当分布式事务组件（如 Seata、DTM）需要访问 API Server 查询 Pod 状态或更新资源时，鉴权流程如下：

Pod 使用挂载的 ServiceAccount Token 发起请求。
API Server 验证 Token 有效性（认证）。
API Server 检查 RBAC 规则是否允许该操作（授权）。
如果 Token 过期、RBAC 规则缺失或 ServiceAccount 未正确绑定，则返回 403 Forbidden 或 401 Unauthorized。

  实战案例： 某生产环境中，Seata Server 无法向 API Server 注册自身信息，日志显示 Forbidden: user "system:serviceaccount:seata:default" cannot create resource "endpoints"。原因是默认 ServiceAccount 没有创建 Endpoints 的权限，需要创建 Role 并绑定。

4.4 网络与鉴权的交汇点：Pod 身份与网络策略的联动

在分布式事务场景中，网络策略和鉴权策略可能产生叠加效应：

NetworkPolicy 限制流量：即使 RBAC 允许 Pod A 访问 API Server，如果 NetworkPolicy 阻止了 Pod A 的出站流量，请求仍然失败。
ServiceAccount 用于网络策略：部分 CNI 插件（如 Cilium）支持基于 ServiceAccount 的 L7 网络策略，实现更细粒度的控制。

4.5 本章小结

CNI 插件 决定了 Pod 网络连通性，不同插件对 NetworkPolicy 的支持程度不同。
NetworkPolicy 是 Pod 级别的防火墙，默认拒绝所有未允许的流量，容易导致分布式事务通信中断。
ServiceAccount 为 Pod 提供身份，RBAC 控制该身份对 API Server 的访问权限。
故障排查时，应遵循 先网络后鉴权 的顺序：先确认 Pod 间网络可达，再检查 ServiceAccount 和 RBAC 配置。