发布于 由admin

Kubernetes 网络策略（Network Policy）高级模式与复杂场景应用

好的，各位观众老爷们，欢迎来到今天的“Kubernetes 网络策略高级进阶：织一张让Pod乖乖听话的网”专场！我是你们的老朋友，江湖人称“码农界段子手”的程序猿小K。今天咱们不聊那些虚头巴脑的概念，直接上干货，聊聊如何用 Kubernetes 的网络策略，玩转那些让人头疼的复杂网络场景。

开场白：网络策略，Pod的“行为规范”

想象一下，你的 Kubernetes 集群就像一个热闹的社区，里面住着各种各样的 Pod，它们各自负责不同的业务。如果没有网络策略，那就相当于这个社区没有“行为规范”，Pod们可以随意串门、聊天，甚至搞点小破坏。这显然是不行的！

网络策略就像是给每个Pod定制的“行为规范”，告诉它们哪些邻居可以访问，哪些邻居必须绕道走。有了它，你的集群才能秩序井然，安全可靠。

第一章：网络策略基础回顾：温故而知新

在深入高级玩法之前，咱们先快速回顾一下网络策略的基础知识，毕竟磨刀不误砍柴工嘛！

  • 什么是网络策略？

    网络策略（Network Policy）是 Kubernetes 提供的一种资源对象，用于控制 Pod 之间的网络流量。它定义了一组规则，指定哪些 Pod 可以访问哪些 Pod，以及Pod允许访问哪些外部服务。

  • 核心概念：

    • Pod Selector: 用于选择策略应用的目标 Pod。就像给一群小鸭子贴标签，告诉策略：“嘿，就是你们，听好了！”
    • Policy Types: 定义策略影响的流量类型，可以是 Ingress（入站流量）或 Egress（出站流量）或者两者皆有。
    • Ingress: 允许进入目标 Pod 的流量。相当于给Pod设置“访客名单”。
    • Egress: 允许目标 Pod 发出的流量。相当于给Pod颁发“通行证”。
    • IPBlock: 允许特定 IP 地址范围的流量。这个就像“国境线”，只有持有特定国家护照的才能通过。

  • 一个简单的例子：

    假设我们有一个名为 my-app 的 Deployment，想只允许来自 monitoring 命名空间中的 Pod 访问它。我们可以这样定义一个网络策略：

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring-access
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring

    这个策略的意思是：只允许来自 monitoring 命名空间中的 Pod 访问带有 app: my-app 标签的 Pod。

第二章：高级技巧：玩转网络策略的各种姿势

掌握了基础知识，咱们就可以开始解锁高级技巧了。接下来，咱们将深入探讨一些复杂的场景，并学习如何使用网络策略来应对它们。

  1. 跨命名空间访问控制：隔壁老王也得守规矩

    在实际应用中，Pod 往往分布在不同的命名空间中。如何控制不同命名空间之间的访问？这就要用到 namespaceSelector 和 podSelector 的组合拳了。

    假设我们有两个命名空间：production 和 staging。我们希望只允许 staging 命名空间中的 Pod 访问 production 命名空间中的数据库服务。我们可以这样配置：

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-staging-to-production-db
  namespace: production  # 注意，策略要部署在 production 命名空间下
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: staging

    这个策略部署在 production 命名空间中，它允许来自 staging 命名空间的所有 Pod 访问 production 命名空间中带有 app: database 标签的 Pod。即使隔壁老王（staging命名空间）想来串门，也得先看看有没有通行证！

  2. 基于标签的精细化控制：给Pod贴上“身份标签”

    除了命名空间，我们还可以使用标签（Labels）进行更精细的访问控制。这就像给每个 Pod 贴上一个“身份标签”，然后根据这些标签来决定是否允许访问。

    例如，我们想只允许具有 role: frontend 标签的 Pod 访问具有 role: backend 标签的 Pod。我们可以这样配置：

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

    这个策略只允许带有 role: frontend 标签的 Pod 访问带有 role: backend 标签的 Pod。其他 Pod 就算挤破头也进不来！

  3. Egress 策略：控制 Pod 的对外访问

    Ingress 策略控制的是进入 Pod 的流量，而 Egress 策略控制的是 Pod 发出的流量。这就像给 Pod 安装了一个“防火墙”，限制它们可以访问哪些外部服务。

    例如，我们想只允许 Pod 访问特定的外部 API，可以这样配置：

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-external-api
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32  # 允许访问 Google DNS
    ports:
    - protocol: UDP
      port: 53

    这个策略只允许带有 app: my-app 标签的 Pod 访问 8.8.8.8 (Google DNS) 的 UDP 53 端口。其他外部服务，一律禁止！

  4. 使用 IPBlock 控制外部流量：守好“国境线”

    IPBlock 允许我们基于 IP 地址范围来控制流量。这在需要限制特定 IP 地址或 IP 地址段访问集群内部服务时非常有用。

    例如，我们想只允许来自公司内部网络的流量访问我们的应用：

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal-network-access
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/16  # 允许 10.0.0.0/16 网段的流量

    这个策略只允许来自 10.0.0.0/16 网段的流量访问带有 app: my-app 标签的 Pod。其他 IP 地址，统统拦截！

  5. Default Deny Policy：默认拒绝一切，安全至上！

    在生产环境中，强烈建议配置一个 “Default Deny” 策略。这意味着，如果没有明确允许，所有流量都将被拒绝。这就像给集群设置了一个“安全锁”，确保只有经过授权的流量才能通过。

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

    这两个策略分别拒绝所有 Ingress 和 Egress 流量。注意，它们需要部署在集群中的每个命名空间中，才能真正生效。

