信创环境下Kubernetes多主高可用架构实战指南

1. 信创Kubernetes多主高可用架构概述

在国产化信息技术应用创新（信创）背景下，构建高可用的Kubernetes集群已成为企业级云原生基础设施的核心需求。作为一名在金融行业实施过多个信创云原生项目的架构师，我将分享基于国产化环境的Kubernetes多主高可用架构实战经验。

1.1 信创环境特点解析

信创环境与传统x86架构的主要差异体现在：

• 硬件层面：采用鲲鹏920（ARM架构）、飞腾2000+等国产CPU，指令集与Intel/AMD不同
• 软件层面：运行银河麒麟V10、统信UOS等国产操作系统，内核版本和软件包管理存在差异
• 生态适配：容器运行时、网络插件等组件需要针对ARM架构重新编译

实际踩坑经验：在鲲鹏920芯片上首次部署时，因未使用ARM架构的Docker镜像导致Pod启动失败。后改用华为容器引擎（基于ARM优化）才解决问题。

1.2 多主高可用架构价值

传统单Master架构在信创生产环境中存在明显短板：

1. 单点故障风险：Master节点宕机导致集群完全失控
2. 性能瓶颈：单个API Server处理能力有限（实测单节点QPS≤1000）
3. 维护困难：升级或维护时必须停止整个集群服务

通过3节点多主架构可实现：

• 服务可用性99.95%：年中断时间≤4.38小时
• 线性扩展能力：API Server性能随节点数增加而提升（3节点实测QPS≥2500）
• 滚动维护：可逐个节点进行升级维护

2. 架构设计与核心组件

2.1 两种拓扑结构对比

我们在政务云项目中对比测试了两种架构：

结论：生产环境强烈推荐外部etcd拓扑，虽然部署复杂但稳定性更好。我们在某银行项目中，外部etcd架构在单AZ故障时仍保持服务可用。

2.2 核心组件选型建议

2.2.1 控制平面组件

• kube-apiserver：所有集群操作的唯一入口，必须通过负载均衡暴露
• kube-controller-manager：采用Leader Election机制确保单活跃实例
• kube-scheduler：同样使用Leader Election实现高可用

配置要点：controller-manager和scheduler的--leader-elect=true参数必须开启（默认值）

2.2.2 高可用关键组件

1. etcd集群：

   • 必须3节点以上（偶数节点会导致脑裂）
   • 使用高性能SSD（推荐华为OceanStor Dorado）
   • 定期快照备份（后文详述）

2. 负载均衡方案：

   mermaid复制graph TD
     A[客户端] --> B{HAProxy+Keepalived}
     B --> C[Master1:6443]
     B --> D[Master2:6443]
     B --> E[Master3:6443]
   

   实测发现，采用独立LB节点比部署在Master上性能提升30%

2.2.3 信创适配组件

• 容器运行时：华为iSula > containerd > Docker（已弃用）
• CNI插件：Calico ARM版（需3.26+版本）
• 监控方案：Prometheus+Granfa ARM版本

3. 详细部署实操

3.1 硬件配置建议

某政务云项目实际配置参考：

注：etcd节点务必使用低延迟存储（NVMe），我们曾因使用SATA SSD导致集群频繁超时

3.2 分步部署指南

3.2.1 系统初始化（所有节点）

bash复制# 关闭防火墙（银河麒麟）
sudo systemctl stop firewalld
sudo systemctl disable firewalld

# 关闭SELinux
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

# 关闭Swap
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# 加载内核模块
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter

# 设置内核参数
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl --system

3.2.2 etcd集群部署

证书生成关键步骤（使用cfssl）：

bash复制# 生成CA证书
cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
{
  "CN": "etcd-ca",
  "key": { "algo": "rsa", "size": 2048 },
  "names": [
    {"C": "CN", "L": "Beijing", "O": "etcd", "OU": "xinchuang"}
  ]
}
EOF

# 生成服务器证书
cat <<EOF | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server - | cfssljson -bare server
{
  "CN": "etcd-server",
  "hosts": [
    "etcd1", "etcd2", "etcd3",
    "192.168.1.30", "192.168.1.31", "192.168.1.32"
  ],
  "key": { "algo": "rsa", "size": 2048 }
}
EOF

etcd服务配置示例（etcd1节点）：

ini复制[Unit]
Description=Etcd Server
After=network.target

[Service]
Type=notify
ExecStart=/usr/local/bin/etcd \
  --name=etcd1 \
  --data-dir=/var/lib/etcd \
  --listen-peer-urls=https://192.168.1.30:2380 \
  --listen-client-urls=https://192.168.1.30:2379,https://127.0.0.1:2379 \
  --advertise-client-urls=https://192.168.1.30:2379 \
  --initial-advertise-peer-urls=https://192.168.1.30:2380 \
  --initial-cluster=etcd1=https://192.168.1.30:2380,etcd2=https://192.168.1.31:2380,etcd3=https://192.168.1.32:2380 \
  --initial-cluster-token=etcd-cluster \
  --initial-cluster-state=new \
  --client-cert-auth=true \
  --trusted-ca-file=/etc/etcd/ca.pem \
  --cert-file=/etc/etcd/server.pem \
  --key-file=/etc/etcd/server.key \
  --peer-client-cert-auth=true \
  --peer-trusted-ca-file=/etc/etcd/ca.pem \
  --peer-cert-file=/etc/etcd/peer.pem \
  --peer-key-file=/etc/etcd/peer.key
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

3.2.3 Master节点初始化

关键初始化命令：

