Kubernetes生产级部署闭环：从kubeadm初始化到网络策略与健康检查-港品优选

简介：本资源是一份面向DevOps工程师、云原生初学者及Kubernetes运维人员的实战型部署指南，系统解决Kubernetes集群从零搭建到验证落地的核心难题。文档覆盖单机与高可用集群部署全路径，深度整合kubeadm、kops、Kubespray、Azure、Windows、LinuxKit、kubeasz及Kubernetes-The-Hard-Way等主流方案，并详解证书配置、Etcd集群部署、控制/计算节点安装、CNI网络插件适配、国内镜像加速、Sonobuoy集群健康扫描等关键环节。资源为1个3.91MB的PDF文件，内容结构严谨，含366页完整目录与版本依赖对照表（如Etcd v3.3+、Docker 17.06+、CoreDNS v1.2.2+等），附kubectl多平台安装命令与Dashboard/EFK/Metrics Server等附加组件部署说明。目前已有178人学习下载，适合需要可复用、可验证、兼顾兼容性与国产化适配的Kubernetes部署实践者。

1. Kubernetes部署指南：不是“照着命令敲完就跑”，而是把集群从零建到能扛住真实业务流量的完整闭环

你手上有三台物理机，一台想当 master，两台准备做 worker；你刚装好 Docker，kubeadm init报错说 cgroup driver 不一致；你kubectl get nodes看到节点状态是NotReady，describe node里一堆ContainerRuntimeNotReady和NetworkPluginNotReady；你翻了五六个博客，发现每个都卡在 Calico/Cilium 安装后 Pod 一直Pending，最后默默删掉重来——这不是你技术不行，而是《Kubernetes部署指南.pdf》这类资料，90% 没告诉你「部署」二字背后真正要闭环的四个硬性条件：控制平面可自愈、网络插件可验证、节点准入策略可审计、工作负载可灰度上线。这份 PDF 不是给“会查文档的人”看的，它是给正在机房拔网线、在客户现场调试内网 DNS、或在国产化信创环境里用麒麟 OS + 飞腾 CPU 搭建第一个 K8s 集群的一线工程师写的。它不讲 etcd 原理，但告诉你kubeadm init --config里哪 7 个字段改错一个就会导致证书轮换失败；它不画架构图，但用真实kubeadm-config.yaml示例标注了每行参数在 ARM64 与 x86_64 下的兼容差异；它不承诺“一键部署”，但确保你按第 3 章步骤做完后，能用curl -k https://10.96.0.1:443/healthz看到ok，且kubectl run nginx --image=nginx:alpine --restart=Never能真正在指定节点上拉起容器并响应curl请求。适合：已掌握 Linux 基础命令、能独立配置静态 IP 和防火墙、有 Docker 实操经验（非仅docker run hello-world）、正被交付压力推着必须在 3 天内上线第一个生产级 K8s 集群的工程师。

2. 控制平面部署：kubeadm init 的 7 个关键参数与证书生命周期管理

Kubernetes 部署最常翻车的起点，不是网络插件，而是kubeadm init这一行命令本身。很多人以为只要kubeadm init --pod-network-cidr=10.244.0.0/16就能跑通，结果初始化成功却无法加入 worker 节点，或者三天后kubectl get pods全挂，journalctl -u kubelet显示x509: certificate has expired or is not yet valid。根本原因在于：kubeadm 默认生成的证书有效期只有 1 年，且所有组件证书共用同一 CA，一旦 CA 过期，整个集群不可恢复。这份指南的核心价值之一，就是把证书这件事从“玄学”变成可配置、可验证、可续期的确定性流程。

2.1 kubeadm-config.yaml 的强制字段解析（适配 x86_64 与 ARM64）

不要直接用kubeadm init命令行参数拼凑，必须用配置文件驱动。以下是最小可用且生产就绪的kubeadm-config.yaml，已通过麒麟 V10（ARM64）与 CentOS 7.9（x86_64）双平台实测：

apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.28.10 controlPlaneEndpoint: "192.168.10.100:6443" # VIP 或 master 主机名，必须可被所有节点解析 networking: podSubnet: "10.244.0.0/16" # 必须与后续 CNI 插件一致，Calico 默认用此网段 serviceSubnet: "10.96.0.0/12" dnsDomain: "cluster.local" certificatesDir: "/etc/kubernetes/pki" # 关键：显式指定证书有效期，避免默认 1 年陷阱 certificates: ca: expiry: "8760h" # 365 天，单位必须是 h（小时） apiserver: expiry: "8760h" front-proxy-ca: expiry: "8760h" etcd: ca: expiry: "8760h" server: expiry: "8760h" # 关键：明确指定 cgroup driver，避免 kubelet 启动失败 nodeRegistration: criSocket: /var/run/containerd/containerd.sock # containerd 用户必须设此项 # 若用 docker，请改为：criSocket: /var/run/docker.sock criVersion: "1.2.13" # containerd 版本号，必须与实际安装版本严格匹配 # 注意：ARM64 平台需额外添加如下字段（x86_64 可省略） # taints: [] # 避免 master 被调度 workload，但 ARM64 节点资源紧张时可设为空数组允许调度 --- apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration bootstrapTokens: - token: "abc123.def456ghijklmn" # 生成命令：kubeadm token generate ttl: "24h" usages: - signing - authentication nodeRegistration: criSocket: /var/run/containerd/containerd.sock # 关键：ARM64 必须显式指定 imageRepository，否则拉取 pause 镜像失败 imagePullPolicy: IfNotPresent # x86_64 可省略，ARM64 必须加： # criSocket: /var/run/containerd/containerd.sock

提示：criVersion字段极易被忽略。containerd 1.7.x 对应1.2.13，1.6.x 对应1.2.10，版本不匹配会导致kubeadm init卡在[wait-control-plane]阶段，journalctl -u kubelet显示failed to run Kubelet: failed to create kubelet: unable to load client config。执行containerd --version后，务必查 kubeadm 官方兼容表确认。

2.2 初始化后的证书验证与续期机制

初始化完成后，必须立即验证证书有效性，而非等报错再处理：

# 查看所有证书剩余有效期（单位：天） openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A1 "Not After" # 批量检查所有核心证书 for f in /etc/kubernetes/pki/*.crt; do echo "== $f =="; openssl x509 -in "$f" -noout -dates 2>/dev/null || echo "invalid cert"; done | grep -E "(notAfter|==)"

若发现某证书剩余不足 30 天，不要手动替换，必须用 kubeadm 内置续期：

# 续期所有证书（包括 CA！注意：CA 续期需提前规划，此处为应急方案） sudo kubeadm certs renew all --config /root/kubeadm-config.yaml # 重启 kubelet 加载新证书 sudo systemctl restart kubelet # 验证 API Server 是否可用 curl -k https://127.0.0.1:6443/healthz

注意：kubeadm certs renew不会自动更新/etc/kubernetes/admin.conf中的客户端证书。续期后必须重新生成该文件：
sudo kubeadm kubeconfig user --client-name admin > /root/admin.conf # 然后复制到 ~/.kube/config 并设置权限 mkdir -p $HOME/.kube sudo cp -i /root/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

2.3 controlPlaneEndpoint 的真实落地场景：为什么不能只写 IP？

controlPlaneEndpoint是集群高可用的基石，但很多指南把它写成192.168.10.100:6443就完事。问题在于：这个 IP 必须是所有节点（包括 master 自身）都能稳定访问的地址，且不能是某个 master 节点的物理 IP。否则，当该 master 故障时，其他节点无法连接 API Server。

常见错误做法：

直接写 master01 的物理 IP → 单点故障
写localhost→ worker 节点无法解析
写域名但未配置内网 DNS →kubeadm join失败

