使用 kubeadm 快速搭建生产级 Kubernetes 集群：从工具介绍到完整实战

• 教程
• 云原生
• 容器编排

Kubernetes 集群的搭建一直是初学者和运维人员面前的"第一道坎"：证书签发、各组件启动顺序、网络插件选择，任何一步出错都可能导致集群无法工作。kubeadm正是为解决这一问题而生的集群引导工具，它在 Kubernetes 1.13 中正式 GA（General Availability），被官方定位为"以简单、合理安全且可扩展的方式引导最佳实践集群"的标准工具。本文以 kubeadm 工具介绍 为骨架，结合本书的 Ubuntu 上 kubeadm 实战安装文档，完整讲解 kubeadm 的能力边界、成熟度现状，以及从节点规划、软件安装、master 初始化、节点加入、网络插件部署到集群验收的全过程，让读者在阅读后能够独立搭建一套可用于学习与测试的 Kubernetes 集群。

kubeadm 基本介绍

kubeadm是一个工具包，可帮助用户以简单、合理安全和可扩展的方式引导遵循最佳实践的 Kubernetes 集群。它同时支持为您管理 Bootstrap Tokens（引导令牌），并支持集群的升级与降级操作。

kubeadm 的设计目标非常明确：建立一个通过 Kubernetes Conformance tests（一致性测试）的最小可行集群，但它不会替您安装任何附加功能插件。具体而言，它在其设计上并未为您安装网络解决方案，需要用户自行安装第三方符合 CNI 的网络解决方案（如 flannel、calico、canal 等）。

kubeadm 可以在多种设备上运行，既可以是 Linux 笔记本电脑、虚拟机、物理/云服务器，也可以是 Raspberry Pi，这使得 kubeadm 非常适合与不同种类的配置系统（如 Terraform、Ansible 等）集成。它的适用人群也很广：

• 对于新用户，kubeadm 是一种简单的方式，让您开始尝试 Kubernetes；
• 对于现有用户，它可能是第一次让您轻松测试自己的应用程序并"缝合"到一起的方式；
• 对于生态工具链，它可以作为其他安装工具、更大范围部署体系中的构建块。

kubeadm 可以在支持安装 deb 或 rpm 软件包的操作系统上非常轻松地安装。SIG Cluster Lifecycle（kubeadm 所属的 Kubernetes 特别兴趣小组）的维护者提供了预编译的软件包，同时 kubeadm 也可以在其他操作系统上使用。

与本书另一套 在 CentOS 上使用二进制方式部署 Kubernetes 集群 的方案相比：二进制部署需要手动完成 TLS 证书签发、kubeconfig 创建、各组件 systemd 单元编写等大量步骤（可参见仓库中的 kubelet 服务单元 与 kubelet 环境变量配置）；而 kubeadm 将"生成证书 → 生成 kubeconfig → 写 Static Pod 清单 → 引导 kubelet → 下发引导令牌"这一整条链路自动化，大幅降低了门槛。二进制部署适合深度学习各组件交互原理，kubeadm 则适合快速获得一个标准、可复现的集群。

kubeadm 成熟度

kubeadm 的整体功能状态曾长期处于Beta阶段，并于 2018 年 12 月 3 日发布的 Kubernetes 1.13 版本中宣布GA，可以支持生产。下表反映了其 GA 前各子功能的成熟度分级，帮助读者理解哪些能力是稳定可用的、哪些仍在演进中：

从表中可以看到：命令行体验（Command line UX）与核心实现（Implementation）最先成熟；而配置文件 API（Config file API）、自托管（Self-hosting）、kubeadm alpha 子命令、CoreDNS 集成以及 DynamicKubeletConfig 等子功能在早期仍处于 alpha 级别，处于积极开发中。随着工具的发展，创建集群的实现细节可能会稍有调整，但总体实现已经相当稳定。需要说明的是，按照 kubeadm 的定义，任何kubeadm alpha子命令都在 alpha 级别上受支持，生产环境中应谨慎使用。

支持时间表

