我在香港机房负责几十台裸金属服务器的管理和运维工作，这些服务器承载着我们面向东南亚用户的高并发应用。过去我们用传统虚拟机+Ansible的方式部署，效率低且运维负担重。去年，我主导将核心服务迁移到 Kubernetes 集群上，实现了高效的资源管理、快速部署、可扩展性与容错能力。

这篇文章记录了我在香港机房里亲手搭建与优化 K8s 的真实经历，以及踩过的坑和解决方案。

1. 机房环境与部署背景

香港机房里我们有 12 台物理服务器，配置如下：

服务器规格：

• CPU：Intel Xeon Gold 6248R (24 核 48 线程)
• 内存：256GB
• 硬盘：2TB NVMe SSD + 8TB SATA
• 网卡：双 10GbE

操作系统：Ubuntu 22.04 LTS

容器运行时：containerd 1.7

Kubernetes 版本：v1.29

网络插件：Calico (BGP 模式，支持多子网)

存储：Ceph RBD 提供持久化存储，节点本地 SSD 用于高速缓存

当初我们最大的痛点是：

• 部署新服务需要人手 SSH 上去拉镜像、配置环境、调度端口。
• 资源利用率低，部分服务器 CPU 经常空闲，其他节点却过载。
• 服务宕机后，人工干预恢复慢，无法满足 SLA。

2. Kubernetes 集群搭建过程中的实战细节

我选择使用 kubeadm 部署裸金属集群，但实际过程并不顺利，以下是核心步骤与关键问题。

2.1 初始化主节点

在主节点上，我执行了：

kubeadm init \
  --apiserver-advertise-address=10.10.1.11 \
  --pod-network-cidr=10.244.0.0/16 \
  --service-cidr=10.96.0.0/12

这里踩的第一个坑是机房的多网卡问题，K8s 默认会选第一个网卡作为 API Server 广播地址，导致工作节点无法加入集群。

解决方案：指定 --apiserver-advertise-address 为 业务网段 IP。

初始化完成后，我配置了 kubectl 访问权限：

mkdir -p $HOME/.kube
cp /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

然后部署了 Calico 网络插件：

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml

2.2 节点加入与负载均衡优化

在 11 台工作节点上，我执行 kubeadm join 加入集群，但发现两个问题：

部分节点加入失败：原因为 conntrack 模块未加载，导致 Pod 网络不通。
解决方案：

modprobe br_netfilter
echo "br_netfilter" >> /etc/modules

Master 节点 API Server 压力过高：因为我们业务初期部署了 500+ Pod，API Server 的 ETCD 压力大。

解决方案：

• 在三台主节点上部署了高可用控制平面，使用 HAProxy 做前端负载均衡。
• etcd 数据盘单独挂载 NVMe SSD 提升 IOPS。

3. 应用部署与资源管理的优化实践

3.1 部署高可用服务

以我们在香港机房跑的 Web API 服务为例，我创建了如下 Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hk-web-api
spec:
  replicas: 6
  selector:
    matchLabels:
      app: hk-web-api
  template:
    metadata:
      labels:
        app: hk-web-api
    spec:
      containers:
      - name: hk-web-api
        image: registry.local/hk-web-api:1.2.3
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "2"
            memory: "2Gi"
        ports:
        - containerPort: 8080

部署后发现，Pod 分布极不均衡，有些节点高负载，有些几乎空闲。

解决方案：

开启 TopologySpreadConstraints 保证 Pod 分散到不同节点：

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app: hk-web-api

使用 HPA 自动扩容：

kubectl autoscale deployment hk-web-api --cpu-percent=60 --min=6 --max=20

3.2 业务中断与自愈

有一次机房网络抖动导致一台节点掉线 5 分钟，Pod 自动漂移到其他节点，业务完全没有中断。

我在 Prometheus 里观察到 K8s 自动驱逐了不可达节点上的 Pod，并在 30 秒内在健康节点拉起了新副本。

这让我第一次真正感受到 Kubernetes 的自愈能力带来的价值。

3.3 存储与状态服务的挑战

香港机房的数据库服务（MySQL、Redis）最初我用 Deployment 部署，结果 Pod 重建后数据丢失。

解决方案：

改用 StatefulSet + PVC：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-hk
spec:
  serviceName: redis-hk
  replicas: 3
  selector:
    matchLabels:
      app: redis-hk
  template:
    metadata:
      labels:
        app: redis-hk
    spec:
      containers:
      - name: redis
        image: redis:7
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: ceph-rbd
      resources:
        requests:
          storage: 50Gi

存储用 Ceph RBD，并开启本地 SSD 缓存，IO 延迟降低了 40%。

4. 总结与经验

通过在香港机房部署 Kubernetes，我的最大收获是：

• 资源利用率提升约 40%：通过 Pod 自动调度与 HPA 弹性伸缩实现。
• 部署速度从小时级降到分钟级：CI/CD 结合 K8s 的滚动更新非常高效。
• 容错与自愈能力显著提升：节点故障无需人工干预。
• 存储和网络是裸金属集群最大的挑战：需要精心设计和优化。

目前我们的香港集群已稳定运行半年以上，每次回想起初次在机房里调试 Calico 网络、解决多网卡路由冲突、以及第一次看到 Pod 自动漂移恢复的场景，都让我切实感受到容器编排技术带来的生产力。