Kubenetes Network

技术方案之 Kubernetes大规模容器网络优化

Kubernetes大规模容器网络优化

Posted by 董江 on Monday, January 6, 2025

技术方案之 Kubernetes大规模容器网络优化

背景

1.1 大规模集群特点

  • 大业务：单模块超大规模副本（300+）
  • 小业务：资源减少边际成本（平摊控制层资源和运维管理资源）
  • 网络互联互通 or 网络安全隔离
  • 不确定业务：有潮汐业务 或者 热点业务（突发流量从小业务到大业务）
  • 在离线混部：资源利用率提升，潮汐算力平衡
  • 其他：新业务尝试

1.2 网络使用原则

  • Global IPAM 和 CIDR 划分
  • 大规模： 物理服务器组网，交换机组网方式不同，屏蔽底层网络局部特征：Overlay网络
  • 网络互通性： 部分Pod IP和集群外IP互通访问， 特殊IP段分配： Global 地址池映射
  • 常规
    • 性能：路由表
    • 可维护性：IPAM分配规则和CIDR管理
    • 安全性：NetworkPolicies

1.3 网络使用

原则： 运维人员 精确化配置（人工规划） 与 软件CNI最终一致性分配 上的平衡

我们都清楚：

  • 性能最好： Underlay CNI（MacVlan 或 SR-IOV 或者 SDN） 直通RDMA等网络
  • 性能次一点：BGP 或者 BGP RR （其中将内核流程通过ebpf减少内核各个filter环）
  • 性能再次一点： Overlay CNI IPinIP 或者 Vxlan 隧道网络（建设基础网络差异性）
  • 性能最差：Global VPC CNI（与VPC网络同步，包括安全组等）

通过网络包L2/L3封装 和 IPAM各种分配策略，来换取大规模下人为规划和分配不确定

选型方案

2.1 实现的功能

2.1.1 multus-cni

配置多个cni 由于不同目的。 默认cni可用于pod-pod、pod-service、pod-node同网段互通，其他CNI由于外部互通（集群外网络互通等能力）

优点：

  • 不同场景，不同网络链路
  • 更方便扩展

缺点：

  • IP段成倍使用
  • Kubernetes 需要1.25以上，支持POD支持多IP
  • 容器内网卡命名规则，南北东西流量按不同名称网卡

2.1.2 calico ebpf 和 clium ebpf

本质：通过绕过内存filter等模块，提升性能； ebpf替换kube-proxy等

优点：

  • 网络链路简单
  • 性能优先

缺点：

  • 内核要求 >= 5.10+
  • eBPF基于TBF插件控制流量，对于NetworkPolicies支持不全面
  • DSF和SNAT对外流量复杂性
  • kube-proxy替换，也就是对service clusterIP分配替换

2.1.3 sriov-cni

CNI直连物理网卡转发，数据最优

优点：

  • 性能最优
  • 网卡支持类型局限

缺点：

  • 配置最复杂：HW 物理网卡配置
  • 网卡支持类型局限

2.2 性能对比结果

说明：

  • calico ebpf：对内核有要求5.8
  • calico ipip网络要求最宽松，单不支持PodIP 与集群外直接互通，只能通过SNAT对外暴漏
  • calico bgp RR：需要知道Node在哪些leaf交换机下，进行精确认为配置

2.2.1 方式一: Calico IPinIP隧道 + kubproxy IPVS

使用场景：

  1. C/S架构服务，对内核、网络限流、TCP长链接均衡等无特殊要求;
  2. server端，单集群（大集群内）闭环，即无外部客户端服务发现;
  3. 网络东西向流量，集群内闭环；南北向流量走NAT;

注意点：

  1. IPIP MTU 1480（-20）；
  2. kube-proxy分配的是ClusterIP, calico/flannel分配的是Pod IP

通过Service 访问具体实例的Endpoint, 核心是在kube-proxy

因此 kube-proxy 更改

--ipvs-min-sync-period=1s #默认：最小刷新间隔1s
--ipvs-sync-period=5s  # 默认：5s周期性刷新
--cleanup=false

--ipvs-min-sync-period=0s # 发生事件实时刷新
--ipvs-sync-period=30s # 30s周期性刷新, 刷新一次节点 iptables 规则
--cleanup=true (清理 iptables 和 ipvs 规则并退出)

对于数据面高并发场景，服务服务配置

--ipvs-scheduler=lc #最小连接，默认是rr round-robin

3、 无论是iptable 或者 ipvs 底层都会走conntracker

$ sysctl -w net.netfilter.nf_conntrack_max=2310720

kube-proxy 启动的时候会重新设置, 因此配置参数可以按node CPU 个数进行调整

--conntrack-max-per-core=144420  # 2310720/cpu个数。 2310720/16核 = 144420
--conntrack-min=2310720 # 设置为nf_conntrack_max

2.2.2 方式二: Calico BGP RR + kubeproxy IPVS + IPVS scheduler lc

设置过的IPPool， 对每一个IPPool做路由聚合; 注意：

  1. IPPool不能冲突，blockSize 全部保持一致 27;
  2. calico_datastore 独立K8s外静态pod etcd；
  3. RR 节点多网卡做bond，并且外部处于不同的交换机下； 并且在这台机器上RR节点优先走网卡权重Queue队列；

「如果这篇文章对你有用,请随意打赏」

Kubeservice博客

如果这篇文章对你有用,请随意打赏

使用微信扫描二维码完成支付

CATALOG
    FEATURED TAGS
    agent apiserver application bandwidth-limit cgo cgroupfs ci/cd client-go cloudnative cncf cni community container container-network-interface containerd controller coredns crd cuda custom-controller deployment device-plugin docker docker-build docker-image drop ebpf ecology egress etcd gitee github gitlab golang governance gpu gpu-device hpa http2 image ingress iptables jobs kata kata-runtime kernel kind kubelet kubenetes kubernetes library linux-os logging loki metrics monitor namespace network network-troubleshooting node nodeport nvidai ollama pingmesh pod prestop prometheus proxyless pvc rollingupdate schedule scheduler serverless sglang sidecar sigtrem systemd tensorrt-llm throttling timeout tools traceroute vllm