Kubernetes 版本通常支持九个月，在此期间，如果发现严重的错误或安全问题，官方可能会从发布分支发布补丁程序版本。这一支持周期同样适用于 kubeadm。下表是早期 Kubernetes 版本的发布与停止支持时间表：

读者在实际使用中应始终选择当前仍在支持窗口内的版本，并及时关注发布分支的补丁更新；生产环境还需要参考官方最新的支持周期表。

实战：用 kubeadm 搭建 Kubernetes 测试集群

下面以仓库中 Ubuntu 上 kubeadm 实战安装文档 为例，完整演示从零开始搭建一套包含 1 个 master 与 3 个 node 的 Kubernetes 测试集群。该方案适用于学习和测试用途；生产用途的环境需要考虑各个组件的高可用，建议参考 Kubernetes 官方相关安装文档。

节点规划与系统准备

本次安装建议至少 4 台服务器或虚拟机，每台服务器 4G 内存、2 个 CPU 核心以上，基本架构为 1 台 master 节点、3 台 slave 节点。节点信息如下：

准备工作包括：

• 默认方式安装 Ubuntu Server 版本 16.04；
• 在每个节点配置主机名映射/etc/hosts：

# cat /etc/hosts 127.0.0.1 localhost 192.168.0.200 Ubuntu-master 192.168.0.201 Ubuntu-1 192.168.0.202 Ubuntu-2 192.168.0.203 Ubuntu-3

• 如果连接 gcr（Google Container Registry）网站不方便、无法下载镜像，安装过程会卡在拉取镜像阶段。此时可以预先准备离线镜像包，解压后得到多个 tar 包，使用docker load < xxxx.tar逐个导入即可。

在所有节点上安装 kubeadm

kubeadm、kubelet、kubectl 通过 apt 软件源安装。为了在国内网络环境下顺利安装，可以使用阿里云的系统源与 Kubernetes 源，配置/etc/apt/sources.list如下：

$ cat /etc/apt/sources.list # 系统安装源 deb http://mirrors.aliyun.com/ubuntu/ xenial main restricted deb http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted deb http://mirrors.aliyun.com/ubuntu/ xenial universe deb http://mirrors.aliyun.com/ubuntu/ xenial-updates universe deb http://mirrors.aliyun.com/ubuntu/ xenial multiverse deb http://mirrors.aliyun.com/ubuntu/ xenial-updates multiverse deb http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse # kubeadm及kubernetes组件安装源 deb https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main

安装 Docker，可以使用系统源的 docker.io 软件包（版本 1.13.1）：

# apt-get install docker.io Reading package lists... Done Building dependency tree Reading state information... Done docker.io is already the newest version (1.13.1-0ubuntu1~16.04.2). 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

更新源（可以不理会 GPG 的报错信息）：

# apt-get update Hit:1 http://mirrors.aliyun.com/ubuntu xenial InRelease Hit:2 http://mirrors.aliyun.com/ubuntu xenial-updates InRelease Hit:3 http://mirrors.aliyun.com/ubuntu xenial-backports InRelease Get:4 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial InRelease [8,993 B] Ign:4 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial InRelease Fetched 8,993 B in 0s (20.7 kB/s) Reading package lists... Done W: GPG error: https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 6A030B21BA07F4FB W: The repository 'https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial InRelease' is not signed. N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use. N: See apt-secure(8) manpage for repository creation and user configuration details.

在源未签名的情况下，使用--allow-unauthenticated强制安装 kubelet、kubeadm、kubectl 软件包（会同时安装依赖的 kubernetes-cni 与 socat）：

