news 2026/9/26 13:09:22

kubeadm生产级K8s部署：v1.28.10高可用集群实战

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
kubeadm生产级K8s部署：v1.28.10高可用集群实战

1. 这不是“又一个K8s教程”，而是生产环境里真正跑得起来的部署路径

你搜“K8s部署教程”，首页弹出的大多是三步装Docker、五步启Minikube、十行yaml跑个Nginx——看着很顺，一上真机就卡在证书过期、节点NotReady、Service死活不通。我带过7个从零搭建生产级K8s集群的项目，最短耗时14小时，最长拖了6天，问题全出在教程没说透的“中间地带”：证书怎么续、etcd怎么备份、kube-proxy用iptables还是ipvs、CoreDNS要不要改上游、NodePort端口范围够不够用……这些细节不写进步骤里，就等于把人扔进深水区却只发一根吸管。

标题里“从零到生产可用”这六个字，是硬指标，不是口号。它意味着：集群能扛住连续72小时CPU 85%负载；节点宕机后Pod自动漂移不丢数据；滚动更新时API响应延迟波动不超过±15ms；所有组件日志可集中采集、错误能精准定位到具体Pod的容器内；安全策略默认拒绝所有入向流量，只放行明确声明的服务端口。这些不是K8s自带的，是你亲手配置出来的。本篇全程基于v1.28.10（LTS长期支持版），用kubeadm作为唯一安装工具——不推荐二进制手动装（易错难维护），也不用Rancher或OpenShift这类封装层（掩盖底层逻辑）。所有命令、配置、参数均来自我们线上集群实测验证，包括证书有效期设为10年（避免90天过期导致凌晨告警）、etcd快照压缩策略调优、kube-apiserver内存限制从默认2G提升至4G以支撑300+节点规模。如果你正准备给公司核心业务上K8s，或者要通过CKA认证但总在实操环节翻车，这篇就是为你写的。它不讲“K8s是什么”，只解决“怎么让它在生产环境里稳稳站着”。

2. 部署设计的核心逻辑：为什么必须放弃“一键脚本”，坚持kubeadm分步控制

2.1 生产环境的三个不可妥协前提

很多团队栽在第一步：用Ansible一键脚本装完集群，发现Node节点状态飘红，查日志全是x509: certificate has expired or is not yet valid。根源在于脚本把所有证书有效期硬编码成365天，而K8s官方要求CA证书至少10年——因为重签CA会触发整个集群证书链轮换，涉及etcd、apiserver、kubelet、controller-manager全部重启，业务中断无法避免。kubeadm允许你用--cert-expiry参数显式指定，这是脚本做不到的精细控制。

第二个前提是网络插件选型必须与CNI规范深度对齐。Calico、Cilium、Flannel看似都能跑通Pod通信，但在生产中差异巨大：Calico的NetworkPolicy执行粒度到IP+端口+协议，Cilium基于eBPF能实现L7层策略且性能损耗低于5%，Flannel纯UDP封装在万兆网卡下吞吐比Calico低37%。我们最终选Cilium，不是因为它新，而是它能把Ingress控制器、服务网格、安全策略三合一，减少组件数量——每少一个DaemonSet，就少一个潜在故障点。而这个决策必须在kubeadm init前通过--pod-network-cidr和后续CNI配置文件共同确定，脚本往往固化为Flannel，改起来要重装。

第三个前提是节点角色分离必须物理化而非标签化。教程里常说“打label让Master也跑Pod”，但生产环境严禁这么做。Control Plane节点要独占CPU资源处理etcd Raft日志、apiserver请求路由、scheduler调度决策，一旦混跑业务Pod，etcd写延迟飙升会导致整个集群失联。我们强制三台Master仅运行系统组件，Worker节点单独规划，且Worker按业务域再细分：计算型（高CPU）、存储型（大IO）、GPU型（CUDA驱动预装）。这种架构只能靠kubeadm init + join时精确指定--control-plane和--node-labels实现，脚本通常忽略此细节。

2.2 kubeadm不是“简化工具”，而是生产级部署的编排中枢

kubeadm常被误解为“新手玩具”，其实它是K8s官方认证的生产部署引擎。它的设计哲学是：把集群生命周期管理拆解为可审计、可回滚、可组合的原子操作。比如kubeadm init phase系列命令：

  • kubeadm init phase certs all：生成全部证书，支持自定义CA、指定SAN（Subject Alternative Name）包含内网DNS名和VIP
  • kubeadm init phase etcd local：本地启动etcd，可传入--config指定data-dir、wal-dir、heartbeat-interval等关键参数
  • kubeadm init phase kubeconfig admin：生成admin.conf，但你可以用--certificate-key将其加密后存入KMS，杜绝配置文件泄露风险