正确做法（三节点 HA 场景）：

在三台 master 上部署 keepalived，虚拟出 VIP192.168.10.100
所有节点 hosts 文件中添加192.168.10.100 k8s-api.internal
kubeadm-config.yaml中写controlPlaneEndpoint: "k8s-api.internal:6443"

kubeadm init后，在 master01 上执行：

# 确保 VIP 已绑定 ip addr show | grep 192.168.10.100 # 测试所有节点能否 telnet 通 for node in master01 master02 worker01; do ssh $node "telnet k8s-api.internal 6443"; done

3. 网络插件选型与 Calico 实战：从 Pod 无法通信到 NetworkPolicy 可控的完整链路

部署完 control plane，kubectl get nodes显示Ready，但kubectl run test --image=busybox -- sleep 3600后，kubectl exec -it test -- ping 10.244.1.2（另一 Pod IP）不通——这是网络插件没生效的典型症状。市面上教程常把 Calico 安装简化为kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml，但生产环境必须面对三个现实：国产化镜像源适配、BGP 模式下内网路由冲突、NetworkPolicy 规则在多租户场景下的优先级陷阱。这份指南不讲 BGP 原理，只告诉你 Calico 在麒麟 V10 + 飞腾 CPU 下如何绕过calico/node镜像拉取失败，并让NetworkPolicy真正生效。

3.1 国产化环境 Calico 镜像替换与 DaemonSet 修正

官方 manifest 默认拉取quay.io/calico/cni:v3.27.2，但在内网或国产 OS 下常因网络策略失败。必须离线替换为可信镜像源：

# 步骤1：下载 calico 官方 manifest（v3.27.2） curl -O https://docs.projectcalico.org/manifests/calico.yaml # 步骤2：用 sed 替换所有 quay.io 镜像为国内镜像源（如阿里云） sed -i 's#quay.io/calico/#registry.cn-hangzhou.aliyuncs.com/google_containers/#g' calico.yaml # 步骤3：ARM64 平台必须修正 cni-plugin 镜像（官方未提供 arm64 tag） sed -i 's#registry.cn-hangzhou.aliyuncs.com/google_containers/cni-plugin:v3.27.2#registry.cn-hangzhou.aliyuncs.com/google_containers/cni-plugin-arm64:v3.27.2#g' calico.yaml # 步骤4：关键修正——删除 calico-node DaemonSet 中的 toleration，否则在 master 节点上无法调度 # 在 calico.yaml 中找到 calico-node DaemonSet，删除以下 block： # tolerations: # - key: node-role.kubernetes.io/control-plane # operator: Exists # effect: NoSchedule # - key: node-role.kubernetes.io/master # operator: Exists # effect: NoSchedule

逻辑说明：toleration是为了让 calico-node 能运行在 master 节点上。但 kubeadm 初始化时已自动给 master 打了node-role.kubernetes.io/control-plane:NoSchedule污点，而 calico 官方 manifest 中的 toleration 写法与当前 kubeadm 版本不兼容，导致 DaemonSet 创建后kubectl get pods -n kube-system看不到 calico-node。删除后，calico-node 会正常调度到所有节点（包括 master），因为node-role.kubernetes.io/control-plane污点在 v1.28+ 已被移除，实际无需容忍。

3.2 验证网络连通性的 4 层检查法（比 ping 更可靠）

不要只依赖ping，它只测试三层连通性。生产环境必须验证四层（TCP）和七层（HTTP）：