# apt-get install -y kubelet kubeadm kubectl --allow-unauthenticated Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: kubernetes-cni socat The following NEW packages will be installed: kubeadm kubectl kubelet kubernetes-cni socat 0 upgraded, 5 newly installed, 0 to remove and 4 not upgraded. Need to get 56.9 MB of archives. After this operation, 410 MB of additional disk space will be used. WARNING: The following packages cannot be authenticated! kubernetes-cni kubelet kubectl kubeadm Authentication warning overridden. Get:1 http://mirrors.aliyun.com/ubuntu xenial/universe amd64 socat amd64 1.7.3.1-1 [321 kB] Get:2 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial/main amd64 kubernetes-cni amd64 0.6.0-00 [5,910 kB] Get:3 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial/main amd64 kubelet amd64 1.10.1-00 [21.1 MB] Get:4 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial/main amd64 kubectl amd64 1.10.1-00 [8,906 kB] Get:5 https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial/main amd64 kubeadm amd64 1.10.1-00 [20.7 MB] Fetched 56.9 MB in 5s (11.0 MB/s)

kubeadm 安装完成后，就可以使用它来快速安装部署 Kubernetes 集群了。

使用 kubeadm 初始化 master 节点

在 master 节点上执行kubeadm init。因为要使用 canal 网络插件，需要在初始化时加上网络配置参数，将 Kubernetes 的 Pod 子网设置为10.244.0.0/16——注意此处不要随意修改为其他地址，因为这个值必须与后续 canal 的 yaml 中的配置保持一致，如果修改，请一并修改。

说明：初始化过程需要从 gcr 站点拉取控制平面容器镜像（kube-apiserver、kube-controller-manager、kube-scheduler、etcd 等）。如果网络不便，可以使用上文准备工作中提到的离线镜像包预先导入。

# kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.0.200 [init] Using Kubernetes version: v1.10.1 [init] Using Authorization modes: [Node RBAC] [preflight] Running pre-flight checks. [WARNING FileExisting-crictl]: crictl not found in system path Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd/crictl [preflight] Starting the kubelet service [certificates] Generated ca certificate and key. [certificates] Generated apiserver certificate and key. [certificates] apiserver serving cert is signed for DNS names [ubuntu-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.200] [certificates] Generated apiserver-kubelet-client certificate and key. [certificates] Generated etcd/ca certificate and key. [certificates] Generated etcd/server certificate and key. [certificates] etcd/server serving cert is signed for DNS names [localhost] and IPs [127.0.0.1] [certificates] Generated etcd/peer certificate and key. [certificates] etcd/peer serving cert is signed for DNS names [ubuntu-master] and IPs [192.168.0.200] [certificates] Generated apiserver-etcd-client certificate and key. [certificates] Generated sa key and public key. [certificates] Generated front-proxy-ca certificate and key. [certificates] Generated front-proxy-client certificate and key. [certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki" [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf" [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf" [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf" [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf" [controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml" [controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml" [controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml" [etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml" [init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests". [init] This might take a minute or longer if the control plane images have to be pulled. [apiclient] All control plane components are healthy after 28.003828 seconds [uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace [markmaster] Will mark node ubuntu-master as master by adding a label and a taint [markmaster] Master ubuntu-master tainted and labelled with key/value: node-role.kubernetes.io/master="" [bootstraptoken] Using token: rw4enn.mvk547juq7qi2b5f [bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials [bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token [bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster [bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace [addons] Applied essential addon: kube-dns [addons] Applied essential addon: kube-proxy Your Kubernetes master has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config You should now deploy a pod network to the cluster. Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/ You can now join any number of machines by running the following on each node as root: kubeadm join 192.168.0.200:6443 --token rw4enn.mvk547juq7qi2b5f --discovery-token-ca-cert-hash sha256:ba260d5191213382a806a9a7d92c9e6bb09061847c7914b1ac584d0c69471579

从这段输出可以完整看到 kubeadm 的工作流程，理解它在"后台"替我们做了什么：

