容器网络策略（NetworkPolicy）精细化控制

好的，各位老铁们，大家好！我是你们的老朋友——码农老王。今天咱们来聊聊 Kubernetes 里一个相当重要，但又经常被忽略的家伙：容器网络策略（NetworkPolicy）。

想象一下，你家小区装了智能门禁，理论上只有住户才能自由进出。但如果物业告诉你，所有人都畅通无阻，那这门禁还有啥用？ 容器网络策略就相当于 Kubernetes 集群里的门禁，它能让你精细地控制 Pod 之间的网络流量，确保只有授权的 Pod 才能互相访问。

一、为啥要用 NetworkPolicy？不用行不行？

有些小伙伴可能会问：“我集群里跑着几个服务，跑得好好的，没设置 NetworkPolicy，也没出啥问题啊？为啥要用这玩意儿？”

问得好！这就像你新买的房子，还没装修，水电煤气都通了，也能住。但你总不能一直住毛坯房吧？

默认情况下，Kubernetes 集群里的所有 Pod 都可以自由地互相通信。 这固然方便，但也带来了潜在的风险，例如：

• 安全漏洞扩散: 假设你的某个 Pod 存在安全漏洞，攻击者可以通过该漏洞轻松地访问集群里的其他 Pod，横向移动，造成更大的损失。
• 误操作影响: 程序员手抖了一下，把某个 Pod 的配置搞错了，可能会导致它错误地访问到其他 Pod，影响整个系统的稳定性。
• 合规性要求: 某些行业（例如金融、医疗）对数据安全有严格的合规性要求，需要对网络流量进行精细的控制和审计。

所以，即使你的集群现在运行良好，也应该尽早考虑使用 NetworkPolicy，防患于未然。 亡羊补牢，犹未晚矣，但不如未雨绸缪。

二、NetworkPolicy 是个啥？长啥样？

NetworkPolicy 本质上是一个 Kubernetes 资源对象，它定义了一组规则，用于控制 Pod 的网络流量。 它的 YAML 文件大概长这样：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: my-app # 匹配哪些 Pod 应用此策略
  policyTypes:
  - Ingress # 入站规则
  - Egress  # 出站规则
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: other-app # 允许来自哪些 Pod 的流量
    ports:
    - protocol: TCP
      port: 8080 # 允许哪些端口的流量
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/16 # 允许到哪些 IP 地址段的流量
    ports:
    - protocol: UDP
      port: 53 # 允许到哪些端口的流量

是不是感觉有点像防火墙规则？没错，NetworkPolicy 的作用就类似于防火墙，只不过它是针对 Pod 级别的。

我们来逐行解读一下这个 YAML 文件：

• apiVersion: networking.k8s.io/v1 和 kind: NetworkPolicy： 这两行定义了 API 版本和资源类型，固定写法。
• metadata： 包含了 NetworkPolicy 的名称和命名空间。 命名空间很重要，NetworkPolicy 只会影响它所在的命名空间内的 Pod。

• spec： 这是 NetworkPolicy 的核心部分，包含了策略的详细定义。

  • podSelector： 使用 Label Selector 匹配哪些 Pod 应用此策略。只有满足 matchLabels 条件的 Pod 才会受到此策略的约束。
  • policyTypes： 指定策略的类型，可以是 Ingress（入站规则）、Egress（出站规则），或者两者都有。
  • ingress： 定义入站规则，控制允许哪些流量进入 Pod。
    • from： 指定允许流量的来源，可以使用 podSelector、namespaceSelector（选择命名空间）、ipBlock（选择 IP 地址段）等方式。
    • ports： 指定允许流量的端口和协议。
  • egress： 定义出站规则，控制允许 Pod 发送到哪些目标的流量。
    • to： 指定允许流量的目标，可以使用 podSelector、namespaceSelector、ipBlock 等方式。
    • ports： 指定允许流量的端口和协议。

三、NetworkPolicy 的几种常见用法

掌握了 NetworkPolicy 的基本概念，接下来我们来看看几种常见的用法。

1. 默认拒绝所有流量

这是最安全的一种策略，它会阻止所有 Pod 之间的流量，除非显式地允许。 就像你家的门禁，默认情况下禁止所有人进入，只有登记过的住户才能刷卡进入。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {} # 匹配所有 Pod
  policyTypes:
  - Ingress
  - Egress

