当前位置： 首页 > news >正文

Kubernetes最小真实集群：2节点Ubuntu 24.04生产级部署指南

news 2026/7/9 21:19:52

1. 什么是“K8s 最小真实集群”？它到底解决什么问题？

“K8s 最小真实集群”不是玩具、不是单机伪集群，更不是minikube或kind那种仅用于演示的容器化沙盒。它是我在过去三年里给中小团队、边缘计算节点、CI/CD 测试环境、甚至客户现场 PoC（概念验证）交付时反复打磨出的一套可落地、可运维、可监控、可扩展的真实生产级轻量集群形态。它的核心定义有三条硬边界：第一，必须包含至少一个独立控制平面节点（control plane node），且该节点不兼任工作负载；第二，必须有至少一个真正意义上的工作节点（worker node），与控制平面物理或逻辑隔离；第三，所有组件必须通过标准 Kubernetes API Server 对接，能原生运行 Helm Chart、支持 RBAC、具备基础网络策略能力——换句话说，你用kubectl get nodes看到的不是localhost，而是两个或以上带真实 IP 的、角色明确的节点。

为什么需要这个“最小真实”？因为太多人卡在学习和落地之间那道看不见的墙。学完kubeadm init后发现：本地跑通了，但一上云就报错；flannel网络通了，CoreDNS却一直 Pending；kubectl apply -f nginx.yaml成功，但curl http://<node-ip>:30080就是打不通；更常见的是——集群装好了，却连个基础告警都没有，Pod 崩了都不知道。这些问题，90% 不出在 Kubernetes 本身，而出在部署阶段对组件依赖关系、网络拓扑、证书生命周期、系统内核参数等真实约束条件的忽视。而“最小真实集群”，就是把这堵墙拆掉的第一块砖：它不追求高可用（HA）、不堆叠 etcd 集群、不引入 Istio 或 KubeSphere 这类重量级平台，但它强制你面对每一个真实运维场景中绕不开的细节——比如 Ubuntu 24.04 默认启用的systemd-resolved如何与 CoreDNS 冲突，比如 Docker 24.x 的 cgroup driver 默认从cgroupfs切换为systemd后导致 kubelet 启动失败，比如kubeadm join时 token 过期后如何安全续签而不重装整个集群。

我见过太多人花两周时间反复重装 k8s，最后发现只是/etc/fstab里多了一行 swap 分区挂载。也见过运维同事在客户现场，因没提前关闭ufw防火墙，导致6443和10250端口被拦截，排查三小时才定位。所以这篇指南不讲“Kubernetes 是什么”，也不罗列所有命令参数，它只聚焦一件事：用最精简的节点数、最标准的组件栈、最贴近生产环境的配置方式，一次性装出一个你能 ssh 登录、能kubectl logs查日志、能kubectl exec进容器、能curl通 Service、能接入 Prometheus 抓指标的真实集群。适合谁？刚考完 CKA 想动手验证的工程师、负责内部测试平台搭建的 DevOps、需要快速交付边缘 AI 推理节点的算法团队，以及所有厌倦了“教程能跑，实战翻车”的实践者。

2. 整体设计思路与方案选型逻辑

2.1 为什么坚持“2 节点”而非“1 节点”或“3 节点”？

很多人第一反应是：“最小不就是minikube start吗？”或者“直接上 3 节点 HA 集群更稳妥”。这两种思路在真实场景中都有明显缺陷。minikube本质是单机虚拟化封装，它的kubelet运行在 VM 内，docker.sock映射到宿主机，网络模型与真实集群完全不同——你无法复现 NodePort 不通、Service DNS 解析失败、CNI 插件初始化超时等典型问题。而盲目上 3 节点 HA，不仅增加硬件成本（尤其在边缘设备如 Jetson Orin 或树莓派集群上），更关键的是掩盖了控制平面与工作节点间最基础的通信链路问题。比如etcd集群成员发现失败、apiserver证书 SAN 缺少 worker 节点 IP、kube-proxyiptables 规则未生效等，在 3 节点下可能因冗余路径暂时“看起来正常”，但一旦某个节点宕机，故障会集中爆发，排查难度指数级上升。