1. Preflight 检查：检查系统环境（端口、内核参数、crictl 是否存在等）并启动 kubelet 服务；
2. 证书生成：在/etc/kubernetes/pki下生成 ca、apiserver、etcd、front-proxy、sa 等全套证书与密钥——这正是二进制部署中最繁琐的环节（可对照 创建 TLS 证书和秘钥 一文）；
3. kubeconfig 写入：为 admin、kubelet、controller-manager、scheduler 分别生成 kubeconfig 文件；
4. 控制平面部署：将 kube-apiserver、kube-controller-manager、kube-scheduler、etcd 以Static Pod 清单的形式写入/etc/kubernetes/manifests，由 kubelet 负责拉起——这就是 kubeadm 实现控制平面自举的核心机制；
5. 标记 master：给 master 节点打上node-role.kubernetes.io/master标签与污点（taint），默认阻止业务 Pod 调度到 master 上；
6. 引导令牌：生成 bootstrap token，并配置好 RBAC 规则，使节点可以通过 Bootstrap Token 提交 CSR 获取长期证书、自动审批 CSR、并支持节点客户端证书轮换；
7. 基础插件：应用 kube-dns（kube-system 命名空间）与 kube-proxy 两个必要插件。

配置 kubectl 访问集群

按初始化输出末尾的提示，在 master 节点执行如下命令配置 kubectl：

mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

这样 master 节点就配置好了，可以使用 kubectl 进行各种操作。

Slave 节点加入集群

在每台 slave 节点执行kubeadm init输出的 join 命令（包含 API Server 地址、bootstrap token 与 CA 证书哈希指纹），即可将节点加入集群：

# kubeadm join 192.168.0.200:6443 --token rw4enn.mvk547juq7qi2b5f --discovery-token-ca-cert-hash sha256:ba260d5191213382a806a9a7d92c9e6bb09061847c7914b1ac584d0c69471579 [preflight] Running pre-flight checks. [WARNING FileExisting-crictl]: crictl not found in system path Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd/crictl [discovery] Trying to connect to API Server "192.168.0.200:6443" [discovery] Created cluster-info discovery client, requesting info from "https://192.168.0.200:6443" [discovery] Requesting info from "https://192.168.0.200:6443" again to validate TLS against the pinned public key [discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "192.168.0.200:6443" [discovery] Successfully established connection with API Server "192.168.0.200:6443" This node has joined the cluster: * Certificate signing request was sent to master and a response was received. * The Kubelet was informed of the new secure connection details. Run 'kubectl get nodes' on the master to see this node join the cluster.

join 过程中值得关注的细节：

• --discovery-token-ca-cert-hash提供了CA 证书指纹校验，slave 节点会通过cluster-info获取集群信息，并用固定的公钥校验 TLS，防止中间人攻击；
• 节点通过 Bootstrap Token 向 master 提交CSR（证书签名请求），获得长期有效的客户端证书，之后 kubelet 即使用该证书与 API Server 安全通信。

检查节点与系统组件状态

在所有节点完成 join 后，在 master 上查看节点状态，此时节点通常处于 NotReady 状态——这是正常的，因为还没有安装网络插件：

# kubectl get node NAME STATUS ROLES AGE VERSION ubuntu-1 NotReady <none> 6m v1.10.1 ubuntu-2 NotReady <none> 6m v1.10.1 ubuntu-3 NotReady <none> 6m v1.10.1 ubuntu-master NotReady master 10m v1.10.1

查看 kube-system 命名空间中的系统组件 Pod：

root@Ubuntu-master:~# kubectl get pod -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE etcd-ubuntu-master 1/1 Running 0 21m 192.168.0.200 ubuntu-master kube-apiserver-ubuntu-master 1/1 Running 0 21m 192.168.0.200 ubuntu-master kube-controller-manager-ubuntu-master 1/1 Running 0 22m 192.168.0.200 ubuntu-master kube-dns-86f4d74b45-wkfk2 0/3 Pending 0 22m <none> <none> kube-proxy-6ddb4 1/1 Running 0 22m 192.168.0.200 ubuntu-master kube-proxy-7ngb9 1/1 Running 0 17m 192.168.0.202 ubuntu-2 kube-proxy-fkhhx 1/1 Running 0 18m 192.168.0.201 ubuntu-1 kube-proxy-rh4lq 1/1 Running 0 18m 192.168.0.203 ubuntu-3 kube-scheduler-ubuntu-master 1/1 Running 0 21m 192.168.0.200 ubuntu-master