第三章：复杂场景应用：实战演练

理论知识学了一大堆，是时候来点实战了。下面，咱们将模拟几个常见的复杂场景，并学习如何使用网络策略来解决它们。

  1. 微服务架构：服务之间的精细化访问控制

    在微服务架构中，各个服务之间需要进行频繁的通信。我们需要使用网络策略来确保只有授权的服务才能相互访问。

    假设我们有三个微服务：frontend、backend 和 database。frontend 需要访问 backend，backend 需要访问 database，而 frontend 不应该直接访问 database。我们可以这样配置：

    # frontend 允许访问 backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
---
# backend 允许访问 database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

    这样，我们就实现了服务之间的精细化访问控制。frontend 只能访问 backend，backend 只能访问 database，而 frontend 无法直接访问 database。

  2. 多租户环境：租户之间的隔离

    在多租户环境中，我们需要确保不同租户之间的资源是隔离的，防止相互干扰。网络策略可以帮助我们实现这一目标。

    假设我们有两个租户：tenant-a 和 tenant-b，分别对应两个命名空间。我们可以配置网络策略，确保 tenant-a 中的 Pod 只能访问 tenant-a 中的 Pod，tenant-b 中的 Pod 只能访问 tenant-b 中的 Pod。

    # tenant-a 命名空间下的策略：只允许 tenant-a 内部访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-tenant-a-internal-access
  namespace: tenant-a
spec:
  podSelector: {}  # 匹配所有 Pod
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector: {} # 匹配所有 Pod
  egress:
  - to:
    - podSelector: {} # 匹配所有 Pod
---
# tenant-b 命名空间下的策略：只允许 tenant-b 内部访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-tenant-b-internal-access
  namespace: tenant-b
spec:
  podSelector: {}  # 匹配所有 Pod
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector: {} # 匹配所有 Pod
  egress:
  - to:
    - podSelector: {} # 匹配所有 Pod

    这两个策略分别部署在 tenant-a 和 tenant-b 命名空间下，它们只允许来自同一命名空间内的 Pod 访问。这样就实现了租户之间的隔离。

  3. 灰度发布：控制流量逐步迁移

    在灰度发布过程中，我们需要逐步将流量从旧版本迁移到新版本，以便观察新版本的运行情况。网络策略可以帮助我们实现这一目标。

    假设我们有一个应用，正在进行灰度发布。我们有两个版本的 Pod：v1 和 v2。我们希望先将 10% 的流量导向 v2，然后逐步增加到 100%。

    首先，给 v1 和 v2 的 Pod 打上不同的标签：

    • v1：version: v1
    • v2：version: v2

    然后，配置一个网络策略，将部分流量导向 v2：

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-traffic-to-v2
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          version: v2
    ports:
    - protocol: TCP
      port: 80

    这个策略将所有来自带有 version: v2 标签的 Pod 的流量导向带有 app: my-app 标签的 Pod。要实现 10% 的流量导向 v2，你需要结合 Service Mesh (例如 Istio) 或者 Ingress Controller 的流量管理功能，例如使用 weight 权重配置。网络策略只负责允许流量，流量的比例分配需要其他组件配合。

第四章：常见问题与注意事项：避坑指南

使用网络策略的过程中，可能会遇到一些问题。下面是一些常见的坑，以及如何避免它们：

  • 网络插件支持： 确保你的 Kubernetes 集群使用的网络插件支持网络策略。常见的支持网络策略的网络插件包括 Calico, Cilium, Weave Net 等。
  • 策略生效顺序： 网络策略的生效顺序是不确定的。因此，不要依赖策略的顺序来控制流量。
  • 策略冲突： 多个网络策略可能会发生冲突。例如，一个策略允许某个流量，另一个策略拒绝该流量。在这种情况下，流量会被拒绝，因为 “deny” 策略优先级高于 “allow” 策略。
  • 监控与调试： 使用网络策略后，要密切监控集群的网络流量，以便及时发现问题。可以使用工具如 kubectl describe networkpolicy 来查看策略的详细信息，以及使用网络流量分析工具来分析流量。
  • 测试： 在生产环境中应用网络策略之前，一定要进行充分的测试，确保策略符合预期。可以使用工具如 nsenter 进入 Pod 的网络命名空间，然后使用 ping 或 telnet 命令来测试网络连接。
  • 维护成本： 网络策略会增加集群的维护成本。因此，要谨慎使用网络策略，只在必要的时候才应用它们。

总结：网络策略，集群安全的守护神

网络策略是 Kubernetes 中一个强大的工具，可以帮助我们实现精细化的网络访问控制，提高集群的安全性。掌握网络策略的各种技巧，可以让我们更好地应对复杂的网络场景，让我们的 Kubernetes 集群更加安全、可靠。

好了，今天的分享就到这里。希望大家能够学有所获，在实际应用中灵活运用网络策略，打造一个安全、高效的 Kubernetes 集群。

如果大家觉得今天的分享对您有所帮助，不妨点个赞，加个关注，以后我会继续分享更多 Kubernetes 的干货知识。咱们下期再见！👋

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注