当甲方说‘要能抗核弹’：聊聊 K8s 架构师的防杠设计艺术-优快云博客

本文链接：https://blog.youkuaiyun.com/2201_75340297/article/details/147218068

在这里插入图片描述
$S ka g i t Va ll ey, W A, U ni t e d St a t es$

每日语录： "Don’t let perfection become procrastination. Do it now. "

$引言$

今天就围绕这个问题，来探讨下。

如果文章哪里有问题，还望指出。

最后有相关的学习群，有兴趣可以加入。

$开始$

深夜收到报警短信，集群突然宕机——这可能是每个运维人最不愿面对的噩梦。生产级Kubernetes集群的部署，远不是几条命令就能搞定的事情。本文将结合真实踩坑经验，从零拆解一个高可用、高安全、可自愈的Kubernetes生产环境该如何落地。

一、架构设计：你的集群能抗住“双11”吗？

1. 业务需求决定架构形态

场景案例：某电商公司大促期间API调用量暴增10倍，因未预留足够控制平面资源，导致API Server过载崩溃。
设计原则：
- 计算型业务（如Web服务）：优先考虑横向扩展，使用HPA（水平扩缩容）+ Cluster Autoscaler。
- IO密集型业务（如日志处理）：选择本地SSD存储+Local PersistentVolume。
- 混合负载：划分节点池（Node Pool），如gpu-worker、high-mem等。

2. 高可用设计的三个致命细节

负载均衡器的隐藏陷阱：

误区：直接使用云厂商的HTTP(S)负载均衡器。
真相：API Server需要TCP层负载均衡（如HAProxy + Keepalived），且健康检查必须配置为/readyz端点。

# HAProxy配置片段示例
backend k8s-api
  mode tcp
  balance roundrobin
  option tcp-check
  tcp-check connect port 6443
  tcp-check send GET /readyz HTTP/1.0\r\nHost:\ k8s-api\r\n\r\n
  tcp-check expect string ok
  server master1 10.0.0.1:6443 check
  server master2 10.0.0.2:6443 check
  server master3 10.0.0.3:6443 check

etcd集群的“黄金法则”：
- 跨机房部署：若跨3个机房，选择5节点（机房A:2节点，机房B:2节点，机房C:1节点）避免脑裂。
- 磁盘隔离：etcd节点禁止与其他服务共享磁盘，避免IO竞争导致心跳超时。
Worker节点的“冷热分区”：
- 热区：运行核心服务，禁用自动伸缩，确保资源充足。
- 冷区：运行批处理任务，启用Spot实例（云环境）或低优先级节点。

二、集群部署：别让工具链成为“定时炸弹”

1. 工具选型的血泪教训

kubeadm的“甜区”与“毒点”：
- 适合场景：中小规模（<200节点）、标准化环境。
- 致命缺陷：默认证书有效期仅1年，过期会导致集群瘫痪（某公司曾因此停机8小时）。
- 拯救方案：
```
# 证书到期前手动续期
kubeadm certs renew all
# 或使用cert-manager自动管理
helm upgrade cert-manager jetstack/cert-manager --set installCRDs=true
```

二进制部署的“外科手术”：

适用场景：超大规模集群、内核定制（如调整cgroup v2参数）。

操作示例（手动签发API Server证书）：

# 使用cfssl生成CA证书
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
# 生成API Server证书（必须包含LB IP和DNS）
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json \
  -hostname=10.0.0.100,k8s-api.example.com,kubernetes.default.svc \
  apiserver-csr.json | cfssljson -bare apiserver

2. 网络插件的“性能暗战”

Calico vs Cilium真实压测：
- 场景：某游戏公司从Calico迁移至Cilium后，网络延迟降低40%。
- 选型建议：
  需求 推荐方案
  简单易用 Flannel（VXLAN模式）
  网络安全策略 Calico（BGP模式）
  可观测性+服务网格 Cilium（eBPF驱动）