我最终锁定2 节点架构：1 control plane + 1 worker，这是经过 17 次不同环境实测后的最优解。它满足三个刚性条件：第一，角色分离——控制平面不跑业务 Pod，避免资源争抢和安全风险；第二，链路可验证——所有跨节点通信（API Server ↔ kubelet、kube-proxy ↔ apiserver、CNI ↔ kube-apiserver）都必须显式打通，无任何隐藏通道；第三，故障可收敛——当 worker 节点失联，你能清晰看到kubectl get nodes中状态变为NotReady，而不是因 HA 机制自动切换导致现象模糊。更重要的是，这个结构天然适配后续扩展：加第三个节点只需kubeadm join，无需重构整个集群，所有配置范式完全复用。

2.2 为什么选择 Ubuntu 24.04 LTS 而非 CentOS Stream 或 Rocky Linux？

当前主流教程大量使用 CentOS 7/8，但自 2024 年起，CentOS Stream 已转向滚动发布模式，其内核更新节奏、systemd 版本、默认 cgroup v2 支持程度与稳定版发行版存在显著差异。我们在某金融客户现场曾遇到：同一份kubeadm配置，在 Rocky Linux 8.10 上正常，在 CentOS Stream 9 上因kernel.sysctl参数默认值变更导致net.bridge.bridge-nf-call-iptables未生效，造成 Flannel 网络不通。而 Ubuntu 24.04 LTS（Noble Numbat）作为 2024 年 4 月发布的长期支持版本，具备三大优势：一是内核版本为6.8.0-xx-generic，原生支持 cgroup v2 且默认启用，与 Kubernetes 1.28+ 完全兼容；二是systemd-resolved服务虽带来 DNS 冲突风险，但其行为可预测、可配置，比某些发行版中不可控的dnsmasq更易治理；三是官方对云镜像（AWS/Azure/GCP）和裸金属安装器支持完善，subiquity自动化安装流程成熟，极大降低环境初始化误差。

我们实测对比了 Ubuntu 24.04、Debian 12、AlmaLinux 9 在相同硬件上的 kubeadm 初始化耗时：Ubuntu 平均 217 秒，Debian 243 秒，AlmaLinux 289 秒。差异主要来自包管理器（apt vs dnf）的依赖解析效率及内核模块加载速度。对于需要快速交付的场景，这近一分钟的差距意味着一次 CI 流水线能否在 5 分钟内完成集群拉起。因此，本指南所有操作步骤、参数配置、故障排查均基于 Ubuntu 24.04.1 LTS（内核 6.8.0-45-generic）进行验证，不兼容旧版 Ubuntu 或其他发行版的“微小差异”将被明确标注。

2.3 为什么选用 containerd 而非 Docker？Docker Desktop 已成历史

Docker Engine 自 2023 年底起正式移除对dockershim的维护，Kubernetes 1.24+ 彻底弃用该组件。这意味着，如果你还在用kubeadm+ Docker，实际运行的是containerd作为底层运行时，Docker CLI 仅作为上层管理工具。这种“双层抽象”不仅增加故障面（比如docker ps可见容器但crictl ps不可见），更在调试时制造认知混乱。我们曾协助一家 IoT 公司排查设备端 Pod 启动慢的问题，最终发现是 Docker 的overlay2存储驱动在 ARM64 平台上存在元数据锁竞争，而直接使用containerd则无此问题。

因此，本指南全程采用containerd作为唯一容器运行时。它更轻量（二进制仅 28MB）、启动更快（systemctl start containerd平均耗时 0.3 秒）、配置更简洁（单一 TOML 文件/etc/containerd/config.toml）。关键在于，containerd的配置项与 Kubernetes 要求高度对齐：比如SystemdCgroup = true直接对应 kubelet 的--cgroup-driver=systemd参数，避免了 Docker 时代常见的cgroupfs/systemd混用导致 kubelet 启动失败。所有crictl命令（如crictl ps,crictl logs）均可直接替代docker命令进行底层调试，且输出格式与 CRI 标准完全一致。这不是为了“炫技”，而是让学习者从第一天起就建立对 Kubernetes 底层运行时的正确认知——容器不是 Docker 的专利，而是 CRI 接口的实现。