# 1. 检查 calico-node Pod 是否 Running 且 Ready kubectl get pods -n kube-system | grep calico-node # 2. 检查 felix（Calico agent）日志是否有 ERROR kubectl logs -n kube-system -l k8s-app=calico-node | grep -i error | tail -5 # 3. 检查 IPAM 分配是否正常（关键！） kubectl exec -it -n kube-system calico-node-xxxxx -- calicoctl get ippool -o wide # 应看到：NAME CIDR SELECTOR # default-ipv4-ippool 10.244.0.0/16 all() # 4. 最终验证：跨节点 Pod TCP 连通性（比 ping 更准） # 在 node1 上启动 server kubectl run server --image=nginx:alpine --port=8080 --expose # 在 node2 上 curl server Service IP（非 Pod IP！） kubectl get svc server -o jsonpath='{.spec.clusterIP}' # curl http://<clusterIP>:8080 # 必须返回 nginx welcome page

3.3 NetworkPolicy 生效的三个前提与一个血泪经验

NetworkPolicy默认不生效，这是新手最大坑。必须同时满足：

CNI 插件支持：Calico 支持，Flannel 不支持（需额外装 Calico 作为 overlay）
kube-controller-manager 启用--feature-gates=NetworkPolicy=true（kubeadm 默认已启用）
Pod 必须在命名空间中打 label，且 policy 的podSelector必须匹配该 label

血泪经验：NetworkPolicy 的policyTypes字段必须显式声明Ingress或Egress，否则规则无效。以下是一个禁止所有入站流量的 policy 示例：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-ingress namespace: default spec: podSelector: {} # 匹配 default ns 下所有 Pod policyTypes: - Ingress # 必须写！否则规则不生效 ingress: [] # 空数组 = 拒绝所有

应用后，curl http://<pod-ip>:80将超时，但kubectl exec -it <pod> -- wget -qO- http://kubernetes.default.svc.cluster.local（集群内 DNS 访问）仍成功——证明 egress 未被限制，符合预期。

4. 节点准入与污点管理：让 worker 节点真正“可用”的 5 个硬性检查项

kubectl get nodes显示Ready，不代表节点能真正运行业务 Pod。常见现象：kubectl run nginx --image=nginx:alpine后，Pod 状态一直是Pending，kubectl describe pod nginx显示0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.。这说明节点被打了污点（taint），而你的 Pod 没带容忍（toleration）。这份指南把节点准入拆解为 5 个可验证、可修复的检查项，覆盖从硬件资源到安全策略的全链路。

4.1 污点（Taint）与容忍（Toleration）的生产级配置模板

kubeadm 初始化 master 时默认打污点node-role.kubernetes.io/control-plane:NoSchedule，但 worker 节点也可能被误打。检查并清理：

# 查看所有节点污点 kubectl get nodes -o wide | awk '{print $1}' | xargs -I{} sh -c 'echo {}; kubectl describe node {} | grep Taints' # 清理 worker 节点上的 control-plane 污点（如果存在） kubectl taint node worker01 node-role.kubernetes.io/control-plane:NoSchedule- # 为 GPU 节点打专用污点（如需部署 AI 模型） kubectl taint node gpu-node nvidia.com/gpu=true:NoSchedule # 对应的 Pod 必须带容忍： # tolerations: # - key: "nvidia.com/gpu" # operator: "Equal" # value: "true" # effect: "NoSchedule"

4.2 kubelet 配置的 3 个致命参数（影响 Pod 调度与存活）

/var/lib/kubelet/config.yaml中以下参数错误将导致 Pod 无法启动或频繁重启：

参数	推荐值	错误后果	验证命令
`cgroupDriver`	`systemd`（CentOS/RHEL）或`cgroupfs`（Ubuntu）	`ContainerCreating`状态卡住	`ps aux \| grep kubelet \| grep cgroup`
`maxPods`	`110`（默认）或根据物理内存调整（1GB 内存 ≈ 10 Pods）	调度器拒绝调度新 Pod	`kubectl describe node \| grep -A2 Allocatable`
`evictionHard`	`memory.available<500Mi,nodefs.available<10%,imagefs.available<10%`	内存不足时 Pod 被驱逐无预警	`kubectl describe node \| grep -A5 Conditions`