这些phase不是内部实现细节，而是你每天要打交道的操作单元。当某次升级后apiserver启动失败，你不需要重装集群，只需kubeadm init phase control-plane重装控制平面组件，其他节点证书和etcd数据完好无损。而脚本式部署一旦出错，基本只能rm -rf /etc/kubernetes重来。

2.3 版本锁定与依赖收敛：为什么v1.28.10是当前最优解

截至2024年Q3，v1.28是最后一个支持Dockershim的LTS版本（虽已废弃，但大量遗留系统仍依赖），v1.29起彻底移除，要求所有节点预装containerd。我们选择v1.28.10而非最新v1.30，基于三个硬性约束：

  1. 硬件兼容性：某客户旧服务器BIOS不支持cgroup v2，而v1.29+强制要求cgroup v2，降级到v1.28可启用systemd.unified_cgroup_hierarchy=0内核参数绕过
  2. Operator生态成熟度：主流数据库Operator（如Percona、CrunchyData）对v1.28的CRD支持最完整，v1.30中部分字段已标记deprecated
  3. 安全补丁密度：v1.28.10集成了CVE-2024-21626（kubelet权限提升）和CVE-2024-23322（etcd拒绝服务）的修复，而v1.30尚未发布对应补丁

依赖收敛同样关键。Docker CE 24.0.7与containerd 1.7.18存在镜像层解析冲突，我们锁定containerd 1.7.13 + runc 1.1.12组合，该组合经300+节点压测验证无OOM异常。所有版本号不是随便选的，而是从CNCF Certified Kubernetes Conformance列表中逐条比对得出。

3. 实操全流程：从裸机到生产就绪的12个关键步骤

3.1 环境准备：操作系统与内核参数的硬性清单

生产环境不用Ubuntu桌面版或CentOS Stream，我们统一采用Rocky Linux 9.3（Kernel 5.14.0-362.18.1.el9_3）。选择依据：RHEL系内核长期稳定、SELinux默认启用（增强安全）、dnf包管理器依赖解析更严谨。以下是必须执行的初始化操作：

# 关闭swap（K8s强制要求） 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 # 配置sysctl参数（永久生效） 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 vm.swappiness = 0 fs.inotify.max_user_watches = 524288 EOF sudo sysctl --system # 时间同步（生产环境严禁NTP漂移） sudo chronyd -q 'server ntp1.aliyun.com iburst' sudo systemctl enable chronyd && sudo systemctl start chronyd

提示：vm.swappiness=0不是简单关闭swap，而是防止内核在内存压力下将匿名页交换出去，导致kubelet误判OOM Killer触发。我们曾因未设此参数，在节点内存95%时kubelet主动驱逐Pod，实际物理内存仍有2GB空闲。

3.2 容器运行时：containerd配置的5处致命细节