2.4 为什么 CNI 选定 Flannel v0.24.2 而非 Calico 或 Cilium？

CNI 插件选择是集群网络稳定性的基石。Calico 功能强大，但其birdBGP 路由进程在小型集群中属于过度设计，且calicoctl配置复杂度远超必要；Cilium 基于 eBPF，性能优异，但在 Ubuntu 24.04 的6.8内核上需手动编译 eBPF 字节码，对新手极不友好。Flannel v0.24.2（2024 年 3 月发布）则精准匹配“最小真实”需求：它仅依赖etcd或kubernetes API作为后端存储，无需额外部署路由守护进程；其host-gw模式在同网段节点间直连，延迟低于 0.1ms；vxlan模式在跨网段场景下封装开销可控（实测吞吐下降 <8%）。更重要的是，Flannel 的故障现象极其明确：如果flanneldPod 启动失败，kubelet会持续报Failed to run pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox；如果 VXLAN 设备flannel.1未创建，则ip link show中完全不可见——这种“非黑即白”的状态，极大降低了网络问题的模糊性。

我们对比了三种 CNI 在 2 节点集群中的初始化时间：Flannel 平均 8.2 秒，Calico 23.7 秒，Cilium 41.5 秒。Flannel 的轻量不仅体现在速度，更在于其配置文件仅需 3 行关键参数（Network,SubnetLen,Backend.Type），而 Calico 需要维护IPPool、BGPConfiguration、FelixConfiguration等 7 类 CRD 资源。对于目标是“快速获得一个能工作的集群”的用户，Flannel 是唯一合理选择。

3. 核心细节解析与实操要点

3.1 系统级前置准备：不只是swapoff -a

绝大多数失败源于系统初始化不彻底。以下步骤必须在两台机器上逐条执行、逐条验证，缺一不可：

  1. 禁用 swap 并永久移除

    sudo swapoff -a # 永久注释 /etc/fstab 中 swap 行（不能只删，防止重装系统后恢复） sudo sed -i '/swap/ s/^/#/' /etc/fstab # 验证：free -h 中 swap 行应显示 0B

  2. 配置内核模块自动加载
    Kubernetes 依赖br_netfilter、overlay等模块。Ubuntu 24.04 默认不自动加载，需手动写入：

    cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf br_netfilter overlay EOF sudo modprobe br_netfilter overlay # 验证：lsmod | grep -E "(br_netfilter|overlay)" 应有输出

  3. 设置 sysctl 参数并持久化
    关键参数共 4 项，缺一不可：

    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 EOF sudo sysctl --system # 验证：sysctl net.bridge.bridge-nf-call-iptables 应返回 1

    提示：vm.swappiness=0是硬性要求。Ubuntu 24.04 默认值为 60，若不修改，当内存压力大时内核会主动交换匿名页，导致 kubelet OOM 被杀，现象为kubectl get nodes显示NotReady且journalctl -u kubelet中出现OOM killed process。

  4. 关闭防火墙并禁用 ufw

    sudo ufw disable sudo systemctl disable ufw # 验证：sudo ufw status 应显示 `Status: inactive`

    注意：不要试图“放行特定端口”，ufw 的规则链会干扰iptables由 kube-proxy 生成的规则，导致 Service 流量转发失败。真实生产环境应使用云厂商安全组或专用防火墙设备，而非节点级 ufw。

  5. 配置 systemd-resolved 兼容性
    Ubuntu 24.04 默认启用systemd-resolved，其监听53端口并与 CoreDNS 冲突。必须将其降级为 stub resolver：

    echo "DNSStubListener=no" | sudo tee -a /etc/systemd/resolved.conf sudo systemctl restart systemd-resolved # 验证：sudo ss -tuln | grep :53 应无输出（表示 resolved 不再监听 53）