可以看到：etcd、kube-apiserver、kube-controller-manager、kube-scheduler 与各节点的 kube-proxy 均已正常运行，只有 kube-dns 处于 Pending 状态——它需要在网络插件完成安装后才会正常运行。

安装 CNI 网络插件 canal

正如 kubeadm 的设计初衷所述，它不负责安装网络解决方案，需要用户自行部署 CNI 网络插件。本例选用canal（Calico 与 Flannel 的组合方案，兼具 Flannel 的简单性与 Calico 的 NetworkPolicy 能力）。部署两个文件：一个是配置 canal 的 RBAC 权限，一个是部署 canal 的 DaemonSet：

# kubectl apply -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/canal/rbac.yaml clusterrole.rbac.authorization.k8s.io "calico" created clusterrole.rbac.authorization.k8s.io "flannel" created clusterrolebinding.rbac.authorization.k8s.io "canal-flannel" created clusterrolebinding.rbac.authorization.k8s.io "canal-calico" created # kubectl apply -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/canal/canal.yaml configmap "canal-config" created daemonset.extensions "canal" created customresourcedefinition.apiextensions.k8s.io "felixconfigurations.crd.projectcalico.org" created customresourcedefinition.apiextensions.k8s.io "bgpconfigurations.crd.projectcalico.org" created customresourcedefinition.apiextensions.k8s.io "ippools.crd.projectcalico.org" created customresourcedefinition.apiextensions.k8s.io "clusterinformations.crd.projectcalico.org" created customresourcedefinition.apiextensions.k8s.io "globalnetworkpolicies.crd.projectcalico.org" created customresourcedefinition.apiextensions.k8s.io "networkpolicies.crd.projectcalico.org" created serviceaccount "canal" created

安装完成后查看 canal 与 kube-dns 的状态：

# kubectl get pod -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE canal-fc94k 3/3 Running 10 4m 192.168.0.201 ubuntu-1 canal-rs2wp 3/3 Running 10 4m 192.168.0.200 ubuntu-master canal-tqd4l 3/3 Running 10 4m 192.168.0.202 ubuntu-2 canal-vmpnr 3/3 Running 10 4m 192.168.0.203 ubuntu-3 etcd-ubuntu-master 1/1 Running 0 28m 192.168.0.200 ubuntu-master kube-apiserver-ubuntu-master 1/1 Running 0 28m 192.168.0.200 ubuntu-master kube-controller-manager-ubuntu-master 1/1 Running 0 29m 192.168.0.200 ubuntu-master kube-dns-86f4d74b45-wkfk2 3/3 Running 0 28m 10.244.2.2 ubuntu-3 kube-proxy-6ddb4 1/1 Running 0 28m 192.168.0.200 ubuntu-master kube-proxy-7ngb9 1/1 Running 0 24m 192.168.0.202 ubuntu-2 kube-proxy-fkhhx 1/1 Running 0 24m 192.168.0.201 ubuntu-1 kube-proxy-rh4lq 1/1 Running 0 24m 192.168.0.203 ubuntu-3 kube-scheduler-ubuntu-master 1/1 Running 0 28m 192.168.0.200 ubuntu-master

可以看到 canal 和 kube-dns 都已经运行正常（kube-dns Pod 获得了10.244.2.2的 Pod 网段地址，说明 Pod 网络已经打通）。此时再查看集群节点状态：

# kubectl get node NAME STATUS ROLES AGE VERSION ubuntu-1 Ready <none> 27m v1.10.1 ubuntu-2 Ready <none> 27m v1.10.1 ubuntu-3 Ready <none> 27m v1.10.1 ubuntu-master Ready master 31m v1.10.1

四个节点全部进入Ready状态，一个基本功能正常的 Kubernetes 测试环境就部署完毕了。

可选：让 master 节点也运行 Pod

默认情况下 master 节点带node-role.kubernetes.io/master污点，不会调度业务 Pod。在测试环境可以移除该污点让 master 也运行 Pod（不建议在生产环境如此操作）：

