Kubernetes 网络模型与网络策略详解

CarlowZJ

已于 2025-05-18 19:59:54 修改

阅读量703

点赞数 11

分类专栏：运维文章标签： kubernetes 网络 php

于 2025-05-16 00:01:36 首次发布

本文链接：https://blog.youkuaiyun.com/csdn122345/article/details/147994747

版权

运维专栏收录该内容

16 篇文章

订阅专栏

摘要：网络是 Kubernetes（K8s）集群中容器通信的核心，本文深入探讨 K8s 网络模型、网络插件及网络策略，助力读者构建高效、安全的集群网络环境。通过概念讲解、配置示例与应用场景分析，结合架构图和流程图，全面揭示 K8s 网络的运作机制与实践方法。

一、Kubernetes 网络模型基础

（一）K8s 网络模型核心原则

Kubernetes 的网络模型基于以下几个核心原则：

Pod 网络互联：每个 Pod 都拥有一个独立的 IP 地址，同一节点内的 Pod 可以直接通过各自的 IP 地址进行通信，无需额外的网络地址转换（NAT）或端口映射。这使得 Pod 之间的通信简洁高效，如同位于同一局域网内的主机通信。
跨节点 Pod 通信：不同节点上的 Pod 也能直接通过 IP 地址相互通信，就好像它们位于同一个扁平网络中。K8s 集群内的网络基础设施需要确保这一点，无论 Pod 部署在哪个节点，都能实现无缝的网络连接。
Service 的稳定网络标识： Service 作为 Pod 的逻辑集合抽象，被分配一个稳定的集群内部 IP 地址（Cluster IP）。外部流量可以通过这个 Cluster IP 访问 Service 所代表的一组 Pod，而无需关心后端 Pod 的具体 IP 地址变化。Service 实现了对后端 Pod 的负载均衡和流量分发功能。

（二）K8s 网络模型的优势

简化应用开发与部署：开发者在编写应用时，无需过多考虑复杂的网络拓扑和通信细节，只要知道 Pod 和 Service 的 IP 地址，就可以像在传统网络环境中一样进行应用开发和部署。例如，在一个分布式应用中，前端服务可以通过直接访问后端服务的 Service IP 地址进行通信，无需处理 Pod 岳变化带来的连接问题。
支持弹性伸缩：当应用的副本数量发生变化（如通过 Deployment 进行扩缩容），新的 Pod 可以迅速加入到 Service 的后端列表中，或者从列表中移除。由于 Service 的 Cluster IP 保持不变，外部调用方无需关心这些变化，从而实现了应用的无缝弹性伸缩。

（三）K8s 网络数据流向

一个典型的网络数据流向是：外部流量首先进入集群的入口点（如负载均衡器），然后根据 Service 的配置将流量分发到对应的后端 Pod 上。在 Pod 内部，容器之间可以直接通过localhost进行通信。K8s 网络模型确保了在整个数据传输过程中，各层级的网络通信都畅通无阻。

二、常见网络插件介绍与选择

（一）Flannel 网络插件

工作原理： Flannel 是一个流行的 K8s 网络插件，它为每个节点分配一个子网，并通过覆盖网络（Overlay Network）技术实现跨节点的 Pod 通信。Flannel 在每个节点上运行一个 agent 进程，负责在宿主机网络和 Pod 网络之间进行数据帧的封装和解封装。例如，当一个 Pod 向另一个节点上的 Pod 发送数据时，数据帧会被 Flannel agent 封装成宿主机网络能够识别的格式进行传输，到达目标节点后，再由该节点的 Flannel agent 解封装并转发给目标 Pod。
适用场景与优缺点： Flannel 适用于小型到中型规模的 K8s 集群，其优点是部署简单、易于配置，能够快速搭建起 K8s 网络环境。然而，Flannel 在大规模集群或高性能网络场景下可能会面临一些挑战，如网络性能开销较大、网络隔离性相对较弱等。

（二）Calico 网络插件