这个策略的 podSelector 为空，表示匹配所有 Pod。 policyTypes 同时指定了 Ingress 和 Egress，但 ingress 和 egress 部分都为空，表示拒绝所有入站和出站流量。

应用了这个策略后，集群里的所有 Pod 都无法互相访问，也无法访问外部网络。 如果你想允许某些 Pod 之间的通信，或者允许 Pod 访问外部网络，需要显式地添加规则。

2. 允许同一命名空间内的 Pod 互相访问

有时候，你希望同一命名空间内的 Pod 能够自由地互相访问，但阻止跨命名空间的访问。 这就像你家的小区，允许住户在小区内自由活动，但禁止进入其他小区。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
spec:
  podSelector: {} # 匹配所有 Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {} # 允许来自同一命名空间内所有 Pod 的流量

这个策略的 podSelector 匹配所有 Pod，ingress 部分的 from 使用了空的 podSelector，表示允许来自同一命名空间内所有 Pod 的流量。

3. 允许特定 Pod 访问特定 Pod

这是最常见的用法，它允许特定的 Pod 访问特定的 Pod，实现精细化的访问控制。 这就像你家的门禁，只允许特定的访客进入。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend # 应用于 backend Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend # 允许来自 frontend Pod 的流量
    ports:
    - protocol: TCP
      port: 8080 # 允许 8080 端口的流量

这个策略的 podSelector 匹配 Label 为 app: backend 的 Pod，ingress 部分的 from 使用了 podSelector，匹配 Label 为 app: frontend 的 Pod。 这表示只允许 Label 为 app: frontend 的 Pod 访问 Label 为 app: backend 的 Pod 的 8080 端口。

4. 允许 Pod 访问外部服务

有时候，你需要允许 Pod 访问外部服务，例如数据库、消息队列等。 这就像你家的小区，允许住户外出购物、就医等。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-external-db
spec:
  podSelector:
    matchLabels:
      app: my-app # 应用于 my-app Pod
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.0/24 # 允许访问 192.168.1.0/24 网段的 IP 地址
    ports:
    - protocol: TCP
      port: 3306 # 允许访问 3306 端口

这个策略的 podSelector 匹配 Label 为 app: my-app 的 Pod，egress 部分的 to 使用了 ipBlock，指定允许访问的 IP 地址段为 192.168.1.0/24，端口为 3306。 这表示只允许 Label 为 app: my-app 的 Pod 访问 192.168.1.0/24 网段的 3306 端口。

四、NetworkPolicy 的注意事项

在使用 NetworkPolicy 的时候，有一些注意事项需要牢记：

1. 需要网络插件的支持

NetworkPolicy 并不是 Kubernetes 内置的功能，它需要网络插件的支持才能生效。 常用的网络插件，例如 Calico、Cilium、Weave Net 等，都支持 NetworkPolicy。

如果你没有安装支持 NetworkPolicy 的网络插件，即使你创建了 NetworkPolicy，也不会生效。

2. 策略是累加的

当多个 NetworkPolicy 应用于同一个 Pod 时，它们的规则是累加的。 也就是说，只要其中一个策略允许某个流量，该流量就会被允许。

这就像你家的门禁，如果物业同时发布了多个策略，只要其中一个策略允许访客进入，访客就可以进入。

3. 策略是基于 Label 的

NetworkPolicy 使用 Label Selector 来匹配 Pod，因此确保你的 Pod 都打上了正确的 Label。 如果你的 Label 打错了，NetworkPolicy 可能无法正确地应用。

4. 策略是命名空间级别的

NetworkPolicy 只会影响它所在的命名空间内的 Pod。 如果你想控制跨命名空间的流量，需要使用 namespaceSelector。

5. 测试！测试！再测试！

在生产环境应用 NetworkPolicy 之前，一定要在测试环境进行充分的测试。 确保你的策略能够正确地控制流量，并且不会影响应用的正常运行。

五、NetworkPolicy 的高级用法

掌握了 NetworkPolicy 的基本用法，我们再来看看一些高级用法。

1. 使用 namespaceSelector 控制跨命名空间的流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend-across-namespaces
spec:
  podSelector:
    matchLabels:
      app: backend # 应用于 backend Pod
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          environment: production # 允许来自 production 命名空间的流量
      podSelector:
        matchLabels:
          app: frontend # 允许来自 frontend Pod 的流量
    ports:
    - protocol: TCP
      port: 8080 # 允许 8080 端口的流量