bash复制sudo kubeadm init \
  --control-plane-endpoint "192.168.1.100:6443" \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16 \
  --service-cidr=10.96.0.0/12 \
  --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers \
  --kubernetes-version v1.26.10 \
  --apiserver-cert-extra-sans=k8s-vip.example.com \
  --etcd-servers=https://192.168.1.30:2379,https://192.168.1.31:2379,https://192.168.1.32:2379 \
  --etcd-cafile=/etc/etcd/ca.pem \
  --etcd-certfile=/etc/etcd/server.pem \
  --etcd-keyfile=/etc/etcd/server.key

特别注意：--image-repository必须指定国内镜像源，否则ARM架构镜像拉取会失败

4. 生产环境运维要点

4.1 监控与告警配置

推荐监控指标：

• etcd集群：存储空间、写入延迟、心跳异常
• API Server：请求延迟、错误率、并发连接数
• 节点：CPU/内存/磁盘使用率、网络丢包率

Granfa看板配置示例：

bash复制# 创建数据源
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-datasources
  namespace: monitoring
data:
  prometheus.yaml: |
    {
      "apiVersion": 1,
      "datasources": [
        {
          "access": "proxy",
          "editable": true,
          "name": "Prometheus",
          "orgId": 1,
          "type": "prometheus",
          "url": "http://prometheus-server.monitoring.svc.cluster.local",
          "version": 1
        }
      ]
    }
EOF

4.2 备份与恢复方案

4.2.1 etcd定时备份脚本

bash复制#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
ETCD_ENDPOINTS="https://192.168.1.30:2379,https://192.168.1.31:2379,https://192.168.1.32:2379"
BACKUP_DIR="/data/etcd-backup"

ETCDCTL_API=3 etcdctl \
  --endpoints=$ETCD_ENDPOINTS \
  --cacert=/etc/etcd/ca.pem \
  --cert=/etc/etcd/server.pem \
  --key=/etc/etcd/server.key \
  snapshot save $BACKUP_DIR/etcd-snapshot-$DATE.db

# 上传到OSS（华为云OBS）
ossutil cp $BACKUP_DIR/etcd-snapshot-$DATE.db oss://mybucket/etcd-backup/ --config-file=/etc/ossutil.conf

# 保留最近7天备份
find $BACKUP_DIR -name "*.db" -mtime +7 -delete

4.2.2 灾难恢复流程

1. 准备新etcd集群
2. 从备份恢复数据：

   bash复制ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
     --name etcd-new1 \
     --initial-cluster etcd-new1=https://192.168.1.40:2380,etcd-new2=https://192.168.1.41:2380 \
     --initial-cluster-token etcd-recovery \
     --initial-advertise-peer-urls https://192.168.1.40:2380
   

3. 修改Kubernetes配置指向新etcd
4. 逐个节点滚动重启

4.3 性能调优经验

4.3.1 etcd关键参数

yaml复制# /etc/etcd/etcd.conf
# 提高存储性能
auto-compaction-retention: "1h"
max-request-bytes: 33554432 # 32MB
quota-backend-bytes: 8589934592 # 8GB

# 网络优化
heartbeat-interval: 500
election-timeout: 5000

4.3.2 kube-apiserver优化

yaml复制# /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:
  - command:
    - kube-apiserver
    - --max-requests-inflight=3000
    - --max-mutating-requests-inflight=1000
    - --watch-cache-sizes=1000
    - --event-ttl=168h

5. 故障排查手册

5.1 常见问题及解决方案

5.2 诊断命令速查

bash复制# 检查etcd集群健康
ETCDCTL_API=3 etcdctl --endpoints=$ENDPOINTS --cacert=$CA --cert=$CERT --key=$KEY endpoint health

# 查看API Server请求指标
kubectl get --raw /metrics | grep apiserver_request_total

# 诊断网络问题
kubectl run net-test --image=nicolaka/netshoot -it --rm -- /bin/bash
# 在容器内执行：
ping <target_ip>
curl -v http://<service>:<port>
traceroute <target_ip>

6. 演进路线建议

6.1 集群扩展方案

• 垂直扩展：升级Master节点配置（32核/128G）
• 水平扩展：增加Master节点（5节点或7节点）
• 多集群联邦：使用Kubefederation管理多个集群

6.2 安全加固措施

1. RBAC精细化控制：

   bash复制kubectl create role developer --verb=get,list --resource=pods,svc
   kubectl create rolebinding dev-binding --role=developer --user=dev-user
   

2. 网络策略：

   yaml复制apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: default-deny
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     - Egress
   

3. 审计日志：

   yaml复制# /etc/kubernetes/audit-policy.yaml
   apiVersion: audit.k8s.io/v1
   kind: Policy
   rules:
   - level: Metadata
     resources:
     - group: ""
       resources: ["secrets", "configmaps"]
   

7. 经验总结

在三个大型信创项目中实施多主Kubernetes集群后，我们得出以下关键经验：

1. 硬件选择：鲲鹏920+银河麒麟V10组合稳定性最佳，某项目连续运行180天无故障
2. 性能基准：
   • 3节点Master集群可支撑200节点规模
   • etcd集群写入延迟应控制在50ms以内
3. 升级策略：采用蓝绿部署方式，先建新集群再迁移应用，比原地升级风险更低
4. 文档沉淀：维护详细的运行手册和应急预案，新成员可快速上手处理故障

最后建议：生产环境部署前，务必在测试环境进行完整的破坏性测试（随机杀死节点、网络分区等），验证高可用机制的有效性。我们在某次演练中发现Keepalived配置缺陷，及时修复避免了生产事故。