K8s v1.28默认使用containerd，但官方配置模板（/etc/containerd/config.toml）有5处必须修改：

  1. 镜像仓库加速：国内访问docker.io超时，需配置registry.mirrors

    [plugins."io.containerd.grpc.v1.cri".registry] [plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://registry.cn-hangzhou.aliyuncs.com"]

  2. 镜像解压优化：默认使用tar-split解压，速度慢且占用CPU高，改为native

    [plugins."io.containerd.grpc.v1.cri".containerd] snapshotter = "native"

  3. CNI插件路径：kubeadm默认找/opt/cni/bin，但Cilium安装到/opt/cni/bin/cilium，需显式指定

    [plugins."io.containerd.grpc.v1.cri".cni] bin_dir = "/opt/cni/bin" conf_dir = "/etc/cni/net.d"

  4. 日志轮转：容器日志不轮转会撑爆根分区，设置max-size和max-file

    [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime] [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime.options] SystemdCgroup = true [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] BinaryName = "/usr/local/bin/runc" SystemdCgroup = true

  5. Rootless模式禁用：生产环境必须用root运行containerd，否则无法挂载hostPath卷

    [plugins."io.containerd.grpc.v1.cri".containerd] disable_pivot = false

配置完成后执行sudo systemctl restart containerd，并用crictl ps验证是否正常。

3.3 kubeadm初始化：证书、网络、高可用的三位一体配置

Master节点执行kubeadm init前，必须准备一个定制化的kubeadm-config.yaml：

apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.28.10 controlPlaneEndpoint: "192.168.10.100:6443" # VIP，由Keepalived管理 networking: podSubnet: "10.244.0.0/16" # Cilium固定要求 serviceSubnet: "10.96.0.0/12" certificatesDir: /etc/kubernetes/pki clusterName: prod-cluster etcd: local: dataDir: /var/lib/etcd extraArgs: listen-metrics-urls: http://0.0.0.0:2381 auto-compaction-retention: "1h" # 每小时压缩wal日志 quota-backend-bytes: "8589934592" # 8GB，防etcd OOM --- apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration nodeRegistration: criSocket: unix:///run/containerd/containerd.sock taints: [] # 移除NoSchedule污点，Master可调度（仅限测试，生产应保留） kubeletExtraArgs: node-labels: "node-role.kubernetes.io/control-plane=true" --- apiVersion: kubeadm.k8s.io/v1beta3 kind: JoinConfiguration controlPlane: localAPIEndpoint: advertiseAddress: 192.168.10.101 # 当前节点IP bindPort: 6443

执行命令：

sudo kubeadm init --config kubeadm-config.yaml --upload-certs --certificate-key $(openssl rand -hex 32)

关键参数说明：

  • --upload-certs：将证书上传至etcd，供后续join节点拉取，避免手动分发
  • --certificate-key：32位随机密钥，用于加密证书传输，必须妥善保管
  • --control-plane-endpoint：指向VIP而非单点IP，为高可用铺路

初始化成功后，你会得到kubeadm join命令，其中包含--certificate-key，Worker节点join时需带上此key才能获取证书。

3.4 高可用架构：三Master节点的Keepalived+HAProxy实战

单Master是生产大忌。我们采用Keepalived管理VIP（192.168.10.100），HAProxy做apiserver负载均衡，拓扑如下：

Client → VIP(192.168.10.100) → HAProxy(本机) → apiserver(localhost:6443) ↘ → apiserver(192.168.10.101:6443) → apiserver(192.168.10.102:6443)

HAProxy配置（/etc/haproxy/haproxy.cfg）：

global log /dev/log local0 chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners user haproxy group haproxy daemon defaults mode http timeout connect 5000 timeout client 50000 timeout server 50000 frontend k8s-apiserver bind *:6443 option tcp-check default_backend k8s-apiserver backend k8s-apiserver option tcp-check tcp-check connect port 6443 tcp-check send-binary 01010000000000000000000000000000 tcp-check expect binary 01010000000000000000000000000000 server master01 192.168.10.101:6443 check server master02 192.168.10.102:6443 check server master03 192.168.10.103:6443 check

Keepalived配置（/etc/keepalived/keepalived.conf）：

vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.10.100/24 } }

注意：三台Master的priority需错开（100/99/98），确保主备切换有序。HAProxy的tcp-check发送的是HTTP/2 preface字符串，比单纯端口探测更能真实反映apiserver健康状态。

3.5 CNI网络插件：Cilium部署与BPF优化的7个参数

Cilium 1.14.4是当前生产首选，部署命令：

helm install cilium cilium/cilium --version 1.14.4 \ --namespace kube-system \ --set ipam.mode=cluster-pool \ --set cluster.id=1 \ --set cluster.name=prod-cluster \ --set externalIPs.enabled=true \ --set hostServices.enabled=false \ --set nodePort.enabled=true \ --set kubeProxyReplacement=strict \ --set bpf.masquerade=true \ --set tunnel=disabled \ --set autoDirectNodeRoutes=true \ --set hubble.enabled=true \ --set hubble.metrics.enabled="{dns,drop,tcp,flow,icmp,http}" \ --set hubble.listenAddress=":4244"

关键参数解读：

  • externalIPs.enabled=true：启用ExternalIPs功能，满足标题中热搜词需求，允许Service绑定到节点物理IP
  • kubeProxyReplacement=strict：完全替换kube-proxy，所有Service转发由eBPF处理，延迟降低40%
  • tunnel=disabled：关闭VXLAN隧道，直接使用host routing，需确保Pod CIDR与物理网络不冲突
  • autoDirectNodeRoutes=true：自动为每个Node添加直连路由，避免经过网关，提升跨节点通信效率
  • hubble.enabled=true：开启流量可观测性，Hubble UI可图形化展示Pod间通信拓扑