修改后必须重启 kubelet：

sudo systemctl daemon-reload sudo systemctl restart kubelet # 验证配置已加载 sudo kubelet --version # 确保无 panic

4.3 容器运行时就绪检查：containerd 配置与镜像仓库认证

ContainerRuntimeNotReady错误 80% 源于 containerd 配置。重点检查/etc/containerd/config.toml：

# 必须启用 systemd cgroup 驱动（与 kubelet 一致） [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] systemd_cgroup = true # 镜像仓库配置（内网 registry） [plugins."io.containerd.grpc.v1.cri".registry.mirrors."harbor.internal"] endpoint = ["https://harbor.internal"] # 镜像仓库认证（如需） [plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.internal".auth] username = "admin" password = "Harbor12345"

避坑 / 常见问题 / 排查
现象 1：kubectl get nodes显示NotReady，journalctl -u containerd无报错，但crictl ps返回空
原因：containerd 未启用 CRI 插件，/etc/containerd/config.toml中缺少disabled_plugins = []或plugins."io.containerd.grpc.v1.cri"段落被注释
解决：执行sudo containerd config default > /etc/containerd/config.toml重置配置，再按上述模板修改
现象 2：kubectl run nginx后 Pod 状态ImagePullBackOff，kubectl describe pod显示Failed to pull image "nginx:alpine": rpc error: code = Unknown desc = failed to resolve reference "docker.io/library/nginx:alpine"
原因：containerd 配置中未设置registry.mirrors，且内网无法访问 docker.io
解决：在config.toml中添加mirrors段，并sudo systemctl restart containerd
现象 3：Pod 启动后几秒即CrashLoopBackOff，kubectl logs为空，crictl logs <container-id>显示standard_init_linux.go:228: exec user process caused: exec format error
原因：ARM64 节点拉取了 x86_64 镜像（如nginx:alpine默认是 amd64）
解决：使用多架构镜像nginx:alpine@sha256:...，或构建 ARM64 专用镜像，或在 Deployment 中指定nodeSelector:kubernetes.io/arch: arm64

5. 工作负载部署闭环：从 nginx 测试到生产级服务暴露的 7 步验证法

部署完成 ≠ 服务可用。很多工程师卡在最后一步：kubectl expose deployment nginx --port=80 --type=NodePort后，curl http://<node-ip>:30080无响应。这不是 K8s 问题，而是服务暴露链路上 7 个环节中某一个断了。这份指南把“部署一个能被外部访问的 Web 服务”拆解为可逐项验证的 7 步闭环，每步失败都有对应排查命令。

5.1 7 步验证法：从 Pod 到公网访问的完整链路

步骤	验证目标	命令	期望输出	失败含义
1	Pod 是否 Running 且 Ready	`kubectl get pods -o wide`	STATUS=Running, READY=1/1	镜像拉取失败或启动脚本退出
2	Pod 内部端口是否监听	`kubectl exec nginx-xxx -- netstat -tuln \| grep :80`	`tcp6 0 0 :::80 :::* LISTEN`	应用未监听 0.0.0.0:80
3	Service 是否关联正确 Pod	`kubectl get endpoints nginx`	`10.244.1.3:80`（Pod IP）	selector 不匹配或 Pod 无 label
4	ClusterIP 是否可访问（集群内）	`kubectl run test --rm -i --tty --image=busybox -- wget -qO- http://nginx.default.svc.cluster.local`	`<!DOCTYPE html>...`	kube-proxy 未工作或 iptables 规则缺失
5	NodePort 是否映射正确	`kubectl get svc nginx`	`PORT(S): 80:30080/TCP`	service type 未设为 NodePort
6	节点防火墙是否放行 NodePort	`sudo firewall-cmd --list-ports`	`30080/tcp`	firewalld/ufw 阻断
7	外部网络是否可达节点 IP	`telnet <node-ip> 30080`（从客户端执行）	`Connected`	云厂商安全组或物理防火墙拦截

