https://mp.weixin.qq.com/s/e4Ph3scexAZKGHA8Yds3rQ

1. Kubernetes Service 性能和扩展性问题

默认的 Kubernetes 的 Service 实现 kube-proxy，它是使用了 iptables 去配置 Service IP 和负载均衡：

如上图所示：

• 负载均衡过程的 iptables 链路长，导致网络延时显著增加，就算是 ipvs 模式也是绕不开 iptables 的调用；
• 扩展性差。iptables 规则同步是全量刷的，Service 和 Pod 数量多了，一次规则同步都得接近 1s；Service 和 Pod 数量多了之后，数据链路性能大幅降低。

NetworkPolicy 性能和扩展性问题

NetworkPolicy 是 Kubernetes 控制 Pod 和 Pod 间是否允许通信的规则。目前主流的 NetworkPolicy 实现基于 iptables 实现，同样有 iptables 的扩展性问题：

• iptables 线性匹配，性能不高, Scale 能力差
• iptables 线性更新，更新速度慢

使用 eBPF 加速 Service 和 NetworkPolicy 扩展性

关于 eBPF 的介绍如下:

• Linux 在最近版本提供的可编程接口
• 通过 tc-ebpf 将 ebpf 程序注入到网卡中
• 用于大幅降低网络链路的长度和复杂度

如上图所示，使用 tc 工具注入 eBPF 程序到 Pod 的网卡上，可以直接将 Service 和 NetworkPolicy 在网卡中解决，然后直接转发到弹性网卡，大幅降低网络复杂度：

• 每个节点上运行 eBPF Agent，监听 Service 和 NetworkPolicy，配置容器网卡的 Ingress 和 Egress 规则；
• 在 Egress 的 eBPF 程序中，判断访问 k8s Service IP 的请求直接负载均衡到后端 Endpoint；
• 在 Ingress 的 eBPF 程序中，根据 NetworkPolicy 规则计算源 IP 决定是否放行。

PS：我们使用 Cilium 作为节点上的 BPF-agent 去配置容器网卡的 BPF 规则，已贡献 Terway 相关适配：https://github.com/cilium/cilium/pull/10251

性能对比

• 通过 eBPF 对链路的简化，性能有明显提升，相对 iptables 提升 32%, 相对 ipvs 提升 62%；
• 通过编程的 eBPF 的形式，让 Service 数量增加到 5000 时也几乎没有性能损耗，而 iptables 在 Service 增加到 5000 时性能损失了 61%。

2. Kubernetes Coredns 性能和扩展性问题

Kubernetes Pod 解析 DNS 域名会 search 很多次，例如上图 Pod 中 DNS 配置，当它请求 aliyun.com，会依次解析:

• aliyun.com.kube-system.svc.cluster.local -> NXDOMAIN
• aliyun.com.svc.cluster.local -> NXDOMAIN
• aliyun.com.cluster.local -> NXDOMAIN
• aliyun.com -> 1.1.1.1

Coredns 是中心化部署在某一个节点上的，Pod 访问 Coredns 解析经过链路过长，又是 UDP 协议，导致失败率高。

使用 AutoPath 大幅降低 Pod DNS 的查询量

由客户端 Search 变成服务端 Search：

当 Pod 请求 Coredns 时解析域名：

• Coredns 会通过源 IP 地址查询到 Pod 的信息
• 然后根据 Pod 的 Namespace 信息，匹配到它真正想访问的是哪个服务直接返回
• 客户端请求从 4 个直接减少到 1 个，降低了 75% 的 Coredns 请求，从而让失败率降低

在每个节点上使用 node-local-dns

• 拦截 Pod 的 DNS 查询的请求
• 将外部域名分流，外部域名请求不再请求中心 Coredns
• 中间链路使用更稳定的 TCP 解析
• 节点级别缓存 DNS 解析结果，较少请求中信 Coredns

ExternalDNS 直接使用阿里云的域名解析服务

