Networkpolicy

NetworkPolicy 实现 Pod 间隔离 时，可以从 原理、实践、选型 三个维度展开回答，突出你的技术理解和实战经验。以下是结构化回答建议：

---

1. 核心原理（展示底层理解）

"NetworkPolicy 是 Kubernetes 原生的 Pod 网络隔离机制，本质是通过 CNI 插件（如 Calico、Cilium）在底层实现流量规则。它的核心逻辑是：

• 选择器（Selector）：通过 podSelector 或 namespaceSelector 匹配目标 Pod。
• 规则类型：
  • ingress：控制谁可以访问目标 Pod（入站规则）。
  • egress：控制目标 Pod 可以访问谁（出站规则）。
• 默认行为：
  • 如果未定义任何 NetworkPolicy，所有 Pod 默认允许所有进出流量（Allow All）。
  • 一旦为某个 Namespace 创建了 NetworkPolicy，该 Namespace 的 Pod 会默认拒绝所有流量（Deny All），除非显式放行。"

示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend  # 目标Pod
  policyTypes:
  - ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend  # 仅允许来自frontend的流量
    ports:
    - protocol: TCP
      port: 6379

---

2. 实战场景（结合项目经验）

(1) 典型应用场景

"我们在生产环境中用 NetworkPolicy 解决过以下问题：

• 微服务隔离：只允许 order-service 访问 payment-service，禁止其他服务直接调用。
• 数据库保护：仅允许特定标签的 Pod（如 app=api）访问 MySQL 的 3306 端口。
• 多租户隔离：通过 namespaceSelector 限制不同团队的 Pod 互相访问。"

(2) 排查工具

"调试 NetworkPolicy 时常用工具：

• calicoctl：查看 Calico 生成的最终规则（calicoctl get networkpolicy -o yaml）。
• kubectl describe networkpolicy：确认策略是否生效。
• tcpdump：在 Pod 内抓包验证流量是否被拦截。"

(3) 常见坑点

"我们曾遇到一个故障：

• 现象：NetworkPolicy 配置后，Pod 无法访问 kube-dns（CoreDNS）。
• 原因：未放行 UDP 53 端口的出口流量。
• 修复：添加 egress 规则允许访问 kube-system 命名空间的 CoreDNS Pod。"

---

3. CNI 插件选型对比（体现技术决策能力）

CNI 插件	NetworkPolicy 支持度	适用场景
Calico	完整支持（基于 iptables/IPVS）	需要复杂策略的中大型集群
Cilium	支持（基于 eBPF，性能更高）	高性能场景（如服务网格）
Flannel	不支持	仅需基础网络的测试环境
Weave Net	部分支持（性能较差）	小规模集群

选型理由：
"我们选择 Calico 是因为：

1. 社区活跃，兼容性经过验证（与 Kubernetes 版本严格匹配）。
2. 支持 deny 规则（Cilium 也支持，但 Flannel 完全不行）。
3. 可视化工具（如 Calico UI）便于策略审计。"

---

4. 面试回答示例

面试官：
“你们如何用 NetworkPolicy 实现 Pod 隔离？遇到过什么问题？”

回答：
“我们分三步实现隔离：

1. 规划策略：
   • 例如禁止 default 命名空间的 Pod 访问 prod-db 命名空间的 PostgreSQL。
2. 编写策略：

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: deny-default-to-proddb
     namespace: prod-db
   spec:
     podSelector: {}  # 匹配所有Pod
     policyTypes: [ingress]
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             env: prod  # 仅允许prod命名空间访问
   

3. 验证与排障：
   • 用 kubectl exec 进入测试 Pod，尝试 telnet <db-pod-ip> 5432。
   • 如果失败，通过 calicoctl 检查规则是否下发。

遇到的典型问题：

• 初期未放行 CoreDNS 的 UDP 端口，导致 Pod 无法解析域名。后来通过添加 egress 规则解决：

  - to:
    - namespaceSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
  

---

5. 可能追问与应对

1. “NetworkPolicy 和 Service Mesh 的 mTLS 有什么区别？”
   → “NetworkPolicy 是 L3/L4 层（IP/端口）隔离，而 mTLS 是 L7 层（应用协议）加密+认证。两者可叠加使用。”

2. “如何实现跨集群的 NetworkPolicy？”
   → “需依赖全局网络方案（如 Calico 的 GlobalNetworkPolicy 或 Cilium ClusterMesh）。”

3. “NetworkPolicy 对性能的影响？”
   → “Calico 的 iptables 规则在规模超过 1000 条时可能出现延迟，此时可切换到 Cilium eBPF 模式。”

---

总结回答要点

• 原理：说清 Selector 和默认行为。
• 实战：举例说明策略编写和排障过程。
• 深度：对比不同 CNI 插件的支持差异。
• 反思：分享实际遇到的坑及解决方案。