工作原理： Calico 基于 BGP（边界网关协议）实现网络路由，它在每个节点上运行 BGP 客户端，与宿主机的路由守护进程进行通信，从而建立起集群范围内的路由表。Calico 直接利用宿主机的网络内核功能进行数据包的转发和过滤，避免了数据封装和解封装的开销，提供了高性能的 Pod 到 Pod 通信能力。同时，Calico 还支持强大的网络策略功能，可以精细地控制网络流量的访问权限。
适用场景与优缺点： Calico 适合于大规模 K8s 集群和对网络安全要求较高的场景。它的优点包括高性能、良好的网络隔离性和强大的安全策略支持。缺点是部署和配置相对复杂，需要一定的网络专业知识来正确设置 BGP 参数和网络策略规则。

（三）Weave 网络插件

工作原理： Weave 创建一个虚拟网络，在每个节点上运行 Weave agent，负责将本地 Pod 网络与集群中的其他节点网络连接起来。Weave 支持多种网络模式，包括直接路由模式和 Overlay 模式。在 Overlay 模式下，它对网络数据进行加密和封装，确保数据在不可信网络中的安全传输。Weave 还提供了服务发现和网络诊断工具，方便用户管理和排查网络问题。
适用场景与优缺点： Weave 适用于多云环境和混合云环境下的 K8s 集群部署，其优点是具备良好的跨网络通信能力和网络诊断功能。但与 Flannel 和 Calico 相比，Weave 在大规模集群中的性能表现可能稍逊一筹，且其复杂的网络模式选择和配置可能会增加用户的使用难度。

（四）网络插件选择指南

在选择 K8s 网络插件时，需要综合考虑以下因素：

集群规模与性能需求：对于小型到中型集群，Flannel 是一个简单易用的选择；而对于大规模集群或对网络性能要求极高的场景，Calico 更为合适。
网络安全需求：如果对网络隔离和安全策略有较高要求，Calico 和 Weave 都提供了强大的安全功能，其中 Calico 的网络策略功能尤为突出。
网络环境复杂性：在多云或混合云环境中，Weave 的跨网络通信能力和网络诊断工具能够提供便利；而在相对简单的单云或本地数据中心环境中，Flannel 和 Calico 的部署和管理可能更为高效。
集成与扩展性：考虑网络插件与其他 K8s 组件（如服务网格、监控系统等）的集成能力，以及是否支持未来的扩展需求，如与其他云原生技术的融合。

三、Kubernetes 网络策略详解

（一）网络策略的作用与意义

网络策略（NetworkPolicy）是 K8s 提供的一种控制 Pod 之间以及 Pod 与外部网络之间通信的机制。在默认情况下，K8s 集群中的所有 Pod 都可以自由通信，这在某些场景下可能会带来安全隐患，例如敏感服务的 Pod 可能会受到未授权的访问。通过网络策略，用户可以定义精细化的访问控制规则，限制特定 Pod 的入站和出站流量，从而增强集群的网络安全防护能力。

（二）网络策略资源定义与配置

NetworkPolicy 资源结构： NetworkPolicy 资源主要包含以下几个关键部分：
- spec.podSelector：定义该网络策略适用的 Pod 集合，通过标签选择器来指定。例如，matchLabels: { "app": "frontend" } 表示该策略适用于标签为 app=frontend 的 Pod。
- spec.ingress：定义允许进入 Pod 的流量规则。每个 ingress 规则可以指定来源（from）、端口（ports）等条件。例如
```
ingress:
- from:
  - podSelector:
      matchLabels:
        app: backend
  ports:
  - protocol: TCP
    port: 8080
```
  表示允许来自标签为 app=backend 的 Pod 对本策略 Pod 的 8080 端口的 TCP 入站流量。