这个策略的 ingress 部分的 from 同时使用了 namespaceSelector 和 podSelector。 namespaceSelector 匹配 Label 为 environment: production 的命名空间，podSelector 匹配 Label 为 app: frontend 的 Pod。 这表示只允许来自 Label 为 environment: production 的命名空间内，Label 为 app: frontend 的 Pod 访问 Label 为 app: backend 的 Pod 的 8080 端口。

2. 使用 ipBlock 控制外部流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-specific-ips
spec:
  podSelector:
    matchLabels:
      app: my-app # 应用于 my-app Pod
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32 # 允许访问 8.8.8.8 这个 IP 地址
    ports:
    - protocol: UDP
      port: 53 # 允许访问 53 端口

这个策略的 egress 部分的 to 使用了 ipBlock，指定允许访问的 IP 地址为 8.8.8.8，端口为 53。 这表示只允许 Label 为 app: my-app 的 Pod 访问 8.8.8.8 的 53 端口。

3. 使用预定义的网络策略资源（GlobalNetworkPolicy）

有些网络插件，例如 Calico，支持预定义的网络策略资源，例如 GlobalNetworkPolicy。 这些资源可以应用于整个集群，而不仅仅是单个命名空间。

这就像你家的小区，物业可以发布全局的门禁策略，例如禁止所有车辆进入小区绿地。

六、NetworkPolicy 的未来发展

随着 Kubernetes 的不断发展，NetworkPolicy 也在不断进化。 未来，NetworkPolicy 可能会朝着以下几个方向发展：

1. 更强大的策略表达能力

未来的 NetworkPolicy 可能会支持更复杂的策略表达方式，例如使用正则表达式匹配 Label，使用更灵活的 IP 地址范围匹配等。

2. 更智能的策略管理

未来的 NetworkPolicy 可能会集成 AI 技术，自动学习应用的流量模式，并生成合理的 NetworkPolicy。

3. 更完善的策略审计

未来的 NetworkPolicy 可能会提供更完善的策略审计功能，记录所有网络流量的访问日志，方便排查问题和进行安全分析。

七、总结

今天，我们一起深入探讨了 Kubernetes 的容器网络策略（NetworkPolicy）。 希望通过今天的讲解，你能对 NetworkPolicy 有更深入的了解，并在实际工作中灵活运用它，保护你的 Kubernetes 集群安全。

记住，安全无小事，防患于未然！

最后，感谢各位老铁的观看，我们下期再见！ 👋

表格总结：

特性	描述	优势	适用场景
默认拒绝策略	阻止所有流量，除非显式允许	最安全，防止未经授权的访问	对安全性要求极高的环境，例如金融、医疗等
同命名空间内互访	允许同一命名空间内的 Pod 互相访问	简化同一应用内的服务间通信	同一应用部署在同一命名空间内，需要服务间自由通信
特定 Pod 互访	允许特定 Pod 访问特定 Pod	精细化的访问控制，最小化攻击面	需要严格控制服务间访问权限的环境，例如前端只能访问后端，监控只能访问数据库等
允许访问外部服务	允许 Pod 访问外部服务	允许应用访问外部依赖，例如数据库、消息队列等	需要访问外部服务的应用，例如访问云数据库、第三方 API 等
namespaceSelector	控制跨命名空间的流量	允许跨命名空间的服务互相访问	多命名空间环境，需要跨命名空间的服务互相访问
ipBlock	控制外部流量	允许 Pod 访问特定的 IP 地址或地址段	需要访问特定 IP 地址的外部服务，例如特定的数据库服务器

修辞手法:

• 比喻: 将 NetworkPolicy 比作门禁、防火墙等，更容易理解。
• 拟人: 将 Kubernetes 集群比作小区，将 Pod 比作住户，更生动形象。
• 反问: "不用行不行？" 引发思考，强调 NetworkPolicy 的重要性。
• 排比: "安全漏洞扩散、误操作影响、合规性要求" 增强语气，强调安全风险。
• 引用: "亡羊补牢，犹未晚矣，但不如未雨绸缪" 增加文章的文化底蕴。

希望这篇文章对你有所帮助！如果有什么问题，欢迎随时提问。 😊