Kubernetes NetworkPolicy 实战
约 1007 字大约 3 分钟
kubernetessecuritynetworking
2026-03-14
概述
NetworkPolicy 用来定义 Pod 级别的网络访问边界。它解决的不是“怎么让服务互通”,而是“哪些 Pod 之间允许互通”。在多团队共享集群、零信任内网和合规要求下,它是 Kubernetes 里非常基础的一层控制面。
先理解三个事实
NetworkPolicy是否生效,取决于 CNI 插件是否支持,例如 Calico、Cilium。- 它只控制 Pod 网络流量,不直接替代 Ingress、Service、RBAC。
- 没有命中的策略通常意味着“默认允许”,但一旦某个方向被策略选中,就会变成白名单模式。
工作模型
要点:
podSelector选择被保护的 Pod。ingress规定哪些来源可以访问它。egress规定它可以访问哪些目标。policyTypes决定策略作用于入站、出站还是两者。
默认拒绝是起点
实际治理里,通常先从 namespace 级默认拒绝开始,再逐步开白名单。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress这条策略的含义是:
- 选中
production命名空间里的所有 Pod。 - 对它们的入站和出站都不再“默认允许”。
允许同命名空间内部调用
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-same-namespace
namespace: production
spec:
podSelector: {}
ingress:
- from:
- podSelector: {}
egress:
- to:
- podSelector: {}
policyTypes:
- Ingress
- Egress这常用于第一阶段收敛,先堵住跨命名空间乱连,再继续细分服务边界。
允许网关访问后端
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-gateway-to-order
namespace: production
spec:
podSelector:
matchLabels:
app: order-service
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ingress-system
podSelector:
matchLabels:
app: gateway
ports:
- protocol: TCP
port: 8080
policyTypes:
- Ingress这类策略建议同时限制:
- 来源命名空间
- 来源 Pod 标签
- 目标端口
只配 podSelector 不配端口,往往会放得过宽。
数据库出口控制
后端 Pod 经常需要访问数据库、DNS、消息系统,出站策略不能忘掉这些基础依赖。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: order-service-egress
namespace: production
spec:
podSelector:
matchLabels:
app: order-service
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: database
podSelector:
matchLabels:
app: mysql
ports:
- protocol: TCP
port: 3306
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
policyTypes:
- EgressDNS 是最常被漏掉的一项。策略上线后服务名解析失败,通常不是应用坏了,而是 UDP 53 被挡住了。
常见排障思路
Pod 之间不通
先确认:
- 两端 Pod 标签是否和策略匹配。
- 命名空间标签是否真的存在。
- CNI 是否已启用 policy enforcement。
Service 能访问,Pod 直连不通
问题通常出在:
- 你只放开了 Service 流量方向,没放开目标 Pod 的 ingress。
- kube-proxy 或 eBPF 转发路径和预期不同,导致命中的不是你以为的源地址集合。
某些环境生效,某些环境不生效
优先检查不同集群的 CNI 能力差异。NetworkPolicy 语法一样,不代表实现语义完全一致。
设计建议
- 先按 namespace 做隔离,再按应用细化。
- 对核心服务统一约束标签规范,否则策略会越来越难读。
- 把 DNS、监控、日志、Service Mesh 控制面这些“基础流量”单独梳理出来。
- 用 staging 集群做连通性回归,不要直接在生产上试白名单。
- 给策略命名加上意图,例如
allow-gateway-to-order,不要只叫policy-1。
与其他机制的边界
Ingress解决南北向入口暴露。Service解决服务发现和负载均衡。RBAC解决 API 访问权限。NetworkPolicy解决 Pod 网络平面访问边界。
这四者经常一起出现,但它们控制的是不同层面。
总结
NetworkPolicy 的本质是把“网络是否可达”变成显式声明。真正难的不是写 YAML,而是先把系统依赖关系梳理清楚。只要依赖图清楚,策略通常会比想象中简单很多。
贡献者
更新日志
2026/3/14 13:09
查看所有更新日志
9f6c2-feat: organize wiki content and refresh site setup于