在香港的机房，我们的 Kubernetes 集群运行在裸金属服务器上，提供对外的高并发服务。随着业务的不断扩展，我们遇到了多个网络与存储层面的瓶颈。有时 Pod 间通信延迟过高，有时 Ceph 存储的 IOPS 达不到预期，甚至在某些节点上出现了不明的网络路由冲突。作为运维工程师，这些问题让我焦虑了好一阵子，直到我开始深入分析并调优 Kubernetes 的网络层（特别是 Calico）和存储系统（Ceph）。

这篇文章详细记录了我如何在裸金属 Kubernetes 集群中，深入调优网络与存储，并成功解决了多个瓶颈和故障。

1. 机房环境与网络架构概述

首先，我来简单介绍一下我们在香港机房的基础架构：

硬件：

CPU：Intel Xeon Gold 6248R (24 核 48 线程)

内存：256GB

硬盘：2TB NVMe SSD + 8TB SATA

网络：10GbE 双网卡配置，网络带宽上行 1Gbps，下行 10Gbps

存储：Ceph 集群（2TB SSD 用作 OSD，8TB SATA 用作存储池）

Kubernetes 集群：12 台节点（3 主节点，9 工作节点），使用 Calico 作为 CNI 网络插件，Ceph 作为持久化存储，集群内负载均衡由 HAProxy 提供。

网络配置：

我们使用 BGP（边界网关协议）来实现 Kubernetes 集群的跨子网路由。

机房内部使用了 Calico 来提供 Pod 网络的路由和隔离。

2. 遇到的主要问题与挑战

2.1 BGP 路由冲突

在我们机房的 Kubernetes 集群中，BGP 路由冲突是最早遇到的问题。由于 Calico 使用 BGP 进行跨节点的路由，所有节点的 IP 路由表都被动态更新。但是，由于我们机房内有多个外部 BGP 路由器，导致了部分 IP 路由表的冲突。具体表现为：

Pod 之间通信时出现延迟，有时请求被丢失。

集群外部的访问不稳定，特别是跨子网的访问，时断时续。

2.2 Calico 性能瓶颈

虽然 Calico 在 Kubernetes 网络中提供了较好的网络隔离和高效的网络策略，但是在集群规模扩展到几百个 Pod 时，我发现网络的吞吐量和延迟开始受到影响。具体症状如下：

Pod 间通信延迟增高，尤其是在跨节点通信时，延迟高达 100ms。

网络带宽占用过高，影响到其他业务流量的传输。

2.3 Ceph 存储延迟

Ceph 存储是我们的核心持久化存储方案，但在高并发的读写操作中，我们遇到了存储 延迟高 的问题：

IOPS 达不到预期，大部分请求的响应时间超出了 SLA。

读写延迟不可预测，在负载高峰期，部分请求的延迟暴涨。

3. 网络层深度调优：解决 BGP 路由冲突与 Calico 性能瓶颈

3.1 解决 BGP 路由冲突

针对 BGP 路由冲突，我采取了以下步骤：

调整 Calico BGP 路由设置：

默认情况下，Calico 使用 BGP 来自动同步路由。但是，在机房环境中，多个外部 BGP 路由器的存在让 Calico 的路由表与外部路由表产生了冲突。为了避免这种冲突，我修改了 Calico 的配置，手动配置了节点之间的 BGP 路由，避免了路由信息的自动同步：

apiVersion: crd.projectcalico.org/v1
kind: BGPConfiguration
metadata:
  name: default
spec:
  nodeToNodeMeshEnabled: false  # 禁用节点间自动建立 BGP 对等
  asNumber: 64512  # 自定义 AS 号

调整节点间 BGP 对等配置：

为了确保集群内每个节点的路由不与外部冲突，我手动设置了节点之间的静态路由，并为每个节点分配了唯一的 AS 号。这样，可以在 Calico 中管理集群的路由，而不会影响外部路由的动态更新。

使用 Calico 的 “IP-in-IP” 隧道模式：

我选择将 Calico 的网络模式从 BGP 模式切换为 IP-in-IP 隧道模式，以避免由于外部路由冲突带来的性能影响。此模式下，Calico 会通过 IP 隧道来封装 Pod 间的流量，避免直接依赖 BGP 路由。

修改配置：

apiVersion: operator.projectcalico.org/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
      - cidr: 192.168.0.0/16
        encapsulation: IPIP
        nodeSelector: all()

3.2 优化 Calico 性能瓶颈

为了提升 Calico 网络的性能，我做了如下优化：

增加 IP 分配池大小：

我发现默认的 IP 分配池大小对大型集群支持不够，我通过增加 IP Pool 来分配更多 IP 地址：

apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
  name: default-ip-pool
spec:
  cidr: 192.168.0.0/16
  ipipMode: Always
  natOutgoing: true

调优 Calico MTU 设置：

默认的 Calico MTU 设置为 1500 字节，但由于网络带宽较高，吞吐量不足，我将 MTU 增加至 9000 字节，以支持大规模的网络吞吐：

apiVersion: crd.projectcalico.org/v1
kind: Network
metadata:
  name: calico-network
spec:
  mtu: 9000

开启 BGP 负载均衡：

我还开启了 BGP 负载均衡来提高 Calico 的性能，确保流量分配更加均匀：

apiVersion: crd.projectcalico.org/v1
kind: BGPConfiguration
metadata:
  name: default
spec:
  iBGP: true
  globalNetworkPolicy: true

4. 存储层深度调优：Ceph 延迟优化

4.1 Ceph 存储瓶颈排查

Ceph 存储延迟的问题主要体现在两个方面：

过高的磁盘延迟，特别是 SSD 存储的响应速度并没有达到预期。

网络延迟，由于 Ceph 使用分布式存储，每次写入都会涉及多个节点，导致了网络瓶颈。

4.2 优化 Ceph 存储

调整 Ceph OSD 参数：

我对 Ceph 的 OSD 参数进行了调优，特别是 IOPS 和吞吐量方面，优化了存储池配置：

ceph osd set reweight-by-utilization
ceph osd crush tunables hammer
ceph osd pool set ceph_pool size 3

启用 SSD 缓存：

为了提升 Ceph 的 IOPS 性能，我启用了 Ceph OSD 的 SSD 缓存模式，并对 SSD 做了专门的优化。

优化网络配置：

我通过优化 Ceph 使用的网络配置，将 Ceph 网络隔离到专用网段，并配置了更高带宽的网络设备，从而减少了 Ceph 集群内部的数据传输延迟。

5. 总结与收获

通过对 裸金属 Kubernetes 集群网络与存储的深度调优，我们成功解决了多个瓶颈，显著提升了集群的性能与稳定性：

• BGP 路由冲突：通过调整 Calico BGP 设置与静态路由配置，解决了集群间通信不稳定的问题。
• Calico 性能瓶颈：增加 IP Pool 和调优 MTU 设置，提升了跨节点通信的吞吐量与稳定性。
• Ceph 存储延迟：通过优化 OSD 参数、启用 SSD 缓存和改进网络配置，降低了存储的读写延迟。

这些调优为集群的扩展性和高可用性提供了坚实的保障，也使得我们能够更好地应对业务增长所带来的流量压力。每次在机房调试网络和存储时，我都会感到这份工作带来的成就感，尤其是当问题解决后，集群稳定运行的那一刻。