存储设备的管理方式分为带外管理和带内管理两种方式，这两种方式通过不同的通道，均可实现对存储设备的管理。

SNMP、RMON、Web、TELNET这些管理方式属于带内管理。

通过CONSOLE、AUX接口管理和通过某些高端设备具有的100BASE-TX的带外管理端口进行管理的方式属于带外管理。

实现方式

具体实现方法如下：

• 带外管理：存储设备的管理控制数据与用户业务数据信息在不同的链路传送，即管理一条线，业务一条线。典型的连接方式为：维护终端连接存储设备管理网口或串口，对存储设备进行管理；应用服务器通过业务网口连接存储设备，传输业务数据。这两条链路互相独立。《产品文档》中《配置指南》等手册描述的即为这种方式。
• 带内管理：存储设备的管理控制数据与用户业务数据信息在相同的链路传送，即管理和业务同一条线。典型的连接方式为：应用服务器通过业务网口连接存储设备，通过在应用服务器侧安装Inband Agent软件（该软件属于HostAgent软件包的一部分），来实现在传输业务数据的同时，也能对存储设备进行管理。

区别

• 可靠性：带外管理由于业务数据和管理数据分别存在于两条独立链路，故在业务链路出现故障时，仍可通过管理链路登录存储设备进行管理。
• 管理方式：带外管理可以既可以登录ISM管理软件界面，也可以登录CLI命令行界面，提供了多样化的管理方式。带内管理一般情况下只提供ISM管理方式。
• 组网：带内管理由于管理和业务在同一链路上，故可以减少连接网线的数量。
• 功能：带内管理可以协调应用服务器和存储设备共同运作，故在某些情况下可以提升存储设备的性能。

带外管理的作用

减少运营成本、提高运营效率、减少宕机时间、提高服务质量。

带外管理使用场景

网管系统必须通过网络来管理设备。如果无法通过网络访问被管理对象，带内网管系统就失效了，这时候带外网管系统就排上用场了。

运维人员和IT设备不在同一个物理地点。这种类型的网络环境包括所有的电信运营商和银行及有分支机构的政府、企业网络。一旦设备故障无法通过网络解决（telnet 、pcanywhere等手段），运维人员只能到现场解决问题。这种类型的网络通过带外网管可以大幅提高网络运维效率，同时有效降低运维成本。

运维人员与IT设备在同一地点，IT设备数目很多统一管理面临很大难度。这种类型IT环境包括所有IDC、企业的数据中心（非托管）、互联网公司、游戏运营商。运维TEAM需要面对几百台甚至上万台服务器，对设备的访问控制授权、操作记录均需要借助带外网管来完成。

参考资料

• FAQ-什么是带外管理和带内管理? - huawei

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路由协议规划 - 锐捷