3.2 containerd 配置：绕过runc版本陷阱

Ubuntu 24.04 自带runc版本为1.1.12，而 Kubernetes 1.28+ 要求runc >= 1.1.7且推荐1.1.12+。表面看已满足，但实测发现runc1.1.12 在 ARM64 平台存在seccomp过滤器兼容性问题，导致 Pod 启动时卡在ContainerCreating。解决方案是升级至runc 1.1.13（2024 年 5 月发布）：

# 下载预编译二进制（amd64） wget https://github.com/opencontainers/runc/releases/download/v1.1.13/runc.amd64 sudo install -m 755 runc.amd64 /usr/local/bin/runc # 验证：runc --version 应输出 1.1.13

然后配置 containerd 使用systemdcgroup driver（关键！）：

sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml # 修改 config.toml 中 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] 段： # SystemdCgroup = true （取消注释并设为 true） sudo systemctl restart containerd # 验证：sudo crictl info | grep systemd 应返回 "systemd"

实操心得：SystemdCgroup = true必须与 kubelet 的--cgroup-driver=systemd严格一致。若此处设为false，kubelet 启动时会报failed to run Kubelet: misconfiguration: cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"。这个错误信息里写的 “docker” 实际指 containerd，是历史遗留命名混淆，务必注意。

3.3 kubeadm 初始化：token 与证书的生存周期管理

kubeadm init不是“一键生成”，而是精确控制集群身份的起点。以下参数必须显式指定：

sudo kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --service-cidr=10.96.0.0/12 \ --kubernetes-version=v1.28.11 \ --cri-socket=unix:///run/containerd/containerd.sock \ --upload-certs \ --ignore-preflight-errors=Swap

关键点解析：

  • --pod-network-cidr必须与 Flannel 的Network字段完全一致（后文详述），否则 Flannel 无法分配 IP；
  • --service-cidr是 ClusterIP 的地址池，10.96.0.0/12是 Kubernetes 官方推荐值，避免与公司内网段冲突；
  • --kubernetes-version显式指定版本，防止 kubeadm 自动拉取最新版导致组件不兼容；
  • --cri-socket明确指向 containerd socket，避免 kubeadm 错误探测到已卸载的 Docker socket；
  • --upload-certs启用证书分发，使后续kubeadm join能自动获取控制平面证书，无需手动拷贝。

初始化成功后，会输出kubeadm join命令。但该命令中的 token 默认 24 小时过期。生产环境中必须立即生成永不过期 token：

# 生成 0 秒过期 token（即永不过期） kubeadm token create --ttl 0s --print-join-command # 同时生成 ca cert hash（用于 join 时证书校验） openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

注意：--ttl 0s是关键。很多教程教用户kubeadm token create --ttl 24h，但这仍需定期刷新。永不过期 token 在安全可控的内网环境是合理选择，其安全性由网络隔离和节点物理访问权限保障。

3.4 Flannel 部署：yaml 文件的 3 处致命修改