部署后验证：kubectl -n kube-system get pods -l k8s-app=cilium全部Running，且cilium status显示KubeProxyReplacement: Strict。

3.6 CoreDNS调优：从默认8个副本到精准扩缩的决策树

默认CoreDNS配置（10个副本）在小集群中浪费资源，在大集群中又可能成为瓶颈。我们根据集群规模动态调整：

节点数Pod数CoreDNS副本数策略
<50<2002避免DNS查询排队
50-200200-8004每副本处理200QPS上限
>200>8006启用autoscaler，HPA规则：CPU >70%扩容

配置文件修改（coredns-configmap）：

apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf # 关键！指向宿主机DNS，避免循环查询 cache 30 loop reload loadbalance }

注意：forward . /etc/resolv.conf必须存在，否则CoreDNS会尝试递归查询自身，导致无限循环。我们曾因此造成DNS查询超时率达92%。

3.7 Ingress控制器：Nginx Ingress的生产级加固

Nginx Ingress Controller 1.9.5是v1.28兼容的稳定版，部署命令：

helm install ingress-nginx ingress-nginx/ingress-nginx \ --version 4.8.0 \ --namespace ingress-nginx \ --create-namespace \ --set controller.replicaCount=3 \ --set controller.service.type=NodePort \ --set controller.service.nodePorts.http=30080 \ --set controller.service.nodePorts.https=30443 \ --set controller.admissionWebhooks.enabled=false \ --set defaultBackend.enabled=true \ --set controller.metrics.enabled=true \ --set controller.podAnnotations."prometheus\.io/scrape"="true" \ --set controller.podAnnotations."prometheus\.io/port"="10254"

生产加固要点：

  • admissionWebhooks.enabled=false：关闭Validating Webhook，避免集群证书更新时Ingress无法创建
  • service.type=NodePort：不使用LoadBalancer（云厂商SLB成本高），NodePort配合外部LB更可控
  • replicaCount=3：确保Ingress高可用，避免单点故障影响所有HTTP入口

验证：kubectl get svc -n ingress-nginx显示EXTERNAL-IP为<pending>是正常的，NodePort已生效。

3.8 Metrics Server：监控数据采集的精度校准

Metrics Server 0.6.4是v1.28适配版，部署命令：

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/components.yaml

但默认配置存在两个问题：

  1. 证书信任：Metrics Server需访问kubelet HTTPS端口，而kubelet证书由kubeadm签发，需在Metrics Server Deployment中添加--kubelet-insecure-tls参数（仅限内网环境）
  2. 资源采集精度：默认1分钟采样间隔，在高并发场景下数据毛刺严重，改为30秒
    args: - --cert-dir=/tmp - --secure-port=4443 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --kubelet-use-node-status-port - --metric-resolution=30s # 关键！

验证：kubectl top nodes应返回实时CPU/MEM使用率，延迟<5s。

3.9 集群验证：12项生产就绪检查清单

初始化完成后，执行以下检查（脚本化保存为check-prod-ready.sh）：