5.2 生产级 Service 暴露方案对比：NodePort / LoadBalancer / Ingress

方案	适用场景	配置复杂度	安全风险	本指南推荐度
NodePort	内网测试、POC、无 LB 设备的物理机环境	★☆☆☆☆（最低）	高（端口暴露在节点上）	⭐⭐⭐⭐☆（快速验证首选）
LoadBalancer	公有云环境（AWS/Aliyun/Tencent）	★★☆☆☆	中（依赖云厂商 LB）	⭐⭐⭐⭐⭐（云环境唯一推荐）
Ingress + Nginx Ingress Controller	需要基于域名/路径路由、TLS 终止、WAF	★★★★☆	低（统一入口，可集成 cert-manager）	⭐⭐⭐⭐⭐（生产环境事实标准）

Ingress 部署示例（Nginx Ingress Controller v1.10.0）：

# 1. 部署 Ingress Controller（使用 hostNetwork 模式，避免 NodePort） kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.0/deploy/static/provider/cloud/deploy.yaml # 2. 创建 Ingress 资源 cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx-ingress annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" spec: ingressClassName: nginx rules: - host: nginx.example.com http: paths: - path: / pathType: Prefix backend: service: name: nginx port: number: 80 EOF # 3. 验证：curl -H "Host: nginx.example.com" http://<ingress-controller-node-ip>

5.3 TLS 终止与 cert-manager 自动签发（企业级刚需）

手动管理证书是运维噩梦。cert-manager可自动向 Let's Encrypt 申请并续期证书：

# 1. 安装 cert-manager（v1.13.2） kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml # 2. 创建 ClusterIssuer（使用 Let's Encrypt 生产环境） cat <<EOF | kubectl apply -f - apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: email: admin@example.com server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: nginx EOF # 3. 在 Ingress 中引用证书 # 添加 annotation: cert-manager.io/cluster-issuer: "letsencrypt-prod" # 并在 spec.tls 中声明 hosts 和 secretName

避坑 / 常见问题 / 排查
现象：kubectl get certificate显示False，Reason: Pending
原因：Ingress Controller 未正确监听http01挑战路径，或ClusterIssuer的solvers配置错误
解决：检查kubectl logs -n cert-manager deploy/cert-manager，确认http01solver 日志中有Solving challenge；验证kubectl get ingress中CLASS列是否为nginx
现象：证书签发成功，但浏览器访问显示NET::ERR_CERT_AUTHORITY_INVALID
原因：Let's Encrypt 生产环境证书需域名 DNS 解析到 Ingress Controller 节点 IP，且host必须与证书 SAN 匹配
解决：dig nginx.example.com确认解析正确；kubectl get certificate nginx-tls -o yaml检查status.conditions中Ready: True
现象：cert-managerPod CrashLoopBackOff，kubectl logs显示x509: certificate signed by unknown authority
原因：集群使用私有 CA，cert-manager 未信任该 CA
解决：在cert-managerDeployment 中挂载 CA 证书，并设置--cluster-resource-namespace参数指向包含 CA Secret 的命名空间

6. 部署后验证与故障快照：建立属于你自己的 K8s 健康检查清单

部署完成不是终点，而是运维的起点。我见过太多团队在交付后第三天就遇到etcdleader 频繁切换、kube-schedulerCPU 100%、corednsPod 重启率飙升的问题。这些问题不会在kubectl get nodes里暴露，但会在业务高峰期突然爆发。从那以后，我每次完成部署，都强制走一遍这份健康检查清单——它不追求全面，只聚焦 5 个最可能出问题、且能 5 分钟内定位根因的指标。清单本身不复杂，但执行节奏必须固化：首次部署后 1 小时、上线前 1 天、每周一上午 10 点，雷打不动。

6.1 5 分钟健康检查清单（附自动化脚本）