官方 Flannel yaml（https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml）不能直接使用，必须修改三处：

  1. 指定 backend 类型为vxlan（第 192 行附近）：

    kind: ConfigMap apiVersion: v1 metadata: name: kube-flannel-cfg namespace: kube-system data: cni-conf.json: | { "name": "cbr0", "cniVersion": "0.3.1", "plugins": [ { "type": "flannel", "delegate": { "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", "capabilities": { "portMappings": true } } ] } net-conf.json: | { "Network": "10.244.0.0/16", # 必须与 kubeadm init --pod-network-cidr 一致 "Backend": { "Type": "vxlan" # 必须显式指定，不能留空 } }

  2. 修正net-conf.json中的 Network 值：确保与kubeadm init参数完全相同，包括 CIDR 斜杠位数。10.244.0.0/16错写成10.244.0.0/24将导致所有 Pod 获取不到 IP。

  3. 添加hostPath挂载以支持 ARM64 节点（第 285 行附近）：

    volumeMounts: - name: flannel-cfg mountPath: /etc/kube-flannel/ - name: lib-modules # 新增 mountPath: /lib/modules readOnly: true volumes: - name: flannel-cfg configMap: name: kube-flannel-cfg - name: lib-modules # 新增 hostPath: path: /lib/modules

提示：/lib/modules挂载是 ARM64 平台必需项。Flannel 的vxlan模块需加载内核vxlan.ko，而 Ubuntu 24.04 的 ARM64 镜像中/lib/modules未被 containerd 默认挂载，导致flanneld启动时报modprobe: FATAL: Module vxlan not found in directory /lib/modules/6.8.0-45-generic。

4. 实操过程与核心环节实现

4.1 控制平面节点完整部署流程（含时间戳记录）

以下为在一台 4C8G Ubuntu 24.04 虚拟机上的完整实操记录，每步均标注耗时与验证命令：

步骤 0：环境检查（耗时 23 秒）

# 检查内核版本 uname -r # 输出 6.8.0-45-generic ✓ # 检查 swap free -h | grep Swap # 输出 Swap: 0B ✓ # 检查模块 lsmod | grep br_netfilter # 有输出 ✓

步骤 1：安装 containerd（耗时 41 秒）

# 安装依赖 sudo apt-get update && sudo apt-get install -y curl gnupg2 software-properties-common # 添加 containerd 仓库 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update # 安装 containerd（不装 docker-ce） sudo apt-get install -y containerd.io # 配置 systemd cgroup driver（耗时 8 秒） sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml sudo systemctl restart containerd # 验证 sudo crictl version # 输出 Version: 0.1.0 ✓

步骤 2：安装 kubeadm/kubelet/kubectl（耗时 57 秒）

# 添加 Kubernetes 仓库 sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update # 安装指定版本（v1.28.11） sudo apt-get install -y kubelet=1.28.11-00 kubeadm=1.28.11-00 kubectl=1.28.11-00 sudo apt-mark hold kubelet kubeadm kubectl # 验证 kubeadm version # 输出 &version.Info{Major:"1", Minor:"28", GitVersion:"v1.28.11"} ✓

步骤 3：kubeadm init（耗时 186 秒）

# 执行初始化 sudo kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --service-cidr=10.96.0.0/12 \ --kubernetes-version=v1.28.11 \ --cri-socket=unix:///run/containerd/containerd.sock \ --upload-certs \ --ignore-preflight-errors=Swap # 配置 kubectl（耗时 5 秒） mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config # 验证集群状态（耗时 3 秒） kubectl get nodes # 输出 NAME STATUS ROLES AGE VERSION，STATUS 为 NotReady（正常，因无 CNI）✓

步骤 4：部署 Flannel（耗时 29 秒）

# 下载并修改 yaml curl -O https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml # 手动编辑 kube-flannel.yml，修改 Network、Backend.Type、添加 lib-modules 挂载 kubectl apply -f kube-flannel.yml # 验证（耗时 12 秒） watch -n 1 'kubectl get pods -n kube-system | grep flannel' # 2 分钟内应全部 Running ✓ kubectl get nodes # STATUS 变为 Ready ✓

步骤 5：生成永不过期 join 命令（耗时 4 秒）

JOIN_CMD=$(kubeadm token create --ttl 0s --print-join-command) CA_HASH=$(openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //') echo "$JOIN_CMD --certificate-key $CA_HASH" # 输出类似：kubeadm join 192.168.1.100:6443 --token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:... --certificate-key ...

至此，控制平面节点部署完成，总耗时约 5 分钟。所有验证命令均返回预期结果，无任何报错。

4.2 工作节点加入全流程（含 ARM64 适配）

工作节点可以是另一台 Ubuntu 24.04 x86_64 机器，也可以是树莓派 5（ARM64）。以下是通用流程：

步骤 1：基础环境准备（同控制平面，耗时 32 秒）
执行 3.1 节全部 5 步（swap、模块、sysctl、ufw、resolved），特别注意：

  • ARM64 节点需额外安装linux-modules-extra-raspi（树莓派）或linux-modules-extra-generic（通用 ARM64）以提供vxlan.ko模块：
    sudo apt-get install -y linux-modules-extra-raspi # 树莓派 # 或 sudo apt-get install -y linux-modules-extra-generic # 通用 ARM64

步骤 2：安装 containerd 与 kubeadm（耗时 48 秒）
完全复用 4.1 节步骤 1-2，但无需安装 kubectl（worker 节点不需要）。

步骤 3：执行 join 命令（耗时 112 秒）
在 worker 节点执行控制平面生成的完整命令：

sudo kubeadm join 192.168.1.100:6443 --token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:... --certificate-key ...

注意：--certificate-key参数是--upload-certs启用后才有的，若遗漏会导致x509: certificate signed by unknown authority错误。

步骤 4：验证节点状态（耗时 8 秒）
在控制平面节点执行：

kubectl get nodes -o wide # 输出应包含两行： # NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME # cp-node Ready control-plane 15m v1.28.11 192.168.1.100 <none> Ubuntu 24.04.1 LTS 6.8.0-45-generic containerd://1.7.20 # worker-node Ready <none> 2m v1.28.11 192.168.1.101 <none> Ubuntu 24.04.1 LTS 6.8.0-45-generic containerd://1.7.20

步骤 5：验证跨节点网络（耗时 15 秒）
部署一个测试 Pod 并验证 DNS 与跨节点通信：

# 创建 busybox 测试 Pod kubectl run busybox --image=busybox:1.36 --command -- sleep 3600 # 等待 Pod Running 后，进入容器 kubectl exec -it busybox -- sh # 在容器内执行： / # nslookup kubernetes.default.svc.cluster.local # 应返回 10.96.0.1 ✓ / # ping -c 3 10.244.1.2 # 假设 worker 节点 PodCIDR 是 10.244.1.0/24，应通 ✓ / # exit

4.3 集群功能验证：从kubectl到curl的全链路

一个“真实”集群必须能完成端到端业务闭环。我们以部署一个 Nginx Service 为例，验证从容器调度、网络插件、Service 代理到外部访问的完整链路：

步骤 1：部署 Nginx Deployment（耗时 6 秒）

kubectl create deployment nginx --image=nginx:1.25 kubectl scale deployment nginx --replicas=2 # 验证 Pod 分布 kubectl get pods -o wide # 应显示一个在 cp-node，一个在 worker-node ✓

步骤 2：暴露为 NodePort Service（耗时 4 秒）

kubectl expose deployment nginx --port=80 --type=NodePort # 获取 NodePort 端口 NODE_PORT=$(kubectl get service nginx -o jsonpath='{.spec.ports[0].nodePort}') echo $NODE_PORT # 通常为 30000-32767 间随机值，如 31234 ✓

步骤 3：跨节点访问验证（耗时 3 秒）
在任意节点（包括控制平面节点）执行：

# 访问本机 NodePort（应返回 nginx 欢迎页） curl -s http://localhost:$NODE_PORT | head -1 # 输出 <!DOCTYPE html> ✓ # 访问另一节点的 NodePort（关键！验证 kube-proxy iptables 规则跨节点生效） curl -s http://192.168.1.101:$NODE_PORT | head -1 # 同样输出 <!DOCTYPE html> ✓

步骤 4：Service ClusterIP 访问（耗时 5 秒）

# 获取 ClusterIP CLUSTER_IP=$(kubectl get service nginx -o jsonpath='{.spec.clusterIP}') # 从 busybox Pod 内访问（验证 kube-proxy ClusterIP 代理） kubectl exec busybox -- curl -s http://$CLUSTER_IP | head -1 # 输出 <!DOCTYPE html> ✓

步骤 5：DNS 解析验证（耗时 4 秒）

# 从 busybox Pod 内解析 Service 名称 kubectl exec busybox -- nslookup nginx.default.svc.cluster.local # 输出应包含 A 记录指向 $CLUSTER_IP ✓

这一系列验证覆盖了 Kubernetes 最核心的五大能力：容器编排（Deployment）、网络插件（Flannel PodIP）、Service 代理（NodePort/ClusterIP）、DNS 服务（CoreDNS）、跨节点通信（kube-proxy iptables）。全部通过，即证明这是一个功能完备的“最小真实集群”。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

现象可能原因排查命令解决方案
kubeadm init报错failed to load admin kubeconfig/etc/kubernetes/admin.conf权限错误ls -l /etc/kubernetes/admin.confsudo chmod 600 /etc/kubernetes/admin.conf
kubectl get nodes显示NotReady，flannelPod 为CrashLoopBackOffflannel配置中Network与--pod-network-cidr不一致kubectl logs -n kube-system <flannel-pod-name>检查kube-flannel.yml中net-conf.json的Network字段，确保与kubeadm init参数完全相同
kubectl get pods显示ContainerCreating卡住`containerd
http://www.jsqmd.com/news/1156652/

相关文章：

  • UE4SS脚本注入系统：为虚幻引擎游戏实现深度自定义模组开发
  • bRPC从入门到实践：C++高性能RPC框架编译部署与核心功能详解
  • 计算机毕设实战：个人记账系统全流程开发与避坑指南
  • 5步掌握Android设备完整性检测：Play Integrity API Checker实战指南
  • Unity蓝牙通信实战：跨平台插件方案与全链路开发指南
  • LoRA 训练 3 种自动打标工具对比：BLIP vs Deepbooru vs WD1.4，标签准确率与效率实测
  • Unity 2023核心升级：XR统一管线与GPU光照烘焙实战解析
  • PMP与NPDP双证解析：项目经理与产品经理职业路径的3个关键决策点
  • 3 种相机模型对比：针孔、鱼眼、全景在 180° FOV 下的投影误差分析
  • PyTorch Geometric 2.5 实战：Cora 节点分类 81.5% 准确率复现与 3 大调优策略
  • PyTorch 2.3 中 Softmax Loss 梯度推导：3步手写实现与数值稳定性验证
  • UltraLight VM-UNet 0.049M 参数实战：PVM 层代码详解与 ISIC2017 数据集复现
  • Unity项目发行与部署实战指南：从打包到上架全流程解析
  • 行业合规率仅23%？2026北京工商注册代办TOP5实力测评榜单 - 互联网科技品牌测评
  • 倒装芯片封装（Flip Chip）工艺演进：从凸块键合到混合键合的3个关键技术节点
  • 蓝牙 5.4 协议栈深度解析：从 RFCOMM 到 L2CAP 的 7 层数据流实战
  • ROS 2 Humble 多机通信配置：3步实现Ubuntu 22.04主机与Raspberry Pi协同
  • Cursor Pro终极激活指南：三步解锁完整AI编程功能
  • Sysstat 定时数据收集：3 种方案对比（Cron vs Systemd Timer vs Sa1/Sa2）
  • Unity游戏自动翻译插件XUnity AutoTranslator完整配置与AI大模型接入指南
  • GPT-5.5：从代码生成到意图理解，AI协作范式如何重塑开发与知识工作流
  • Linux动态壁纸引擎：为什么它能彻底改变你的桌面体验？
  • Claude Code不是官方产品：手把手搭建本地CC Switch代理工作流
  • Android 系统签名文件生成：Windows 环境报错分析与 2 种替代方案
  • 寄行李省钱攻略：哪家快递最便宜？这样寄立省一半 - 快递物流资讯
  • Calibre繁简中文转换插件终极指南：一键解决电子书阅读障碍
  • UE5.2专用服务器构建全流程：从源码编译到部署优化
  • 数字电路信号上拉与下拉技术及PIC单片机应用
  • UE5安卓移动端内存分析实战：工具链、案例与监控体系构建
  • 《2026 无锡防水补漏价格体系与消费决策白皮书正式发布》 - 徽顺虹