35、高级Kubernetes网络：解决方案、策略与负载均衡

最新推荐文章于 2025-10-10 21:52:02 发布

mqtt6iot

最新推荐文章于 2025-10-10 21:52:02 发布

阅读量38

点赞数

CC 4.0 BY-SA版权

分类专栏： Kubernetes实战进阶文章标签： Kubernetes 网络解决方案网络策略

本文链接：https://blog.youkuaiyun.com/mqtt6iot/article/details/152397363

Kubernetes实战进阶专栏收录该内容

42 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

高级Kubernetes网络：解决方案、策略与负载均衡

1. Kubernetes网络概述

Kubernetes的网络是一个广泛的话题，它规定了扁平地址空间的高级网络模型，但在这个空间内，有许多不同的网络解决方案可供选择，以满足不同环境的各种需求和策略。

2. 常见的Kubernetes网络解决方案

裸金属集群桥接
- 最基础的环境是仅具有L2物理网络的裸金属集群。可以使用Linux桥接设备将容器连接到物理网络，但此过程较为复杂，需要熟悉 brctl 、 ip addr 、 ip route 、 ip link 、 nsenter 等底层Linux网络命令。可参考此指南进行操作。
Contiv
- 是一个通用的容器网络插件，可通过CNI插件与Docker、Mesos、Docker Swarm和Kubernetes一起使用。它专注于网络策略，与Kubernetes自身的网络策略对象有一定重叠。
- 功能特点 ：
  - 支持libnetwork的CNM和CNI规范。
  - 提供丰富的策略模型，确保应用安全、可预测地部署。
  - 为容器工作负载提供一流的吞吐量。
  - 支持多租户、隔离和重叠子网。
  - 集成IPAM和服务发现。
  - 支持多种物理拓扑，如Layer2（VLAN）、Layer3（BGP）、Overlay（VXLAN）、Cisco SDN解决方案（ACI）等。
  - 支持IPv6。
  - 可扩展的策略和路由分发。
  - 与应用蓝图集成，如Docker-compose和Kubernetes部署管理器。
  - 内置东西向微服务负载均衡。
  - 对存储、控制（如etcd/consul）、网络和管理流量进行流量隔离。
Open vSwitch
- 是一个成熟的基于软件的虚拟交换机解决方案，得到了许多大公司的支持。Open Virtualization Network（OVN）解决方案可用于构建各种虚拟网络拓扑。它有专门的Kubernetes插件，但设置并不简单，可参考此指南。Linen CNI插件可能更易于设置，尽管它不支持OVN的所有功能，可参考此链接。
- 关键特性 ：
  - 标准的802.1Q VLAN模型，带有主干和访问端口。
  - 支持上游交换机上的NIC绑定（带或不带LACP）。
  - 支持NetFlow、sFlow(R)和镜像，提高可见性。
  - 支持QoS（服务质量）配置和策略。
  - 支持Geneve、GRE、VXLAN、STT和LISP隧道。
  - 支持802.1ag连接故障管理。
  - 支持OpenFlow 1.0及众多扩展。
  - 带有C和Python绑定的事务性配置数据库。
  - 使用Linux内核模块进行高性能转发。
Nuage networks VCS
- 提供高度可扩展的基于策略的软件定义网络（SDN）平台，是企业级解决方案。它基于开源的Open vSwitch构建数据平面，并结合基于开放标准的功能丰富的SDN控制器。
- 特点：
  - 使用覆盖网络在Kubernetes Pod和非Kubernetes环境（VM和裸金属服务器）之间提供无缝的基于策略的网络连接。
  - 策略抽象模型以应用为中心，便于为应用声明细粒度的策略。
  - 实时分析引擎可实现对Kubernetes应用的可见性和安全监控。
  - 所有VCS组件都可以安装在容器中，无需特殊硬件要求。
Canal
- 是Calico和Flannel两个开源项目的组合。最初它们是独立开发的，但用户希望将它们一起使用。目前，开源的Canal项目是一种将两个项目作为单独的CNI插件安装的部署模式。与Kubernetes集成时，Canal不再直接使用etcd，而是依赖Kubernetes API服务器。
Flannel
- 是一个虚拟网络，为每个主机分配一个子网供容器运行时使用。它在每个主机上运行 flaneld 代理，从etcd中存储的预留地址空间为节点分配子网。数据包在容器和主机之间的转发由多个后端之一完成，最常见的后端使用UDP通过TUN设备进行隧道传输，默认端口为8285，需确保防火墙开放此端口。
- 其他后端 ：
  - vxlan ：使用内核中的VXLAN封装数据包。
  - host - gw ：通过远程机器IP创建到子网的IP路由，要求运行Flannel的主机之间具有直接的Layer2连接。
  - aws - vpc ：在Amazon VPC路由表中创建IP路由。
  - gce ：在Google计算引擎网络中创建IP路由。
  - alloc ：仅执行子网分配，不转发数据包。
  - ali - vpc ：在阿里云VPC路由表中创建IP路由。