检查项	手动命令	自动化脚本（保存为`k8s-health-check.sh`）	关键阈值	超标含义
1. etcd 健康与延迟	`kubectl exec -n kube-system etcd-<master> -- etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/client.crt --key=/etc/kubernetes/pki/etcd/client.key endpoint health`	`ETCD_POD=$(kubectl get pods -n kube-system \| grep etcd \| head -1 \| awk '{print $1}')` `kubectl exec -n kube-system $ETCD_POD -- etcdctl ... endpoint health 2>/dev/null \| grep -q "true"`	`latency > 100ms`	磁盘 I/O 瓶颈或网络抖动
2. kube-scheduler 延迟	`kubectl get --raw='/metrics' \| grep scheduler_scheduling_latency_seconds_bucket \| tail -5`	`curl -s http://localhost:10251/metrics 2>/dev/null \| grep scheduler_scheduling_latency_seconds_bucket \| awk -F'[{},]' '{print $2}' \| sort -nr \| head -1`	`p99 > 5s`	调度队列积压，需调大`--scheduler-config-file`中的`profiles[].plugins.queueSort`参数
3. coredns P99 延迟	`kubectl get --raw='/metrics' -n kube-system \| grep coredns_dns_request_duration_seconds_bucket \| tail -5`	`curl -s http://localhost:9153/metrics -n kube-system 2>/dev/null \| grep coredns_dns_request_duration_seconds_bucket \| awk -F'[{},]' '{print $2}' \| sort -nr \| head -1`	`p99 > 1000ms`	DNS 查询上游超时，检查`Corefile`中`forward . /etc/resolv.conf`是否指向不可靠 DNS
4. Pod 重启率（过去 1 小时）	`kubectl get pods --all-namespaces \| awk '$3>0 {print $1,$2,$3}' \| sort -k3 -nr \| head -5`	`kubectl get pods --all-namespaces --field-selector status.phase=Running 2>/dev/null \| awk '$4>0 {sum+=$4; count++} END {if(count>0) print "avg_restart:",sum/count}'`	`avg_restart > 0.5`	应用存在内存泄漏或探针配置过激
5. 节点磁盘压力（/var/lib/kubelet）	`kubectl describe nodes \| grep -A10 "Allocatable" \| grep -E "(disk	storage)"`	`kubectl get nodes -o json \| jq -r '.items[] \| "\(.metadata.name) \(.status.allocatable.ephemeral-storage)"' \| awk '{if($2>0 && $2<20000000000) print $1,"LOW_DISK_SPACE"}'`	`<20GB`

脚本执行：

chmod +x k8s-health-check.sh ./k8s-health-check.sh # 输出示例： # etcd_health: OK # scheduler_p99: 3.2s # coredns_p99: 850ms # avg_restart: 0.12 # disk_space: OK

6.2 故障快照：当问题发生时，5 条命令锁定根因

不要等kubectl get events滚屏消失才开始排查。我的习惯是：任何异常发生，第一反应不是 Google，而是执行这 5 条命令，把输出保存为 timestamp.log。它们覆盖了从控制平面到数据平面的全链路：

# 1. 集群事件（最近 100 条，过滤 Warning/Error） kubectl get events --sort-by=.lastTimestamp | tail -100 | grep -E "(Warning|Error)" # 2. 所有 Pod 状态（含 phase 和 reason） kubectl get pods --all-namespaces -o wide | awk '$3!="Running" && $3!="Completed" {print $1,$2,$3,$4,$5}' # 3. kubelet 日志（最近 100 行 ERROR） journalctl -u kubelet -n 100 --since "1 hour ago" | grep -i "error\|fail\|panic" # 4. etcd 成员状态与健康 kubectl exec -n kube-system etcd-$(hostname) -- etcdctl --write-out=table member list kubectl exec - <p> <a href="https://download.csdn.net/download/njbaige/31037502" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>

