networkpolicy 默认不生效，需确认cni支持（如calico/cilium支持，flannel不支持）；“默认拒绝”须逐命名空间部署；微服务白名单需双向定义ingress/egress；跨命名空间访问应使用namespaceselector+podselector而非ipblock。
NetworkPolicy 默认不生效，先确认 CNI 是否支持
创建 NetworkPolicy 对象本身不会报错，但若底层 CNI 不支持策略执行（如 Flannel、早期版本的 Weave），所有规则形同虚设。你看到“策略已创建”，却测不出任何拦截效果，大概率是卡在这一步。
验证方法很简单：
- 运行
kubectl get crd | grep networkpolicies确认 API 资源存在（这仅说明 Kubernetes 能识别该类型） - 查 CNI 插件文档：Calico、Cilium、Antrea、Weave（v2.8+）原生支持；Flannel 完全不支持，必须换插件或加额外组件（如 kube-router）
- 在任意 Pod 中执行
iptables -L KUBE-NWPLCY-INGRESS（Calico）或bpftool prog list | grep cilium（Cilium），有输出才表示策略已注入数据平面
“默认拒绝”必须按命名空间逐个部署
NetworkPolicy 作用域限定在单个 namespace 内，不存在“集群全局默认拒绝”。你给 production 命名空间配了 default-deny-ingress，staging 仍完全开放——这是最常被忽略的隔离盲区。
正确做法是为每个业务命名空间独立部署基础拒绝策略：
- 策略中
podSelector: {}匹配该命名空间下所有 Pod，不含标签筛选条件 -
policyTypes: [Ingress]显式声明，避免旧版本 Kubernetes 因省略字段导致只生效 Ingress（而你本意是两者都禁） - 不要依赖 “一个策略管全部” 的幻想；CI/CD 流水线中应将此策略作为命名空间创建后的必跑步骤
微服务间白名单必须双向定义：Ingress + Egress 都要配
只给 backend Pod 加一条允许来自 frontend 的 Ingress 规则，不代表 backend 就能成功调用 database。出站流量（Egress）默认仍被阻断——零信任要求“每条路径显式授权”，包括返回包所需的反向连接（如 TCP ACK）通常由连接跟踪自动放行，但新建连接必须匹配 Egress 规则。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
典型三段式策略链：
-
frontend的 Egress → 允许到backend的 8080/TCP -
backend的 Ingress ← 来自frontend标签，且backend的 Egress → 允许到database的 5432/TCP -
database的 Ingress ← 来自backend标签，且database的 Egress 通常可留空（除非它要连外部服务）
漏掉任一端，就会出现 “前端能连通 backend，但 backend 日志里反复报 connect timeout 到 database” 这类典型故障。
跨命名空间访问需用 namespaceSelector，别硬写 IP
有人试图用 ipBlock 直接写死 database Pod 的 IP 地址来实现跨 ns 访问，这在 Kubernetes 中是反模式：Pod IP 动态分配、生命周期短暂，策略会迅速失效。
正确方式是结合标签与命名空间选择器：
- 确保
database所在命名空间（如data）打了稳定标签，例如purpose: data-tier - 在
backend的 Ingress 规则中使用：from: [{namespaceSelector: {matchLabels: {purpose: data-tier}}, podSelector: {matchLabels: {app: postgres}}}] - 注意：
namespaceSelector和podSelector是嵌套关系，不是并列；前者选命名空间，后者在该命名空间内选 Pod
这个组合才是可维护、可扩展的零信任表达——它基于身份（标签）而非临时地址，也正因如此，NetworkPolicy 才能成为微隔离的基础设施，而不是又一套脆弱的 IP 黑白名单。