- spec.egress：定义允许从 Pod 发出的流量规则，与 ingress 类似，但关注的是出站流量的方向和端口等。
网络策略配置示例：以下是一个完整的 NetworkPolicy 配置示例，用于限制某个服务的后端 Pod 只能被该服务的前端 Pod 访问，并且只能通过特定的端口进行通信
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-ingress
  namespace: your-namespace
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
```
此配置将适用于 your-namespace 命名空间中标签为 app=backend 的 Pod，只允许来自 app=frontend 的 Pod 对其 8080 端口的 TCP 入站流量。

（三）网络策略的实施与注意事项

网络插件支持：并非所有的 K8s 网络插件都支持网络策略。在使用网络策略之前，需要确保所选用的网络插件（如 Calico、Cilium 等）支持 NetworkPolicy API，并正确配置了相关的策略执行功能。例如，Calico 需要启用网络策略控制器才能使网络策略生效。
命名空间隔离与网络策略：在多租户环境中，通常会使用命名空间（Namespace）来隔离不同的租户资源。网络策略通常在命名空间范围内生效，因此需要合理规划命名空间的网络策略，避免租户之间不必要的网络访问。例如，可以为每个租户的命名空间制定默认的网络策略，拒绝来自其他命名空间的访问，除非有明确的业务需求和授权。
网络策略的优先级与冲突解决：当存在多个网络策略作用于同一个 Pod 或命名空间时，需要明确网络策略的优先级和冲突解决机制。一般来说，网络策略的优先级可以通过策略创建的时间顺序或特定的优先级标签来确定，但不同网络插件的实现可能会有所差异。在配置多个网络策略时，要仔细测试和验证策略的实际效果，确保没有产生意外的访问控制冲突。

四、网络策略应用场景与案例分析

（一）微服务架构中的服务间通信安全

场景描述：在微服务架构下，多个服务之间存在复杂的调用关系。例如，一个电商平台包含用户服务、订单服务、支付服务、库存服务等多个微服务，每个微服务由多个 Pod 组成。需要确保每个微服务只能被授权的其他微服务访问，防止未经授权的调用和数据泄露。
网络策略应用方法：为每个微服务的 Pod 配置相应的网络策略，允许来自特定微服务的入站流量。例如，为订单服务的 Pod 配置如下网络策略
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-order-service-ingress
  namespace: e-commerce
spec:
  podSelector:
    matchLabels:
      app: order-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: user-service
    - podSelector:
        matchLabels:
          app: payment-service
    ports:
    - protocol: TCP
      port: 8080
```
该策略允许用户服务和支付服务的 Pod 对订单服务的 8080 端口进行入站访问，其他服务的 Pod 则无法访问。通过这种方式，可以构建起微服务之间的安全通信拓扑，保障每个服务只暴露必要的接口给授权的调用者。

（二）限制数据访问的服务网络隔离

场景描述：某企业应用中，存在一个敏感数据处理服务和多个普通业务服务。敏感数据处理服务需要访问企业的核心数据库，而普通业务服务只能访问各自的业务数据库。必须确保普通业务服务无法访问敏感数据处理服务的网络通信，防止潜在的数据泄露风险。

网络策略应用方法：为敏感数据处理服务的 Pod 创建一个严格的网络策略，只允许来自企业核心数据库服务的入站流量，并且限制其出站流量只能访问核心数据库服务。例如：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sensitive-data-service-isolation
  namespace: enterprise-app
spec:
  podSelector:
    matchLabels:
      app: sensitive-data-service
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: core-database
    ports:
    - protocol: TCP
      port: 3306
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: core-database
    ports:
    - protocol: TCP
      port: 3306

同时，为普通业务服务的 Pod 配置网络策略，拒绝其访问敏感数据处理服务的端口。通过这些网络策略的组合应用，实现了敏感数据服务与其他普通业务服务的网络隔离，降低了数据泄露的风险。

（三）多环境部署的网络访问控制