Calico项目
- 是一个多功能的容器虚拟网络和网络安全解决方案，可与所有主要的容器编排框架和运行时集成，包括Kubernetes、Mesos、Docker和OpenStack。它可以在本地或公共云环境中部署，其网络策略执行可以针对每个工作负载进行定制，确保流量得到精确控制，数据包始终从源到经过验证的目的地。Kubernetes网络策略的参考实现就是Calico。
Romana
- 是一种现代的云原生容器网络解决方案，在第3层运行，利用标准的IP地址管理技术。整个网络可以成为隔离单元，因为Romana使用Linux主机创建到网络的网关和路由。在第3层运行意味着不需要封装，网络策略作为分布式防火墙在所有端点和服务上执行。跨云平台和本地部署的混合部署更容易，因为不需要配置虚拟覆盖网络。新的Romana虚拟IP允许本地用户通过外部IP和服务规范在第2层LAN上暴露服务。
Weave net
- 注重易用性和零配置，它在底层使用VXLAN封装，并在每个节点上使用微DNS。作为开发者，可以在高抽象级别操作，只需命名容器，Weave net就可以让你使用标准端口连接和使用服务，有助于将现有应用迁移到容器化应用和微服务中。在Kubernetes 1.4及更高版本中，可以通过运行以下命令将Weave net与Kubernetes集成：

kubectl apply -f https://git.io/weave-kube

- Weave net支持网络策略API，提供了一个完整且易于设置的解决方案。

3. 有效使用网络策略

理解Kubernetes网络策略设计
- 网络策略规定了选定的Pod如何与其他网络端点进行通信。NetworkPolicy资源使用标签选择Pod，并定义白名单规则，允许流量访问选定的Pod，这些规则是在给定命名空间的隔离策略基础上的补充。
网络策略与CNI插件的关系
- 网络策略和CNI插件之间存在复杂的关系。一些CNI插件同时实现网络连接和网络策略，而另一些只实现其中一个方面，但可以与实现另一方面的CNI插件协作，例如Calico和Flannel。
配置网络策略
- 网络策略通过NetworkPolicy资源进行配置，以下是一个示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              project: awesome-project
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: tcp
          port: 6379

实施网络策略
- 虽然网络策略API本身是通用的，是Kubernetes API的一部分，但实现与网络解决方案紧密耦合。在每个节点上，有一个特殊的代理或守门人执行以下操作：
  - 拦截进入节点的所有流量。
  - 验证流量是否符合网络策略。
  - 转发或拒绝每个请求。
- Kubernetes通过API提供定义和存储网络策略的功能，而网络策略的执行则由网络解决方案或与特定网络解决方案紧密集成的专用网络策略解决方案负责。Calico和Canal就是这种方法的典型例子。

4. 负载均衡选项

负载均衡的重要性
- 在Kubernetes集群这样的动态系统中，负载均衡是一项关键功能。节点、VM和Pod会不断变化，客户端无法跟踪哪些实体可以处理它们的请求。负载均衡通过添加一层间接性，隐藏集群内部的复杂性，为客户端或消费者提供稳定的服务。
外部负载均衡器
- 外部负载均衡器运行在Kubernetes集群之外，Kubernetes需要与外部负载均衡器提供商交互，以配置健康检查、防火墙规则并获取负载均衡器的外部IP地址。
- 配置外部负载均衡器 ：
  - 通过配置文件 ：

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "example-service"
    },
    "spec": {
        "ports": [
            {
                "port": 8765,
                "targetPort": 9376
            }
        ],
        "selector": {
            "app": "example"
        },
        "type": "LoadBalancer"
    }
}

    - **通过Kubectl命令**：

kubectl expose rc example --port=8765 --target-port=9376 --name=example-service --type=LoadBalancer

- **查找负载均衡器IP地址**：使用`kubectl describe`命令获取负载均衡器的内部和外部IP地址，`IP`表示内部IP地址，`LoadBalancer Ingress`表示外部IP地址。

kubectl describe services example-service

- **保留客户端IP地址**：在Kubernetes 1.5中，GKE上有一个beta功能可通过注解获取客户端源IP地址。在Kubernetes 1.7中，API增加了保留原始客户端IP的功能。需要配置服务规范的以下两个字段：
    - `service.spec.externalTrafficPolicy`：决定服务应将外部流量路由到节点本地端点还是集群范围的端点（默认）。`cluster`选项不会暴露客户端源IP，可能会增加到不同节点的跳转，但负载分布较好；`Local`选项保留客户端源IP，只要服务类型是`LoadBalancer`或`NodePort`就不会增加额外跳转，但负载均衡效果可能不佳。
    - `service.spec.healthCheckNodePort`：可选字段，用于指定服务健康检查使用的端口号，默认是分配的节点端口，对`externalTrafficPolicy`设置为`Local`的`LoadBalancer`类型服务有影响。示例如下：

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "example-service"
    },
    "spec": {
        "ports": [
            {
                "port": 8765,
                "targetPort": 9376
            }
        ],
        "selector": {
            "app": "example"
        },
        "type": "LoadBalancer",
        "externalTrafficPolicy": "Local"
    }
}