• 云原生的 DNS 解析，Pod 直接请求云服务 PrivateZone 中的自定义 DNS 能力；
• 由 ExternalDNS 监听到服务和 Pod 创建后配置 PrivateZone 中的域名解析；
• 和原生的 ECS 解析同样的 DNS 解析性能。

前言

Calico 是容器网络的一种解决方案，提供了纯 3 层的网络模型，每个容器都通过 IP 直接通信，中间通过路由转发找到对方。容器所在的节点充当传统的路由器，提供了路由查找的功能。

我计划将 Calico/BGP 相关的内容都过一遍，把这个过程记录下来。本篇是对 bgp 报文的抓包记录，便于在学习bgp中更有实感。

由于网络的水深与个人能力有限，本文不免存在错误之处。如有疑问，请查阅文末参考资料或与我线上/线下讨论。

背景

kubernetes 部署在裸金属上，使用 calico BGP 并与交换机交换路由，可以充分发挥硬件的速度优势。具体部署架构可参考 calico 官方的部署模式 Calico over IP fabrics #The AS Per Rack model， leaf-spine 二层架构：

其中 Spine 与 Leaf 之间使用三层 ebgp 互联，每个机柜是一个 AS，机柜内使用 ibgp 协议互联，柜顶交换机与核心交换机使用 ebgp互联。

数据中心BGP路由协议规划

BGP 最初是为不同自治系统之间的互通设计的，它也可以用在数据中心内部。现代数据中心中使用最广泛的路由协议就是 BGP。但在 BGP 引入到数据中心场景时，网络规划需要考虑不少问题。

如下图是某厂商典型的三级CLOS数据中心组网：

BGP设计要点大致如下：

• 为Tor、Leaf、Spine设备规划 AS号
• 设备间建立 BGP 邻居
• 为CLOS网络生成 ECMP 等价路由
• 对不同类型的 BGP 路由进行路由属性控制
• 指定路由传递规则
• 使用双向转发检测协议（BFD）加快故障收敛

对于以上涉及要点，Kubernetes 裸金属需要完成如下基础配置：

• BGP计时器，keepalive/hold timer

  配置为1S/3S，在数据中心内部，故障的快速收敛更为重要，配置为1S/3S加快收敛。

• 发布路由通告的间隔，Advertisement Interval

  配置为0，立即发布。

• bgp log-neighbor-changes

  启用交换机侧BGP日志功能，BGP邻居关系建立以及断开时会生成日志信息。

• BGP ECMP

  不同交换机支持可能不同，一般默认为8，推荐配置为 32。

抓包

假定主机使用 bond0 网卡与集群内外部互访，使用如下命令抓包

$ sudo tcpdump -w `hostname`-` date "+%m%d-%H%M"`-bgp.pcap -i bond0

由于配置了BGP keepalive为1s，我们观察到每隔1s会有一次心跳包检测。

路由更新

在这里我简单地用两个 Tor ebgp 互联，架构如下：

   (ebgp)|-------------------------|(ebgp)
         |                         |
   （172.16.0.26/30）          （172.16.0.22/30）
        Tor1(AS65412)            Tor2(AS65413)
  (10.90.0.254/25)            (10.90.0.126/25)
          |                       |       |
          |(ibgp)                 |(ibgp) |(ibgp)
        ▲131                      ▲85     ▲86

▲为服务器，Tor1和Tor2为柜顶交换机

86节点向 Tor2 广播明10.90.20.128/27 的路由：

交换机 Tor2 添加originator_ID和Cluster_list，用于IBGP防环。而后它 使用 update 信息传给同一个 AS 内的 peer 85

同时 Tor2 向 Tor1 发 ebgp 请求，由于 ebgp 的特性，路由携带的Cluster-list和originator全部消失。

（截图空缺=。=）

然后Tor1向 同一个 AS 内的 peer 发送 update 信息：

结束

本文对 bgp 的 update 报文做了简单的记录，便于新人理解 bgp 协议更新过程。

参考资料

• 大型数据中心BGP路由协议规划 - 锐捷

file>settings>Lauguages & Frameworks>javascript

将javascript languages version 修改为 ECMAScript 6

最后apply>ok