上一篇【第46篇】K8s DNS——CoreDNS的黄页服务下一篇【第48篇】Service的三种代理模式——userspace/iptables/IPVS摘要前面讲了网络连通Flannel/Calico、讲了名字解析CoreDNS。现在问你一个扎心的问题你的Pod之间现在谁都能访问谁吗答案是——默认情况下是的。K8s集群里所有Pod默认是全通的。这就像你住的小区所有住户的门都不上锁快递员能进你家厨房隔壁老王能翻你衣柜。这在演示环境没问题但在生产环境就是灾难一个被攻破的Pod能横向移动到所有其他Pod。NetworkPolicy就是给Pod装上的防火墙——按白名单精确控制谁能访问谁、走哪个端口。注意它的名字里带Policy而不是Firewall因为它只是声明意图真正去挡包的是背后的CNI插件Calico/Cilium。这篇文章讲三件事(1)NetworkPolicy的YAML到底怎么写(2)ingress和egress分别管什么(3)怎么用默认拒绝→按需放通搭一套零信任网络。一、NetworkPolicy长什么样1.1 全景结构先看一个完整的例子再逐个拆apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:backend-policynamespace:prodspec:podSelector:# ① 这条规则保护谁matchLabels:app:backendpolicyTypes:# ② 管入站还是出站(或都管)-Ingress-Egressingress:# ③ 允许哪些入站流量-from:-podSelector:# 只允许 frontend 这个Pod访问matchLabels:app:frontendports:-protocol:TCPport:8080egress:# ④ 允许哪些出站流量-to:-podSelector:matchLabels:app:databaseports:-protocol:TCPport:54321.2 四个核心字段【NetworkPolicy 四要素——保护谁/管什么/从哪来/到哪去】 ┌──────────────────────────────────────────────────────┐ │ podSelector → 保护谁 │ │ 选中本namespace里要受此策略约束的Pod │ │ {} 表示所有Pod │ ├──────────────────────────────────────────────────────┤ │ policyTypes → 管什么 │ │ Ingress (入站) / Egress (出站) │ │ 不写默认有ingress块就管入站有egress块就管出站 │ ├──────────────────────────────────────────────────────┤ │ ingress.from → 从哪来(允许谁访问我) │ │ podSelector / namespaceSelector / ipBlock │ │ 不写from 允许所有入站(配合policyTypes要小心) │ ├──────────────────────────────────────────────────────┤ │ egress.to → 到哪去(允许我访问谁) │ │ podSelector / namespaceSelector / ipBlock │ └──────────────────────────────────────────────────────┘要点NetworkPolicy是**“白名单语义**——你写了什么就是允许什么”没写的就是拒绝前提是策略已经生效。但有个关键陷阱如果某个Pod没有匹配任何NetworkPolicy那它就是全通的不设防。只有当Pod被至少一条策略选中它才会进入默认拒绝模式。这个特性决定了我们后面要用的零信任套路。二、ingress vs egress——“进门和出门”2.1 区别一目了然【Ingress 管谁能进我 / Egress 管我能去哪】 Pod A (被策略保护) ┌──────────────────────────┐ │ │ │ ◄── Ingress ── 谁能访问我 (外部→A) │ │ │ ── Egress ──► 我能访问谁 (A→外部) │ │ └──────────────────────────┘ 常见误区 • 只写 ingress不写 egress → A能收流量但A主动发出的流量全被禁 • 只写 egress不写 ingress → A能发出去但谁也访问不了A2.2 三种来源/去向选择器from和to里可以混用三种选择器选择器含义示例podSelector同namespace内匹配Label的PodmatchLabels: {app: frontend}namespaceSelector匹配Label的整个namespacematchLabels: {team: finance}ipBlock匹配CIDR的IP段cidr: 10.0.0.0/24podSelectornamespaceSelector某namespace里某Label的Pod组合使用# 组合选择器只允许 team: frontend 命名空间里的 app: web Pod 访问ingress:-from:-namespaceSelector:matchLabels:team:frontendpodSelector:matchLabels:app:web三、零信任默认拒绝 → 按需放通3.1 为什么要从默认拒绝开始默认全通太危险。零信任的思路是先把所有门都锁上再给需要的人发钥匙。# 第一步默认拒绝某namespace所有入站出站(最狠的锁)apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-allnamespace:prodspec:podSelector:{}# 选中所有PodpolicyTypes:-Ingress-Egress# 不写 ingress / egress → 一条允许的都没有 → 全拒要点这条策略一生效prod命名空间里所有Pod既不能接收任何流量也不能主动发任何流量——包括DNS解析DNS是出站UDP 53被egress挡了。所以实战中通常会补一条允许DNS的放行否则Pod连名字都解析不了应用直接崩。3.2 完整的三层应用隔离实战【三层应用零信任网络拓扑】 Internet │ ▼ [Ingress Controller] --允许-- frontend (80) │ 只允许 frontend │ ▼ backend (8080) │ 只允许 backend │ ▼ database (5432) │ 只允许访问 DNS# 1. 放行DNS(否则所有Pod都傻了)apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-dnsnamespace:prodspec:podSelector:{}policyTypes:[Egress]egress:-to:-namespaceSelector:{}# 任意namespaceports:-protocol:UDPport:53-protocol:TCPport:53# 2. frontend 只允许被 Ingress Controller 访问apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:frontend-allow-ingressnamespace:prodspec:podSelector:matchLabels:{app:frontend}policyTypes:[Ingress]ingress:-from:-namespaceSelector:matchLabels:{kubernetes.io/metadata.name:ingress-nginx}ports:-protocol:TCPport:80# 3. backend 只允许 frontend 访问apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:backend-allow-frontendnamespace:prodspec:podSelector:matchLabels:{app:backend}policyTypes:[Ingress]ingress:-from:-podSelector:matchLabels:{app:frontend}ports:-protocol:TCPport:8080# 4. database 只允许 backend 访问apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:db-allow-backendnamespace:prodspec:podSelector:matchLabels:{app:database}policyTypes:[Ingress]ingress:-from:-podSelector:matchLabels:{app:backend}ports:-protocol:TCPport:5432四、关键限制NetworkPolicy依赖CNI4.1 不是所有网络插件都支持这是个重要警告NetworkPolicy只是个声明真正去挡包的得靠CNI插件。CNI插件NetworkPolicy支持说明Calico✅ 完整(L3/L4)行业标杆Cilium✅ 完整(L3/L4/L7)支持HTTP/gRPC级策略Weave Net✅ 支持但性能一般Flannel❌ 不支持写了策略也不会生效kube-router✅ 支持基于iptables要点如果你用的是Flannel写了NetworkPolicy也不会有任何效果——因为Flannel压根不实现策略执行。这是新手最容易踩的坑以为加了策略就安全了结果流量照样全通。所以要做微隔离请选Calico或Cilium。另外NetworkPolicy只管Pod间/L3-L4流量管不了Servicekube-proxy在Pod网络之前就做了DNAT策略看不到原始目的。要做L7比如只允许GET /api得上Cilium的CiliumNetworkPolicy。本篇小结NetworkPolicy是K8s的Pod防火墙用白名单语义控制谁能访问谁、走哪个端口。记住四要素podSelector保护谁、policyTypes管入站还是出站、ingress.from管谁进来、egress.to管我去哪。最稳的玩法是默认拒绝→按需放通的零信任先锁死所有流量再一条条发钥匙别忘了放行DNS。但务必确认你的CNI插件支持策略——Flannel用户请直接换Calico/Cilium否则写了也白写。上一篇【第46篇】K8s DNS——CoreDNS的黄页服务下一篇【第48篇】Service的三种代理模式——userspace/iptables/IPVS