- 避坑指南：
  - 避免在同一个集群混用多个CNI插件。
  - 使用Cilium时需关闭kube-proxy：
```
helm install cilium cilium/cilium --namespace=kube-system \
  --set kubeProxyReplacement=strict
```

需求	推荐方案
简单易用	Flannel（VXLAN模式）
网络安全策略	Calico（BGP模式）
可观测性+服务网格	Cilium（eBPF驱动）

三、安全加固：黑客就在你身边

1. 认证体系的“三道锁”

锁1：禁用匿名访问

# /etc/kubernetes/manifests/kube-apiserver.yaml
- --anonymous-auth=false

锁2：RBAC精细化控制

反例：某公司开发人员误用cluster-admin角色，导致数据库被误删。

正解：按命名空间分配权限（示例）：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: payment
  name: payment-service-role
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list"]

锁3：审计日志追踪

记录所有敏感操作（如delete、patch）：

# audit-policy.yaml
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets"]
  verbs: ["delete", "patch"]

2. 运行时安全的“最后防线”

Pod安全策略（替代方案）：

Kubernetes 1.25+已弃用PSP，改用内置的Pod Security Admission：

# 命名空间级别强制隔离
apiVersion: v1
kind: Namespace
metadata:
  name: untrusted
  labels:
    pod-security.kubernetes.io/enforce: restricted

镜像签名验证：
- 使用cosign验证镜像签名：
```
cosign verify --key cosign.pub your-registry/app:v1
```

四、可观测性：让故障无处藏身

1. 监控体系的“黄金指标”

必监控项清单：

组件	关键指标	告警阈值
API Server	请求延迟（apiserver_request_duration_seconds）	P99 > 1s
etcd	写入延迟（etcd_disk_wal_fsync_duration_seconds）	平均值 > 100ms
kubelet	容器启动时间（kubelet_container_start_time_seconds）	90%分位 > 5s

Prometheus配置技巧：

使用Recording Rules预计算复杂指标：

groups:
- name: k8s.rules
  rules:
  - record: cluster:apiserver_request_latency:percentile99
    expr: histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

2. 日志收集的“性能杀手”

EFK架构优化：

Fluent Bit：启用多线程Pipeline，避免日志堆积：

[SERVICE]
    Flush        5
    Daemon       Off
    Log_Level    info
    HTTP_Server  On
    HTTP_Listen  0.0.0.0
    HTTP_Port    2020
    storage.path /var/log/flb-storage/

Elasticsearch：冷热数据分层，将旧索引迁移至低成本存储。

五、灾备与演练：宁可备而无用

1. 备份策略的“三二一原则”

3份副本：本地、跨区、离线（如磁带）。
2种形式：
- Velero：备份Kubernetes资源+PV快照。
- etcd快照：直接备份底层数据。
1小时恢复：定期演练恢复流程，确保RTO（恢复时间目标）达标。

2. 混沌工程的“破坏性测试”

模拟真实故障场景：

案例：某公司未测试节点宕机，导致DNS服务单点故障引发全集群瘫痪。

Chaos Mesh实验模板：

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: kill-core-dns
spec:
  action: pod-kill
  mode: one
  selector:
    labelSelectors:
      "k8s-app": "kube-dns"
  gracePeriod: 0 # 立即杀死Pod

六、升级维护：稳定压倒一切

1. 滚动升级的“禁忌之舞”

跨大版本升级（如1.24→1.26）：
- 步骤：
  1. 检查废弃API（如kubectl convert）。
  2. 先升级Master节点，再升级Worker节点。
  3. 绝对禁止跳过次要版本（如1.24→1.26需先升级到1.25）。
回滚预案：
- 保留旧版本etcd快照及二进制文件。
- 使用Velero备份关键命名空间。

2. 日常运维的“隐形战场”

资源泄露排查：
- 使用kube-score检测资源配置问题：
```
kube-score score deployment.yaml
```

垃圾回收配置：

# /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80