- **外部负载均衡的潜在问题**：外部负载均衡器在节点级别操作，负载分布在节点级别进行。例如，如果一个服务有四个Pod，其中三个在节点A，一个在节点B，外部负载均衡器可能会在节点A和节点B之间平均分配负载，导致节点A上的三个Pod处理一半的负载（每个Pod处理1/6），而节点B上的单个Pod处理另一半负载。未来可能会添加权重来解决这个问题。

服务负载均衡器
- 服务负载均衡器旨在处理Kubernetes集群内的内部流量，而不是外部负载均衡。它使用 clusterIP 服务类型。虽然可以通过预分配端口使用 NodePort 服务类型将服务负载均衡器直接暴露为外部负载均衡器，但这不是其设计用途，一些理想的功能如SSL终止和HTTP缓存可能无法直接使用。
Ingress
- Ingress本质上是一组规则，允许入站连接访问集群服务。一些Ingress控制器还支持连接算法、请求限制、URL重写和重定向、TCP/UDP负载均衡、SSL终止、访问控制和授权等功能。Ingress仍处于beta阶段，尚未涵盖所有必要的功能。以下是一个Ingress资源的示例，用于管理进入两个服务的流量：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
    # 这里原文档未完整给出规则内容

综上所述，Kubernetes提供了多种网络解决方案、网络策略配置方法和负载均衡选项，用户可以根据自己的需求和环境选择合适的方案。在实际应用中，需要综合考虑性能、安全性、易用性等因素，以构建高效、稳定的Kubernetes集群网络。

mermaid格式流程图

graph LR
    A[Kubernetes网络] --> B[网络解决方案]
    A --> C[网络策略]
    A --> D[负载均衡]
    B --> B1[裸金属集群桥接]
    B --> B2[Contiv]
    B --> B3[Open vSwitch]
    B --> B4[Nuage networks VCS]
    B --> B5[Canal]
    B --> B6[Flannel]
    B --> B7[Calico]
    B --> B8[Romana]
    B --> B9[Weave net]
    C --> C1[理解设计]
    C --> C2[配置策略]
    C --> C3[实施策略]
    D --> D1[外部负载均衡器]
    D --> D2[服务负载均衡器]
    D --> D3[Ingress]

表格：常见网络解决方案对比

解决方案	特点	适用场景
Contiv	支持多种规范，功能丰富	多平台、对网络策略要求高的场景
Open vSwitch	成熟，功能全面	需要构建复杂虚拟网络拓扑的场景
Nuage networks VCS	企业级，策略强大	企业级Kubernetes集群，对安全监控要求高
Canal	结合Calico和Flannel	需要网络连接和策略结合的场景
Flannel	简单易用	对网络配置要求不高的场景
Calico	网络策略强大	对网络安全和策略控制要求严格的场景
Romana	高性能，无封装	对性能要求高，跨平台部署的场景
Weave net	易用，零配置	快速部署和迁移应用的场景

高级Kubernetes网络：解决方案、策略与负载均衡

5. 不同网络解决方案的性能与特点总结

为了更清晰地了解各种Kubernetes网络解决方案的差异，我们可以从多个维度进行对比，以下是一个详细的对比表格：
| 解决方案 | 网络连接方式 | 网络策略能力 | 性能特点 | 部署难度 | 适用场景 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| Contiv | 支持多种物理拓扑，如Layer2、Layer3、Overlay等 | 具有丰富的策略模型，与Kubernetes网络策略有重叠 | 提供一流的吞吐量 | 较复杂，需考虑多平台适配 | 多平台、对网络策略要求高的复杂场景 |
| Open vSwitch | 可使用Overlay和Underlay模式，连接多种设备 | 支持NetFlow、sFlow等监控，有一定策略配置能力 | 高性能转发，使用Linux内核模块 | 较难，设置过程复杂 | 需要构建复杂虚拟网络拓扑的场景 |
| Nuage networks VCS | 使用覆盖网络实现Kubernetes与非Kubernetes环境的连接 | 策略抽象模型便于声明细粒度策略，有实时分析引擎 | 支持大规模部署，性能稳定 | 中等，组件可容器化安装 | 企业级Kubernetes集群，对安全监控要求高 |
| Canal | 结合Calico和Flannel，分别负责网络策略和容器网络 | 继承Calico的强大网络策略能力 | 性能取决于Calico和Flannel的组合 | 中等，需协调两个项目 | 需要网络连接和策略结合的场景 |
| Flannel | 为每个主机分配子网，通过多种后端转发数据包 | 网络策略能力较弱 | 配置简单，性能一般 | 简单，易于上手 | 对网络配置要求不高的场景 |
| Calico | 可与多种容器编排框架集成，自动映射网络策略 | 是Kubernetes网络策略的参考实现，策略控制精确 | 性能较好，能满足大多数场景需求 | 中等，需理解网络策略映射 | 对网络安全和策略控制要求严格的场景 |
| Romana | 在Layer3运行，利用标准IP地址管理技术 | 分布式防火墙实现网络策略 | 消除VXLAN封装开销，性能提升显著 | 中等，需掌握IP地址管理 | 对性能要求高，跨平台部署的场景 |
| Weave net | 使用VXLAN封装，结合微DNS | 支持网络策略API | 易用性强，零配置 | 简单，一键部署 | 快速部署和迁移应用的场景 |