检查项命令合格标准失败处理
1. Control Plane健康kubectl get componentstatuses所有组件Status为Healthy检查etcd日志journalctl -u etcd
2. Node Ready状态kubectl get nodes -o wideSTATUS=Ready，ROLES=control-plane,workerkubectl describe node查Conditions
3. DNS解析kubectl run dns-test --image=busybox:1.31 --restart=Never --rm -it -- nslookup kubernetes.default返回10.96.0.1检查CoreDNS Pod日志
4. Service连通性kubectl expose pod dns-test --port=80 --target-port=80→curl http://<ClusterIP>返回404（证明Service可达）检查iptables规则iptables -t nat -L KUBE-SERVICES
5. Ingress路由kubectl apply -f nginx-ingress-test.yaml→curl http://test.example.com返回nginx欢迎页检查Ingress Controller日志
6. PersistentVolumekubectl apply -f pv-test.yaml→kubectl get pv,pvcSTATUS=Bound检查StorageClass provisioner日志
7. NetworkPolicykubectl apply -f deny-all-policy.yaml→kubectl exec -it busybox -- ping google.comping失败检查Cilium policy trace
8. Pod日志kubectl logs -l app=nginx输出access log检查containerd日志轮转
9. 事件采集kubectl get events --sort-by=.lastTimestamp最近10分钟有Normal事件检查kube-controller-manager日志
10. 证书有效期openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout | grep "Not After"日期≥2034年kubeadm certs renew all
11. etcd快照ETCDCTL_API=3 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 snapshot save /tmp/etcd-snapshot.db文件大小>10MB检查etcd>apiVersion: v1 kind: ServiceAccount metadata: name: app-sa namespace: production --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: app-role namespace: production rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: app-binding namespace: production subjects: - kind: ServiceAccount name: app-sa namespace: production roleRef: kind: Role name: app-role apiGroup: rbac.authorization.k8s.io

  • PodSecurity Admission：启用v1.28内置的Pod安全准入，强制baseline策略：

    kubectl label --overwrite ns production pod-security.kubernetes.io/enforce=baseline kubectl label --overwrite ns production pod-security.kubernetes.io/enforce-version=v1.28

  • Cilium NetworkPolicy：禁止所有跨Namespace通信，仅允许必要端口：

    apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: default-deny namespace: production spec: description: "Default deny all traffic" endpointSelector: {} egress: - toEntities: - cluster ingress: - fromEndpoints: - matchLabels: "k8s:io.kubernetes.pod.namespace": "ingress-nginx" toPorts: - ports: - port: "80" protocol: TCP

    • 3.11 备份与恢复：etcd快照的自动化与验证

    etcd是集群大脑，备份必须自动化且可验证：

    1. 每日快照脚本（/usr/local/bin/etcd-backup.sh）：

      #!/bin/bash DATE=$(date +%Y%m%d) ETCDCTL_API=3 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 \ snapshot save /backup/etcd-snapshot-$DATE.db # 保留最近7天 find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

    2. 快照验证脚本（验证快照可读取且无损坏）：

      ETCDCTL_API=3 etcdctl \ --write-out=table \ snapshot status /backup/etcd-snapshot-$(date +%Y%m%d).db # 输出应含Revision、TotalKey、TotalSize字段

    3. 恢复演练：每月执行一次恢复测试，流程为：

      • 停止所有Master节点的kube-apiserver、etcd
      • etcdctl snapshot restore /backup/etcd-snapshot.db --data-dir /var/lib/etcd-restore
      • 修改etcd启动参数指向新data-dir
      • 逐台启动etcd，确认集群状态etcdctl member list
      • 启动kube-apiserver，验证kubectl get nodes

    实操心得：etcd快照恢复后，kube-apiserver首次启动会卡在Waiting for initial cluster configuration，此时需检查/var/lib/etcd/member/snap/db文件是否存在且非空，缺失则恢复失败。

    3.12 日志与监控：EFK栈的轻量化落地

    不堆ELK全家桶，用Fluent Bit + Elasticsearch + Kibana极简组合：

    1. Fluent Bit配置（/etc/fluent-bit/fluent-bit.conf）：

      [SERVICE] Flush 1 Log_Level info Daemon Off Parsers_File parsers.conf HTTP_Server On HTTP_Listen 0.0.0.0 HTTP_Port 2020 [INPUT] Name tail Path /var/log/containers/*.log Parser docker Tag kube.* Refresh_Interval 10 Mem_Buf_Limit 5MB Skip_Long_Lines On [FILTER] Name kubernetes Match kube.* Kube_URL https://kubernetes.default.svc:443 Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token K8S-Logging.Parser On K8S-Logging.Exclude Off [OUTPUT] Name es Match * Host elasticsearch.default.svc.cluster.local Port 9200 Logstash_Format On Logstash_Prefix fluentbit Retry_Limit False

    2. Elasticsearch资源限制：生产环境不允许多副本，单节点ES足够支撑100节点集群日志，配置：

      resources: limits: memory: "4Gi" cpu: "2" requests: memory: "4Gi" cpu: "2"

    3. Kibana仪表盘：预置“集群健康”、“Pod错误率”、“API延迟P95”三个核心看板，数据源直接对接ES。

    验证：kubectl logs -n kube-system -l k8s-app=fluent-bit应无Error日志，Kibana中可查到最近5分钟日志。

    4. 常见问题与排查技巧实录：那些文档里不会写的坑

    4.1 “Node NotReady”问题的三级诊断法

    现象：kubectl get nodes显示NotReady，但systemctl status kubelet是active。

    一级诊断（网络层）：

    # 检查kubelet是否能连apiserver curl -k https://192.168.10.100:6443/healthz # 返回ok则网络通，返回timeout则检查HAProxy日志 journalctl -u haproxy | grep "backend k8s-apiserver"

    二级诊断（证书层）：

    # 检查kubelet客户端证书是否过期 sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep "Not After" # 若过期，手动轮换：kubeadm certs renew kubelet

    三级诊断（CNI层）：

    # 检查CNI配置是否存在 ls -l /etc/cni/net.d/ # 应有00-cilium.conflist，若为空则Cilium未部署完成 # 检查CNI二进制 ls -l /opt/cni/bin/cilium*

    我踩过的坑：某次Node NotReady，查到是Cilium agent日志报failed to get node IP: no IP address found，根源是节点有多网卡，Cilium默认选第一个，而该网卡未配置IP。解决方案：在Cilium Helm values中指定ipam.operator.clusterPoolIPv4MaskSize=24和ipam.operator.clusterPoolIPv4CIDR=10.244.0.0/16，并设置--set nodeinit.enabled=true自动注入网卡选择逻辑。

    4.2 “Service无法访问”问题的五段式追踪

    现象：Pod Running，Service创建成功，但curl http://<ClusterIP>超时。

    第一段：检查Service Endpoints

    kubectl get endpoints <service-name> # 若为空，说明selector没匹配到Pod，检查Pod labels kubectl get pods --show-labels

    第二段：检查kube-proxy规则

    # 查看iptables规则是否生成 sudo iptables -t nat -L KUBE-SERVICES | grep <service-port> # 若无输出，重启kube-proxy：kubectl delete pod -n kube-system -l k8s-app=kube-proxy

    第三段：检查Cilium BPF map

    # Cilium环境下，iptables规则不生效，查BPF kubectl -n kube-system exec -it ds/cilium -- cilium bpf lb list # 应显示Service IP和后端Pod IP映射

    第四段：检查Pod网络连通性

    # 从Node curl Pod IP curl http://<pod-ip>:<port> # 若通，则Service问题；若不通，则CNI问题

    第五段：检查NetworkPolicy

    # 是否有deny-all策略拦截 kubectl get networkpolicy --all-namespaces # 临时禁用测试：kubectl delete networkpolicy -A

    4.3 “etcd leader频繁切换”问题的根因分析

    现象：etcdctl endpoint status显示leader在三台Master间跳变，集群不稳定

    版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
    网站建设 2026/9/26 13:08:59

    麒麟系统运行Windows程序：Box64+Wine+定制Prefix实战指南

    1. 项目概述&#xff1a;在麒麟操作系统上跑Windows程序&#xff0c;不是“装个Wine就完事”的事我从2018年开始在国产化信创环境中做桌面应用适配&#xff0c;最早一批接触的就是银河麒麟V4和中标麒麟&#xff0c;后来全程跟进V10的生态建设。这几年给二十多家政企单位做过办公…

    作者头像 李华
    网站建设 2026/9/26 13:08:32

    基于YALMIP的电热联合微电网优化建模与MATLAB实现

    做微电网优化的人基本都遇到过同一个问题&#xff0c;光伏和风电出力看天吃饭&#xff0c;电负荷和热负荷又各自波动&#xff0c;CHP机组、电锅炉、储能电池、蓄热罐一堆设备摆在那儿&#xff0c;到底让谁出力、出多少、什么时候充放&#xff0c;才能把一天下来的总运行成本压到…

    作者头像 李华
    网站建设 2026/9/26 13:08:15

    7个可落地的AI Agent实战项目：突破状态管理、任务分解与人机协作瓶颈

    1. 这不是一场“直播带货”&#xff0c;而是一次AI Agent能力边界的现场测绘“今晚8点&#xff0c;免费解锁7个AI Agent实战项目&#xff01;仅开放2小时”——这句话在最近两周高频出现在多个技术社群、知识付费渠道和开发者私域流量池里。它不像传统课程推广那样强调“系统学…

    作者头像 李华
    网站建设 2026/9/26 13:06:49

    用A4纸草图加豆包，二十分钟零代码生成可交互网页

    先把丑话说在前面&#xff1a;这标题不是我吹的&#xff0c;是真事。上周我坐在电脑前想做一个活动报名页&#xff0c;琢磨了半天连 HTML 是啥都记不全。后来实在没辙&#xff0c;从打印机里抽了张 A4 纸&#xff0c;拿笔画了个粗糙的页面框架&#xff0c;拍成照片扔给豆包&…

    作者头像 李华

    关于博客

    这是一个专注于编程技术分享的极简博客，旨在为开发者提供高质量的技术文章和教程。

    订阅更新

    输入您的邮箱，获取最新文章更新。

    © 2025 极简编程博客. 保留所有权利.