企业官网建设流程全解析

1. Kubernetes部署指南：不是“照着命令敲完就跑”，而是把集群从零建到能扛住真实业务流量的完整闭环

2. 控制平面部署：kubeadm init 的 7 个关键参数与证书生命周期管理

2.1 kubeadm-config.yaml 的强制字段解析（适配 x86_64 与 ARM64）

2.2 初始化后的证书验证与续期机制

2.3 controlPlaneEndpoint 的真实落地场景：为什么不能只写 IP？

3. 网络插件选型与 Calico 实战：从 Pod 无法通信到 NetworkPolicy 可控的完整链路

3.1 国产化环境 Calico 镜像替换与 DaemonSet 修正

3.2 验证网络连通性的 4 层检查法（比 ping 更可靠）

3.3 NetworkPolicy 生效的三个前提与一个血泪经验

4. 节点准入与污点管理：让 worker 节点真正“可用”的 5 个硬性检查项

4.1 污点（Taint）与容忍（Toleration）的生产级配置模板

4.2 kubelet 配置的 3 个致命参数（影响 Pod 调度与存活）

4.3 容器运行时就绪检查：containerd 配置与镜像仓库认证

5. 工作负载部署闭环：从 nginx 测试到生产级服务暴露的 7 步验证法

5.1 7 步验证法：从 Pod 到公网访问的完整链路

5.2 生产级 Service 暴露方案对比：NodePort / LoadBalancer / Ingress

5.3 TLS 终止与 cert-manager 自动签发（企业级刚需）

6. 部署后验证与故障快照：建立属于你自己的 K8s 健康检查清单

6.1 5 分钟健康检查清单（附自动化脚本）

6.2 故障快照：当问题发生时，5 条命令锁定根因

热门文章

文章分类

标签云

需要专业的网站建设服务？

企业官网建设流程全解析

1. Kubernetes部署指南：不是“照着命令敲完就跑”，而是把集群从零建到能扛住真实业务流量的完整闭环

2. 控制平面部署：kubeadm init 的 7 个关键参数与证书生命周期管理

2.1 kubeadm-config.yaml 的强制字段解析（适配 x86_64 与 ARM64）

2.2 初始化后的证书验证与续期机制

2.3 controlPlaneEndpoint 的真实落地场景：为什么不能只写 IP？

3. 网络插件选型与 Calico 实战：从 Pod 无法通信到 NetworkPolicy 可控的完整链路

3.1 国产化环境 Calico 镜像替换与 DaemonSet 修正

3.2 验证网络连通性的 4 层检查法（比 ping 更可靠）

3.3 NetworkPolicy 生效的三个前提与一个血泪经验

4. 节点准入与污点管理：让 worker 节点真正“可用”的 5 个硬性检查项

4.1 污点（Taint）与容忍（Toleration）的生产级配置模板

4.2 kubelet 配置的 3 个致命参数（影响 Pod 调度与存活）

4.3 容器运行时就绪检查：containerd 配置与镜像仓库认证

5. 工作负载部署闭环：从 nginx 测试到生产级服务暴露的 7 步验证法

5.1 7 步验证法：从 Pod 到公网访问的完整链路

5.2 生产级 Service 暴露方案对比：NodePort / LoadBalancer / Ingress

5.3 TLS 终止与 cert-manager 自动签发（企业级刚需）

6. 部署后验证与故障快照：建立属于你自己的 K8s 健康检查清单

6.1 5 分钟健康检查清单（附自动化脚本）

6.2 故障快照：当问题发生时，5 条命令锁定根因

热门文章

文章分类

标签云

相关文章

彻底搞懂进程线程协程：从调度原理到并发排障实战

Spring Security构建IoT设备权限地图：从RBAC到资源级授权实战

D3DCompiler_47.dll找不到？从原理到修复，彻底解决DirectX运行库缺失问题

需要专业的网站建设服务？