6. 网络策略的最佳实践

策略的粒度控制 ：在配置网络策略时，应根据实际需求合理控制策略的粒度。过于宽松的策略可能会导致安全漏洞，而过于严格的策略可能会影响应用的正常运行。例如，对于数据库服务，只允许特定命名空间和角色的前端服务访问，避免其他不必要的流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              project: awesome-project
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: tcp
          port: 6379

策略的测试与验证 ：在正式应用网络策略之前，应进行充分的测试和验证。可以使用模拟流量或测试环境来验证策略是否按预期工作。例如，使用工具模拟不同来源的流量，检查是否只有符合策略的流量能够访问目标服务。
策略的更新与维护 ：随着应用的发展和变化，网络策略也需要相应地更新和维护。定期审查和清理不再使用的策略，确保策略的有效性和一致性。

7. 负载均衡的优化建议

外部负载均衡器的优化
- 合理配置健康检查 ：确保健康检查的频率和阈值设置合理，避免误判导致服务不可用。例如，对于响应时间较长的服务，可以适当增加健康检查的超时时间。
- 使用权重分配 ：虽然目前外部负载均衡器在节点级别分配负载可能存在不均衡的问题，但可以考虑使用权重分配来优化负载分布。例如，根据节点的性能和资源情况，为不同节点分配不同的权重。
服务负载均衡器的优化
- 结合Ingress使用 ：将服务负载均衡器与Ingress结合使用，可以更好地管理集群内的流量。Ingress可以根据URL规则将流量分发到不同的服务，而服务负载均衡器可以在服务内部进行负载均衡。
- 优化服务发现 ：确保服务发现机制的高效性，减少服务发现的延迟。可以使用Kubernetes的内置服务发现机制或第三方服务发现工具。

8. 未来发展趋势

网络解决方案的融合 ：随着Kubernetes的发展，不同的网络解决方案可能会进一步融合，提供更加统一和高效的网络服务。例如，Calico和Flannel的集成可能会更加紧密，为用户提供更简单的配置和更好的性能。
网络策略的智能化 ：未来的网络策略可能会更加智能化，能够根据应用的实时状态和流量情况自动调整策略。例如，根据服务的负载情况动态调整访问控制策略。
负载均衡的创新 ：负载均衡技术可能会不断创新，提供更加灵活和高效的负载均衡方案。例如，引入基于人工智能的负载均衡算法，根据流量特征和节点性能进行智能负载分配。

mermaid格式流程图：网络策略实施流程

graph LR
    A[定义网络策略] --> B[通过API存储策略]
    B --> C[节点代理拦截流量]
    C --> D{验证流量是否符合策略}
    D -- 是 --> E[转发流量]
    D -- 否 --> F[拒绝流量]

表格：负载均衡选项对比

负载均衡类型	优点	缺点	适用场景
外部负载均衡器	提供外部IP地址，可集成云负载均衡器	可能存在负载不均衡问题，依赖外部提供商	面向外部用户的服务
服务负载均衡器	专注于集群内部流量，配置简单	不适合外部负载均衡，部分功能缺失	集群内部服务之间的负载均衡
Ingress	支持多种高级功能，如URL重写、SSL终止等	仍处于beta阶段，功能不完善	管理入站流量，实现复杂的路由规则

在未来的Kubernetes应用中，网络的性能、安全性和可管理性将变得越来越重要。通过深入了解各种网络解决方案、网络策略和负载均衡选项，并结合实际需求进行合理选择和配置，用户可以构建更加高效、稳定和安全的Kubernetes集群网络。同时，关注网络技术的发展趋势，及时采用新的技术和方法，将有助于提升Kubernetes集群的整体性能和竞争力。