# kubectl taint nodes --all node-role.kubernetes.io/master- node "ubuntu-master" untainted taint "node-role.kubernetes.io/master:" not found taint "node-role.kubernetes.io/master:" not found taint "node-role.kubernetes.io/master:" not found

集群初始化后的扩展与验证

一套通过 kubeadm 引导的集群已经具备核心控制平面与 kube-proxy/kube-dns 基础插件，之后可以按需扩展。这里列出几个与仓库配套的常用扩展方向：

• 集群 DNS（CoreDNS/kube-dns）：kubeadm 在早期版本默认部署 kube-dns，新版本默认部署 CoreDNS。仓库中提供了 CoreDNS 部署模板，其中CLUSTER_DOMAIN、REVERSE_CIDRS、CLUSTER_DNS_IP是需要根据集群实际配置替换的占位符，Corefile 中的kubernetes插件块负责将 Service 名解析为集群域名，prometheus :9153暴露 DNS 指标，cache 30设置 30 秒缓存；
• 集群监控：可参考 使用 Prometheus 监控 Kubernetes 集群 与 heapster 安装，其中 HPA 示例清单位于 manifests/HPA；
• Ingress 控制器：可参考 Traefik Ingress 安装，仓库中的 traefik.yaml 以 DaemonSet 加hostNetwork: true方式部署 Traefik 并监听 80 端口，ingress-rbac.yaml 为 ingress ServiceAccount 绑定 cluster-admin 角色以读取 Ingress 规则；
• 存储与中间件：后台存储可参考本书最佳实践中的 存储管理 相关内容（如 NFS、Ceph、OpenEBS 等方案）。

常见问题与注意事项

结合 Ubuntu 上 kubeadm 实战安装文档 中的实操经验，总结以下常见问题：

1. 镜像拉取卡住：kubeadm init需要从 gcr 拉取控制平面镜像，网络受限时安装会卡在[init] Waiting for the kubelet to boot up the control plane as Static Pods。解决方案是提前docker load导入离线镜像包，或使用可访问的镜像仓库；
2. 节点一直 NotReady：绝大多数情况是未安装 CNI 网络插件，或--pod-network-cidr与网络插件 yaml 中的 CIDR 不一致（如本例统一为10.244.0.0/16）。注意 Pod 子网与 Service 子网（默认10.96.0.0/12）是两套独立的网段，从初始化输出可以看到 apiserver 证书中同时签发了 Service IP10.96.0.1与节点地址192.168.0.200；
3. apt 源 GPG 报错：未签名源导致的NO_PUBKEY报错可以忽略，安装时使用--allow-unauthenticated参数即可，生产环境建议正确导入官方 GPG 公钥；
4. kube-dns 处于 Pending：这是网络插件尚未就绪的正常表现，网络插件安装完成后会自动变为 Running；
5. 加入集群的 token 过期：kubeadm init输出的 token 默认有效期 24 小时，过期后可在 master 上执行kubeadm token create --print-join-command重新生成；
6. 版本一致性：kubelet、kubeadm、kubectl 应尽量保持相同版本，避免组件间 API 不兼容；同时应关注 支持时间表 中的版本支持周期。

总结

kubeadm 将 Kubernetes 集群引导过程中最繁琐、最容易出错的环节（证书、kubeconfig、控制平面自举、引导令牌、CSR 自动审批）全部自动化，同时刻意将网络插件等附加组件的选择权留给用户，保持了最小可行集群的简洁与可组合性。它既适合新用户快速上手，也适合作为 Terraform、Ansible 等更大规模部署体系中的构建块。通过本文的完整实战，读者已经可以独立完成一套包含多节点的 Kubernetes 集群的搭建、网络打通与基础插件扩展。

需要更深入理解集群内部工作原理的读者，可以继续阅读本书的 二进制方式部署 Kubernetes 集群 系列（含 创建 TLS 证书和秘钥、创建 kubeconfig 文件、部署 master 节点 等章节），从手动部署的角度理解 kubeadm 自动化的每一步背后究竟发生了什么。

• 教程
• 云原生
• 容器编排