1. 项目概述：为什么集群配置比部署更考验真功夫
“2021最新阿里云部署Kubernetes集群（篇2 集群配置）”这个标题，表面看是技术教程的延续，实则直指K8s落地中最容易被轻视、却最决定成败的核心环节——配置。我带过不少团队做云原生迁移，发现一个普遍现象：80%的人能照着文档把master节点跑起来，但其中60%在三天内因配置失当导致Pod反复Pending、Service无法互通、Ingress 503频发，最后不得不重装。这不是能力问题，而是对“配置即架构”这一底层逻辑缺乏体感。所谓集群配置，绝不是填几个IP、选个网络插件就完事；它本质是一套运行时契约：etcd数据一致性策略、kube-apiserver高可用握手机制、CNI插件与云厂商VPC路由表的协同逻辑、甚至Node节点上kubelet的cgroup驱动选择，都会在某个凌晨三点以“服务雪崩”的形式突然爆发。这篇内容聚焦2021年阿里云环境下的真实配置决策链——当时阿里云容器服务ACK已全面支持Terway和Flannel双CNI方案，但Terway的ENI多IP模式在大规模节点扩容时存在ARP表老化延迟，而Flannel的VXLAN封装又会吃掉约8%的网络吞吐；etcd集群必须跨可用区部署，但阿里云单可用区ECS实例的IO性能波动会导致raft日志写入超时，进而触发leader频繁切换……这些细节不会出现在官方Quick Start里，却是你第二天能否睡安稳觉的关键。适合正在阿里云上搭建生产级K8s集群的运维工程师、SRE或技术负责人，尤其适合那些已经完成基础部署、正卡在“集群看起来在跑，但业务一压就崩”阶段的实践者。接下来的内容，全部来自某金融客户真实上线前72小时的配置调优记录，不讲原理图，只说你打开终端后该敲什么、为什么这么敲、以及敲错之后怎么救。
2. 集群配置整体设计与思路拆解：从“能跑”到“稳跑”的四层校验
2.1 配置目标不是“全绿”，而是建立可验证的健康水位线
很多团队配置K8s时陷入一个误区：追求所有组件状态显示Running。这就像给汽车仪表盘贴满“正常”标签，却不检查机油压力是否在临界值。2021年阿里云环境下，我们定义了四层健康水位线，每层都对应可量化的检测命令：
基础设施层：确认云资源交付质量。执行
aliyun ecs DescribeInstances --InstanceIds ["i-bp1a..."] --output json | jq '.Instances[0].Status'，必须返回"Running"且ExpiredTime为空；同时用aliyun vpc DescribeVpcs --VpcId vpc-bp1... | jq '.Vpcs[0].CidrBlock'核对VPC网段是否与规划一致（如172.16.0.0/12），避免后续Calico IP池冲突。控制平面层：验证API Server的韧性。不只看
kubectl get componentstatuses，更要执行for i in $(seq 1 10); do curl -k https://<master-ip>:6443/healthz 2>/dev/null | grep ok; done | wc -l，要求10次中至少9次返回"ok"，否则说明etcd读写延迟超标。网络平面层：检验CNI的真实连通性。在任意Node上运行
kubectl run test-pod --image=busybox:1.31 --restart=Never --rm -it -- sh -c "ping -c 3 10.244.1.2"（目标为另一Node的Pod IP），失败率需低于5%，且tcpdump -i any port 8472（VXLAN端口）应捕获到双向包。工作负载层：测试调度器与存储的协同。部署一个带PVC的Nginx，观察
kubectl describe pod nginx中Events是否出现"Successfully assigned"而非"FailedScheduling"，并确认kubectl exec nginx -- df -h /usr/share/nginx/html显示挂载点容量正确。
这套分层校验法，让我们在某次配置中提前发现阿里云SLB后端服务器组权重未同步问题——虽然所有Pod显示Running，但curl http://<slb-ip>返回503的比例高达37%，根源是SLB健康检查路径配置为"/healthz"而实际Pod监听的是"/"。
2.2 方案选型：为什么放弃ACK托管版，坚持自建+Ansible？
2021年阿里云容器服务ACK已提供托管K8s，但我们在某电商大促系统中仍选择自建集群，核心原因有三：
第一，内核参数深度调优需求。大促期间Node需开启net.ipv4.tcp_tw_reuse=1和fs.file-max=2097152，而ACK托管版禁止修改宿主机内核参数。我们通过Ansible Playbook在ECS初始化时注入/etc/sysctl.d/99-k8s.conf，并在/etc/cloud/cloud.cfg中添加runcmd: [ "sysctl -p /etc/sysctl.d/99-k8s.conf" ]确保重启生效。
第二，镜像仓库私有化策略。客户要求所有镜像必须经内部Harbor扫描后才允许拉取，而ACK默认使用公网Docker Hub。我们通过Ansible在每个Node的/var/lib/kubelet/config.yaml中配置imageGCHighThresholdPercent: 85和imageGCLowThresholdPercent: 80，并修改/etc/systemd/system/kubelet.service.d/10-kubeadm.conf，追加--pod-infra-container-image=registry.internal/pause:3.2强制使用私有pause镜像。
第三，网络故障隔离能力。ACK托管版的Master节点网络与Worker节点共享同一安全组，一旦Worker节点遭受DDoS攻击，可能波及Master。我们采用物理隔离：Master节点部署在独立VPC（vpc-mgr），通过高速通道与业务VPC（vpc-prod）互联，并在vpc-mgr的安全组中仅开放6443、2379-2380端口，其他端口全部拒绝。
这套方案使集群在2021年双十一大促中实现99.995%可用性，而同期使用ACK托管版的测试集群在流量峰值时出现3次API Server不可用（每次持续12-47秒）。
2.3 配置演进路线：从单Master到高可用的平滑升级路径
很多团队一上来就部署3 Master节点，结果因etcd证书配置错误导致集群脑裂。我们的经验是分三步走：
第一步：单Master验证核心链路
使用kubeadm init --pod-network-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/12 --kubernetes-version=v1.20.11初始化，重点验证：
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.ymlkubectl create deployment nginx --image=nginx:1.20.1kubectl expose deployment nginx --port=80 --type=NodePort
此阶段不启用任何高可用组件，目标是确认CNI、DNS、Ingress Controller（我们选Traefik v2.4）能闭环工作。
第二步：静态Pod模式添加第二个Master
在第二台ECS上不执行kubeadm init，而是直接创建/etc/kubernetes/manifests/kube-apiserver.yaml，关键参数：
spec: containers: - command: - kube-apiserver - --advertise-address=172.16.10.2 # 第二台Master内网IP - --etcd-servers=https://172.16.10.1:2379,https://172.16.10.2:2379,https://172.16.10.3:2379 - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key此模式绕过kubeadm证书签发流程，直接复用首台Master的证书，避免因--certificate-key参数错误导致etcd集群分裂。
第三步：通过kubeadm join升级为标准HA集群
当静态Pod模式稳定运行24小时后，执行kubeadm init phase upload-certs --upload-certs生成新证书密钥，再在第三台Master执行kubeadm join ... --control-plane --certificate-key <key>。此时etcd自动完成集群扩缩容，无需手动操作etcdctl member add。
这条路径让我们在某政务云项目中，将HA集群上线时间从预估的5天压缩至38小时，且零配置回滚。
3. 核心细节解析与实操要点：每个参数背后的血泪教训
3.1 etcd集群配置：跨可用区部署的三个致命陷阱
etcd是K8s的“心脏起搏器”，2021年阿里云环境下，其配置失误占集群故障的42%。我们踩过的坑集中在以下三点：
陷阱一：跨可用区延迟导致raft心跳超时
阿里云不同可用区间网络延迟通常为0.5-2ms，看似很低，但etcd raft心跳默认超时时间为1000ms（--heartbeat-interval=1000）。当网络抖动叠加磁盘IO延迟，极易触发failed to send out heartbeat on time告警。解决方案是动态调整：在/etc/kubernetes/manifests/etcd.yaml中增加：
command: - etcd - --heartbeat-interval=500 - --election-timeout=5000 - --quota-backend-bytes=8589934592 # 8GB，避免disk space exceeded注意--election-timeout必须是--heartbeat-interval的5-10倍，否则选举过于频繁。
陷阱二：VPC路由表未同步引发脑裂
某次我们将etcd节点分散在cn-hangzhou-g和cn-hangzhou-h可用区，但VPC路由表中缺少指向对端可用区的路由条目（目标网段172.16.10.0/24，下一跳为对端可用区的路由器接口）。结果etcd成员间TCP连接能建立，但HTTP探针持续失败。修复方法：在阿里云VPC控制台，进入“路由表”→“添加路由条目”，目标网段填写对端可用区节点IP段，下一跳选择“云企业网CEN”或“高速通道”。
陷阱三：证书SAN缺失导致TLS握手失败kubeadm init生成的etcd证书默认只包含localhost和Node IP，但HA场景下Master节点需通过域名访问etcd。我们在kubeadm-config.yaml中显式声明：
kind: ClusterConfiguration etcd: local: serverCertSANs: - "etcd-master-01.internal" - "etcd-master-02.internal" - "172.16.10.1" - "172.16.10.2"然后执行kubeadm init --config kubeadm-config.yaml，确保所有etcd成员证书包含完整SAN列表。
提示：验证etcd健康状态不要只信
etcdctl endpoint health，必须执行etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint status -w table，检查IS LEADER列是否全为true，且RAFT TERM数值一致。
3.2 CNI网络插件选型：Terway ENI vs Flannel VXLAN的硬核对比
2021年阿里云环境下，CNI选择本质是“网络性能”与“运维复杂度”的权衡。我们用真实压测数据说话：
| 测试项 | Terway ENI多IP模式 | Flannel VXLAN模式 |
|---|---|---|
| Pod创建耗时（平均） | 1.2s | 3.8s |
| 跨Node网络延迟 | 0.3ms | 0.9ms |
| 大包吞吐（1MB） | 9.8Gbps | 8.2Gbps |
| ARP表老化时间 | 300s（需手动调大） | 无ARP依赖 |
| 故障排查难度 | 高（需查ENI、安全组、路由表三层） | 中（仅查flanneld日志） |
Terway ENI模式实操要点：
- 必须关闭Node节点的
iptables转发：echo '1' > /proc/sys/net/ipv4/ip_forward，否则ENI流量被iptables拦截 - 在阿里云ECS控制台，为每个Worker节点绑定的ENI开启“多IP模式”，并分配足够IP（建议按Node规格预分配：4核8G节点配16个IP，16核32G节点配64个IP）
- 修改
/etc/cni/net.d/10-terway.conf，将"eni" : true改为"eni": false，强制使用ENI多IP而非弹性网卡模式，避免因ENI数量限制导致Pod调度失败
Flannel VXLAN模式避坑指南：
- 关键参数
--iface=eth0必须指定为ECS的主网卡（非bond0或docker0），否则flanneld无法获取正确MTU - 在
/run/flannel/subnet.env中，将FLANNEL_MTU=1450改为FLANNEL_MTU=1400，因为阿里云VPC网络本身有50字节开销，不调小会导致TCP分片 - 启用host-gw模式替代VXLAN（仅限同VPC同交换机）：
kubectl edit cm kube-flannel-cfg -n kube-system，将"Backend": {"Type": "vxlan"}改为"Backend": {"Type": "host-gw"}，网络延迟可降至0.1ms
注意：切勿在生产环境混用两种CNI。曾有团队在Terway集群中误装Flannel DaemonSet，导致Node上同时存在
cni0和flannel.1两个网桥，Pod网络彻底混乱，最终通过ip link delete cni0和ip link delete flannel.1强制清理才恢复。
3.3 kubelet深度调优：让Node真正“懂业务”
kubelet不是简单的Pod管家，它是Node资源的“守门人”。2021年我们针对阿里云ECS特性做了五项关键调优：
1. 内存预留策略
阿里云ECS的/proc/meminfo中MemAvailable值常低于MemTotal的15%，因内核缓存占用高。我们设置--system-reserved=memory=1Gi,--kube-reserved=memory=512Mi，并计算公式：Node Allocatable Memory = MemTotal - system-reserved - kube-reserved - eviction-hard
其中eviction-hard=memory.available<512Mi，确保内存不足时kubelet主动驱逐Pod而非OOM Killer杀进程。
2. CPU管理策略
对在线业务Pod（如Java微服务），在Deployment中添加：
spec: containers: - name: app resources: requests: cpu: "1000m" memory: "2Gi" env: - name: GOMAXPROCS value: "2" # 强制Go程序使用2核，避免NUMA跨节点调度同时在kubelet启动参数中加入--cpu-manager-policy=static --topology-manager-policy=single-numa-node，确保CPU核心独占。
3. 镜像GC阈值
阿里云ESSD云盘IOPS高但容量贵，我们设--image-gc-high-threshold=85 --image-gc-low-threshold=75，并配合crictl images | awk '$2 ~ /none|<none>/ {print $1":"$2}' | xargs -r crictl rmi定时清理悬空镜像。
4. 日志轮转--container-log-max-size=100Mi --container-log-max-files=5，避免/var/log/containers/占满根分区。特别注意：阿里云ECS的/var分区默认仅20GB，需在创建ECS时选择/var独立挂载云盘。
5. cgroup驱动统一
阿里云ECS默认使用cgroupfs，但Docker 20.10+推荐systemd。我们执行：
echo '{"exec-opts": ["native.cgroupdriver=systemd"]}' > /etc/docker/daemon.json systemctl restart docker # 然后修改kubelet配置 sed -i 's/cgroup-driver=cgroupfs/cgroup-driver=systemd/' /var/lib/kubelet/kubeadm-flags.env systemctl restart kubelet否则会出现cgroup driver: cgroupfs is different from docker错误。
4. 实操过程与核心环节实现：从零开始的72小时配置实录
4.1 基础环境准备：阿里云ECS与VPC的精准配置
配置始于云资源交付，而非kubeadm init。2021年我们为某物流系统设计的集群规模为：3 Master（8核16G）、12 Worker（16核32G），全部部署在cn-shanghai地域。具体操作如下：
VPC与交换机规划：
- 创建VPC网段
172.16.0.0/12，避免与客户IDC网段10.0.0.0/8冲突 - 在可用区shanghai-a/b/c各创建一个交换机，网段分别为
172.16.1.0/24、172.16.2.0/24、172.16.3.0/24 - 为Master节点单独创建安全组
sg-master，规则仅开放：TCP 6443（API Server）TCP 2379-2380（etcd client/server）TCP 10250（kubelet API）ICMP（健康检查） - 为Worker节点创建安全组
sg-worker，规则开放：TCP 30000-32767（NodePort）TCP 80,443（Ingress）UDP 8472（Flannel VXLAN）TCP 10250（kubelet API）
ECS实例配置要点：
- 操作系统：CentOS 7.9 64位（内核3.10.0-1160），禁用SELinux（
setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config） - 磁盘：系统盘40GB高效云盘，数据盘挂载
/var/lib/kubelet和/var/lib/etcd，使用ESSD PL1云盘（单盘IOPS 5000） - 网络：主网卡绑定到Master交换机，额外绑定一块ENI用于Terway多IP（Worker节点）
- 实例启动模板：在
/etc/cloud/cloud.cfg中添加runcmd，自动执行：# 关闭swap swapoff -a && sed -i '/swap/d' /etc/fstab # 加载内核模块 modprobe br_netfilter && echo 'br_netfilter' >> /etc/modules # 配置iptables sysctl -w net.bridge.bridge-nf-call-iptables=1
实操心得：阿里云ECS创建后，务必立即执行
aliyun ecs DescribeInstances --InstanceIds ["i-bp1..."] --output json | jq '.Instances[0].NetworkInterfaces.NetworkInterface[].PrimaryIpAddress'，确认分配的内网IP与规划一致。曾有客户因VPC DHCP地址池耗尽，导致ECS获取到100.64.x.x网段IP，与K8s Service CIDR冲突，整个集群网络瘫痪。
4.2 控制平面配置：kubeadm init的12个关键参数详解
kubeadm init不是一条命令，而是一份精密的配置契约。2021年我们使用的完整命令如下（已脱敏）：
kubeadm init \ --kubernetes-version=v1.20.11 \ --pod-network-cidr=10.244.0.0/16 \ --service-cidr=10.96.0.0/12 \ --service-dns-domain=cluster.local \ --cri-socket=/var/run/dockershim.sock \ --upload-certs \ --control-plane-endpoint="k8s-api.internal:6443" \ --apiserver-advertise-address=172.16.1.10 \ --apiserver-bind-port=6443 \ --cert-dir=/etc/kubernetes/pki \ --ignore-preflight-errors=NumCPU,Mem \ --node-name=master-01 \ --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers \ --feature-gates="IPv6DualStack=true" \ --v=5参数逐条解析：
--kubernetes-version=v1.20.11：2021年LTS版本，比v1.21更稳定，且兼容所有主流CNI插件--pod-network-cidr=10.244.0.0/16：必须与后续CNI配置严格一致，Flannel默认使用此网段--service-cidr=10.96.0.0/12：避开常用网段（如10.0.0.0/8），防止与客户内网冲突--control-plane-endpoint="k8s-api.internal:6443"：配置DNS名称而非IP，便于后续HA扩展；需在阿里云PrivateZone中创建私有域名解析--apiserver-advertise-address=172.16.1.10：指定Master节点内网IP，不是ECS公网IP，否则Worker节点无法注册--image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers：使用阿里云镜像加速，避免k8s.gcr.io拉取超时--feature-gates="IPv6DualStack=true"：开启双栈支持，为未来IPv6演进留接口（虽当时未启用）--v=5：日志级别设为5，便于排查kubeadm自身问题
执行后，kubeadm会输出kubeadm join命令，必须立即保存。我们习惯将其写入/root/join-command.sh并添加执行权限，因为该命令中的--token有效期仅24小时。
4.3 网络插件部署：Flannel的定制化安装与验证
选择Flannel后，我们不直接kubectl apply -f kube-flannel.yml，而是进行三项定制：
1. 修改镜像源与版本
下载官方YAML：curl -O https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
替换镜像：
sed -i 's/quay.io\/coreos\/flannel:/registry.cn-hangzhou.aliyuncs.com\/google_containers\/flannel:/' kube-flannel.yml sed -i 's/v0.13.0/v0.13.0-amd64/' kube-flannel.yml2. 配置自定义网段与MTU
编辑kube-flannel.yml中ConfigMap部分：
data: cni-conf.json: | { "name": "cbr0", "cniVersion": "0.3.1", "plugins": [ { "type": "flannel", "delegate": { "hairpinMode": true, "isDefaultGateway": true, "mtu": 1400 # 关键！适配阿里云VPC开销 } }, { "type": "portmap", "capabilities": { "portMappings": true } } ] } net-conf.json: | { "Network": "10.244.0.0/16", # 与kubeadm init参数严格一致 "Backend": { "Type": "vxlan" } }3. 部署与验证
kubectl apply -f kube-flannel.yml # 等待1分钟，检查Pod状态 watch 'kubectl get pods -n kube-system | grep flannel' # 验证网络连通性 kubectl run busybox --image=busybox:1.31 --restart=Never --rm -it -- sh -c "ping -c 3 10.244.1.2"验证失败的典型场景与修复：
- 场景1：
flannelPod状态为CrashLoopBackOff，日志显示failed to acquire lease: context deadline exceeded
→ 原因：etcd连接超时，检查/etc/kubernetes/manifests/etcd.yaml中--initial-cluster参数是否包含所有etcd节点 - 场景2：
ping成功但curl http://10.244.1.2:80超时
→ 原因：Worker节点安全组未开放TCP 80端口，或Pod未监听0.0.0.0:80 - 场景3：跨Node
ping丢包率>20%
→ 原因：阿里云VPC路由表缺失，或ECS实例规格不支持万兆网卡（需选ecs.g7及以上）
4.4 工作节点加入：kubeadm join的隐藏参数与批量脚本
Worker节点加入不是简单复制kubeadm join命令，需根据节点角色做差异化配置：
基础join命令（无特殊参数）：
kubeadm join k8s-api.internal:6443 --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:1234567890abcdef... \ --cri-socket /var/run/dockershim.sock关键增强参数：
--node-name=worker-01：强制指定Node名称，避免使用ECS主机名（含特殊字符）--label=role=ingress：为Ingress节点打标签，便于kubectl get nodes -l role=ingress筛选--taints=node-role.kubernetes.io/ingress=:NoSchedule：污点标记，确保只有Ingress Pod可调度至此
批量加入脚本（适用于12个Worker）：
#!/bin/bash # save as join-all.sh NODES=("worker-01" "worker-02" "worker-03" "worker-04" "worker-05" "worker-06") IPS=("172.16.1.101" "172.16.1.102" "172.16.2.101" "172.16.2.102" "172.16.3.101" "172.16.3.102") for i in "${!NODES[@]}"; do ssh root@${IPS[$i]} " kubeadm join k8s-api.internal:6443 \ --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:1234567890abcdef... \ --node-name=${NODES[$i]} \ --label=zone=${IPS[$i]%.*} \ --cri-socket /var/run/dockershim.sock " & done wait加入后必做三件事：
- 执行
kubectl label node worker-01 node-role.kubernetes.io/worker=，补全角色标签 - 运行
kubectl taint nodes worker-01 node-role.kubernetes.io/master:NoSchedule-，移除Master污点（若误加） - 检查
kubectl get nodes -o wide，确认STATUS为Ready且ROLES为<none>（Worker节点不应有master角色）
实操心得：Worker节点加入后，
kubectl get nodes可能显示NotReady，此时不要慌。先执行journalctl -u kubelet -n 100 --no-pager | grep -i "failed\|error"，90%的问题是Docker未启动或/etc/kubernetes/kubelet.conf权限错误（应为600）。我们习惯在加入前统一执行systemctl enable docker kubelet && systemctl start docker kubelet。
5. 常见问题与排查技巧实录：72小时内的17个真实故障
5.1 故障速查表：症状、根因与一键修复命令
| 故障现象 | 可能根因 | 快速验证命令 | 一键修复方案 |
|---|---|---|---|
kubectl get nodes显示NotReady | kubelet未启动或配置错误 | systemctl status kubelet | systemctl start kubelet && systemctl enable kubelet |
kubectl get pods -A中coredns为Pending | CNI未部署或Pod CIDR冲突 | kubectl get cm -n kube-system kube-flannel-cfg -o yaml | grep Network | 检查kubeadm init的--pod-network-cidr与CNI配置是否一致 |
kubectl exec -it nginx -- sh报错unable to upgrade connection | kubelet未启用--enable-server | ps aux | grep kubelet | grep enable-server | 在/var/lib/kubelet/kubeadm-flags.env中添加--enable-server=true |
curl https://<master-ip>:6443返回Unauthorized | kubeconfig未配置或token过期 | kubectl config view --raw | head -20 | 重新生成：kubeadm init phase upload-certs --upload-certs |
kubectl get events出现FailedScheduling | Node资源不足或taint未处理 | kubectl describe node worker-01 | grep -A 10 "Conditions|Allocatable" | kubectl taint nodes worker-01 key=value:NoSchedule- |
kubectl logs nginx返回Error from server (BadRequest): a container name must be specified | Pod有多个容器未指定name | kubectl get pod nginx -o yaml | grep "name:" | kubectl logs nginx -c nginx |
kubectl get svc中kubernetesClusterIP为<none> | API Server未正确注册 | kubectl get endpoints kubernetes | 重启API Server：docker ps | grep apiserver | awk '{print \$1}' | xargs docker restart |
kubectl top nodes报错metrics.k8s.io/v1beta1unavailable | metrics-server未部署 | kubectl get apiservice | grep metrics | kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.4/components.yaml |
kubectl get pv显示Pending | StorageClass未创建或Provisioner不匹配 | kubectl get sc | kubectl patch sc default -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' |
kubectl describe pod nginxEvents中FailedMount | PVC未绑定或PV容量不足 | kubectl get pvc, pv | kubectl patch pvc my-pvc -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}' |
5.2 高频故障深度复盘：三次“凌晨三点”的救火实录
故障一：etcd集群脑裂，API Server拒绝服务（发生于第36小时）
现象：kubectl get nodes卡住，curl -k https://master:6443/healthz返回503，etcdctl endpoint health显示部分节点unhealthy。
排查：登录所有Master节点，执行etcdctl --endpoints=https://127.0.0.1:2379 ... endpoint status，发现master-02的RAFT TERM为123，而其他节点为125。
根因：master-02所在ECS的系统时间漂移达8秒（ntpq -p显示offset为8542ms），导致etcd raft心跳超时被踢出集群。
修复：
- 在
master-02执行systemctl stop chronyd && ntpdate -u ntp1.aliyun.com && systemctl start chronyd - 手动删除
master-02的etcd成员：etcdctl --endpoints=https://127.0.0.1:2379 ... member remove <member-id> - 重新加入：
kubeadm join ... --control-plane --certificate-key <key>
教训：阿里云ECS必须启用NTP服务，且在/etc/chrony.conf中配置server ntp1.aliyun.com iburst，并添加makestep 1.0 3强制校准。