场景描述：企业在开发、测试、生产三个不同的环境中部署了相同的应用。开发环境用于快速迭代和功能开发，测试环境用于应用测试和验证，生产环境运行正式对外服务。需要确保开发环境的 Pod 不能访问测试和生产环境的资源，测试环境的 Pod 只能访问开发环境和特定的测试支持服务，生产环境的 Pod 则具有最高的访问权限但也要遵循最小权限原则。
网络策略应用方法：利用命名空间来隔离不同的环境，并为每个命名空间配置相应的网络策略。例如，开发环境命名空间为 dev，测试环境为 test，生产环境为 prod。在 dev 命名空间中，配置网络策略拒绝出站流量到 test 和 prod 命名空间中的资源；在 test 命名空间中，配置网络策略允许入站流量来自 dev 命名空间，并允许出站流量到 dev 命名空间和特定的测试支持服务命名空间；在 prod 命名空间中，根据生产应用的实际情况，为每个服务配置精细的网络策略，只允许必要的入站和出站流量。通过这种基于命名空间的网络策略配置，实现了多环境部署下的网络访问控制，保障了应用在不同环境中的安全性和独立性。

五、注意事项与最佳实践

（一）网络策略的渐进式实施

在复杂的 K8s 集群环境中，不要一次性实施大量的网络策略，这可能会导致应用通信大面积中断和难以排查的问题。建议采用渐进式的方式实施网络策略：

先进行充分的测试：在实施网络策略之前，在测试环境中对策略进行充分的测试，验证其对应用通信的实际影响。可以使用工具（如 kubectl exec 进入 Pod 内部，使用 curl、telnet 等命令测试网络连通性）来模拟应用的网络请求，确保网络策略按预期工作。
从小范围开始实施：从一些非关键业务的 Pod 或命名空间开始实施网络策略，观察应用运行情况和网络通信变化。逐步扩大实施范围，每次实施新的网络策略后，都要进行全面的测试和监控，确保应用的正常运行。
持续监控与调整：实施网络策略后，持续监控应用的网络通信指标（如流量、延迟、错误率等）和业务指标（如用户访问量、订单处理成功率等），根据实际监控数据和业务需求，及时调整网络策略，优化访问控制规则。

（二）网络策略的可维护性

合理命名与文档记录：为网络策略资源设置清晰、有意义的名称，便于理解和管理。同时，维护一份详细的网络策略文档，记录每个网络策略的目的、适用范围、配置细节以及变更历史。这有助于团队成员之间的协作和知识传承，方便在出现网络问题时快速定位和解决。
模块化与重用：尽量将网络策略配置进行模块化设计，提取通用的访问控制规则模板，以便在不同的 Pod 或命名空间中重用。例如，可以创建一个基础的网络策略模板，用于限制特定端口的入站流量，然后在不同的服务网络策略中引用该模板并根据需要进行定制化修改。这不仅减少了重复配置的工作量，也提高了网络策略的一致性和可维护性。

（三）与服务网格的结合

在复杂的微服务场景下，可以考虑结合服务网格（如 Istio）一起使用。服务网格提供了更强大的网络流量管理功能，如细粒度的流量控制、故障注入、安全的 mTLS 通信等。网络策略和服务网格在网络安全防护上可以形成互补：

网络策略负责边界防护：通过网络策略在集群层面限制不同服务、命名空间之间的网络访问边界，阻止未经授权的流量进入特定服务区域。
服务网格进行内部流量精细化管理：在服务网格内部，可以进一步对授权流量进行精细化的流量控制和安全策略实施，如基于服务调用的认证、授权、加密，以及基于流量特征的路由规则等。例如，使用 Istio 的 AuthorizationPolicy 资源在服务调用级别进行访问控制，结合网络策略构建起多层次的网络安全防护体系。

六、总结

本文深入剖析了 Kubernetes（K8s）的网络模型和网络策略，涵盖了 K8s 网络模型的核心原则和优势、常见网络插件的特点与选择方法、网络策略的配置与应用场景等内容。通过合理选择网络插件并正确配置网络策略，可以为 K8s 集群构建起高效、安全的网络环境，满足不同类型应用的网络需求。在实际应用中，应根据集群规模、性能要求、安全等级等因素综合考虑，制定符合自身业务特点的网络解决方案，并遵循渐进式实施、注重可维护性等最佳实践原则，确保 K8s 集群网络的稳定运行和持续优化。