教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载Kubernetes 集群的搭建一直是初学者和运维人员面前的第一道坎证书签发、各组件启动顺序、网络插件选择任何一步出错都可能导致集群无法工作。kubeadm正是为解决这一问题而生的集群引导工具它在 Kubernetes 1.13 中正式 GAGeneral 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 Lifecyclekubeadm 所属的 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 前各子功能的成熟度分级帮助读者理解哪些能力是稳定可用的、哪些仍在演进中分类成熟度 LevelCommand line UXbetaImplementationbetaConfig file APIalphaSelf-hostingalphakubeadm alpha subcommandsalphaCoreDNSalphaDynamicKubeletConfigalpha从表中可以看到命令行体验Command line UX与核心实现Implementation最先成熟而配置文件 APIConfig file API、自托管Self-hosting、kubeadm alpha 子命令、CoreDNS 集成以及 DynamicKubeletConfig 等子功能在早期仍处于 alpha 级别处于积极开发中。随着工具的发展创建集群的实现细节可能会稍有调整但总体实现已经相当稳定。需要说明的是按照 kubeadm 的定义任何kubeadm alpha子命令都在 alpha 级别上受支持生产环境中应谨慎使用。支持时间表Kubernetes 版本通常支持九个月在此期间如果发现严重的错误或安全问题官方可能会从发布分支发布补丁程序版本。这一支持周期同样适用于 kubeadm。下表是早期 Kubernetes 版本的发布与停止支持时间表Kubernetes versionRelease monthEnd-of-life-monthv1.6.xMarch 2017December 2017v1.7.xJune 2017March 2018v1.8.xSeptember 2017June 2018v1.9.xDecember 2017September 2018v1.10.xMarch 2018December 2018v1.11.xJune 2018March 2019v1.12.xSeptember 2018June 2019v1.13.xDecember 2018September 2019读者在实际使用中应始终选择当前仍在支持窗口内的版本并及时关注发布分支的补丁更新生产环境还需要参考官方最新的支持周期表。实战用 kubeadm 搭建 Kubernetes 测试集群下面以仓库中 Ubuntu 上 kubeadm 实战安装文档 为例完整演示从零开始搭建一套包含 1 个 master 与 3 个 node 的 Kubernetes 测试集群。该方案适用于学习和测试用途生产用途的环境需要考虑各个组件的高可用建议参考 Kubernetes 官方相关安装文档。节点规划与系统准备本次安装建议至少 4 台服务器或虚拟机每台服务器 4G 内存、2 个 CPU 核心以上基本架构为 1 台 master 节点、3 台 slave 节点。节点信息如下角色主机名IP 地址MasterUbuntu-master192.168.5.200Slaveubuntu-1192.168.5.201Slaveubuntu-2192.168.5.202Slaveubuntu-3192.168.5.203准备工作包括默认方式安装 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如果连接 gcrGoogle Container Registry网站不方便、无法下载镜像安装过程会卡在拉取镜像阶段。此时可以预先准备离线镜像包解压后得到多个 tar 包使用docker load xxxx.tar逐个导入即可。在所有节点上安装 kubeadmkubeadm、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 couldnt 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 cant 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-cidr10.244.0.0/16 --apiserver-advertise-address192.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 的工作流程理解它在后台替我们做了什么Preflight 检查检查系统环境端口、内核参数、crictl 是否存在等并启动 kubelet 服务证书生成在/etc/kubernetes/pki下生成 ca、apiserver、etcd、front-proxy、sa 等全套证书与密钥——这正是二进制部署中最繁琐的环节可对照 创建 TLS 证书和秘钥 一文kubeconfig 写入为 admin、kubelet、controller-manager、scheduler 分别生成 kubeconfig 文件控制平面部署将 kube-apiserver、kube-controller-manager、kube-scheduler、etcd 以Static Pod 清单的形式写入/etc/kubernetes/manifests由 kubelet 负责拉起——这就是 kubeadm 实现控制平面自举的核心机制标记 master给 master 节点打上node-role.kubernetes.io/master标签与污点taint默认阻止业务 Pod 调度到 master 上引导令牌生成 bootstrap token并配置好 RBAC 规则使节点可以通过 Bootstrap Token 提交 CSR 获取长期证书、自动审批 CSR、并支持节点客户端证书轮换基础插件应用 kube-dnskube-system 命名空间与 kube-proxy 两个必要插件。配置 kubectl 访问集群按初始化输出末尾的提示在 master 节点执行如下命令配置 kubectlmkdir -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 命名空间中的系统组件 PodrootUbuntu-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 网络插件。本例选用canalCalico 与 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 基础插件之后可以按需扩展。这里列出几个与仓库配套的常用扩展方向集群 DNSCoreDNS/kube-dnskubeadm 在早期版本默认部署 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/HPAIngress 控制器可参考 Traefik Ingress 安装仓库中的 traefik.yaml 以 DaemonSet 加hostNetwork: true方式部署 Traefik 并监听 80 端口ingress-rbac.yaml 为 ingress ServiceAccount 绑定 cluster-admin 角色以读取 Ingress 规则存储与中间件后台存储可参考本书最佳实践中的 存储管理 相关内容如 NFS、Ceph、OpenEBS 等方案。常见问题与注意事项结合 Ubuntu 上 kubeadm 实战安装文档 中的实操经验总结以下常见问题镜像拉取卡住kubeadm init需要从 gcr 拉取控制平面镜像网络受限时安装会卡在[init] Waiting for the kubelet to boot up the control plane as Static Pods。解决方案是提前docker load导入离线镜像包或使用可访问的镜像仓库节点一直 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.200apt 源 GPG 报错未签名源导致的NO_PUBKEY报错可以忽略安装时使用--allow-unauthenticated参数即可生产环境建议正确导入官方 GPG 公钥kube-dns 处于 Pending这是网络插件尚未就绪的正常表现网络插件安装完成后会自动变为 Running加入集群的 token 过期kubeadm init输出的 token 默认有效期 24 小时过期后可在 master 上执行kubeadm token create --print-join-command重新生成版本一致性kubelet、kubeadm、kubectl 应尽量保持相同版本避免组件间 API 不兼容同时应关注 支持时间表 中的版本支持周期。总结kubeadm 将 Kubernetes 集群引导过程中最繁琐、最容易出错的环节证书、kubeconfig、控制平面自举、引导令牌、CSR 自动审批全部自动化同时刻意将网络插件等附加组件的选择权留给用户保持了最小可行集群的简洁与可组合性。它既适合新用户快速上手也适合作为 Terraform、Ansible 等更大规模部署体系中的构建块。通过本文的完整实战读者已经可以独立完成一套包含多节点的 Kubernetes 集群的搭建、网络打通与基础插件扩展。需要更深入理解集群内部工作原理的读者可以继续阅读本书的 二进制方式部署 Kubernetes 集群 系列含 创建 TLS 证书和秘钥、创建 kubeconfig 文件、部署 master 节点 等章节从手动部署的角度理解 kubeadm 自动化的每一步背后究竟发生了什么。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Kubernetes集群引导神器kubeadm快速创建生产级K8s集群的完整指南Kubernetes集群引导神器kubeadm快速创建生产级K8s集群的完整指南 kubeadm是Kubernetes官方提供的集群引导工具能够帮助用户快速robosuite渲染系统深度解析从基础渲染到照片级真实感的完整实现robosuite渲染系统深度解析从基础渲染到照片级真实感的完整实现 robosuite是一个模块化的机器人学习仿真框架和基准测试平台其强大的渲染系统支持从强化学习物理引擎终极指南使用CRI-O和kubeadm快速部署生产级Kubernetes集群终极指南使用CRI O和kubeadm快速部署生产级Kubernetes集群 想要快速搭建稳定可靠的Kubernetes生产环境CRI O作为专为Kuber云原生容器运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/23 16:40:36 · 阅读 1.2k 使用 kubeadm 快速搭建生产级 Kubernetes 集群：从工具介绍到完整实战
教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载Kubernetes 集群的搭建一直是初学者和运维人员面前的第一道坎证书签发、各组件启动顺序、网络插件选择任何一步出错都可能导致集群无法工作。kubeadm正是为解决这一问题而生的集群引导工具它在 Kubernetes 1.13 中正式 GAGeneral 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 Lifecyclekubeadm 所属的 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 前各子功能的成熟度分级帮助读者理解哪些能力是稳定可用的、哪些仍在演进中分类成熟度 LevelCommand line UXbetaImplementationbetaConfig file APIalphaSelf-hostingalphakubeadm alpha subcommandsalphaCoreDNSalphaDynamicKubeletConfigalpha从表中可以看到命令行体验Command line UX与核心实现Implementation最先成熟而配置文件 APIConfig file API、自托管Self-hosting、kubeadm alpha 子命令、CoreDNS 集成以及 DynamicKubeletConfig 等子功能在早期仍处于 alpha 级别处于积极开发中。随着工具的发展创建集群的实现细节可能会稍有调整但总体实现已经相当稳定。需要说明的是按照 kubeadm 的定义任何kubeadm alpha子命令都在 alpha 级别上受支持生产环境中应谨慎使用。支持时间表Kubernetes 版本通常支持九个月在此期间如果发现严重的错误或安全问题官方可能会从发布分支发布补丁程序版本。这一支持周期同样适用于 kubeadm。下表是早期 Kubernetes 版本的发布与停止支持时间表Kubernetes versionRelease monthEnd-of-life-monthv1.6.xMarch 2017December 2017v1.7.xJune 2017March 2018v1.8.xSeptember 2017June 2018v1.9.xDecember 2017September 2018v1.10.xMarch 2018December 2018v1.11.xJune 2018March 2019v1.12.xSeptember 2018June 2019v1.13.xDecember 2018September 2019读者在实际使用中应始终选择当前仍在支持窗口内的版本并及时关注发布分支的补丁更新生产环境还需要参考官方最新的支持周期表。实战用 kubeadm 搭建 Kubernetes 测试集群下面以仓库中 Ubuntu 上 kubeadm 实战安装文档 为例完整演示从零开始搭建一套包含 1 个 master 与 3 个 node 的 Kubernetes 测试集群。该方案适用于学习和测试用途生产用途的环境需要考虑各个组件的高可用建议参考 Kubernetes 官方相关安装文档。节点规划与系统准备本次安装建议至少 4 台服务器或虚拟机每台服务器 4G 内存、2 个 CPU 核心以上基本架构为 1 台 master 节点、3 台 slave 节点。节点信息如下角色主机名IP 地址MasterUbuntu-master192.168.5.200Slaveubuntu-1192.168.5.201Slaveubuntu-2192.168.5.202Slaveubuntu-3192.168.5.203准备工作包括默认方式安装 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如果连接 gcrGoogle Container Registry网站不方便、无法下载镜像安装过程会卡在拉取镜像阶段。此时可以预先准备离线镜像包解压后得到多个 tar 包使用docker load xxxx.tar逐个导入即可。在所有节点上安装 kubeadmkubeadm、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 couldnt 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 cant 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-cidr10.244.0.0/16 --apiserver-advertise-address192.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 的工作流程理解它在后台替我们做了什么Preflight 检查检查系统环境端口、内核参数、crictl 是否存在等并启动 kubelet 服务证书生成在/etc/kubernetes/pki下生成 ca、apiserver、etcd、front-proxy、sa 等全套证书与密钥——这正是二进制部署中最繁琐的环节可对照 创建 TLS 证书和秘钥 一文kubeconfig 写入为 admin、kubelet、controller-manager、scheduler 分别生成 kubeconfig 文件控制平面部署将 kube-apiserver、kube-controller-manager、kube-scheduler、etcd 以Static Pod 清单的形式写入/etc/kubernetes/manifests由 kubelet 负责拉起——这就是 kubeadm 实现控制平面自举的核心机制标记 master给 master 节点打上node-role.kubernetes.io/master标签与污点taint默认阻止业务 Pod 调度到 master 上引导令牌生成 bootstrap token并配置好 RBAC 规则使节点可以通过 Bootstrap Token 提交 CSR 获取长期证书、自动审批 CSR、并支持节点客户端证书轮换基础插件应用 kube-dnskube-system 命名空间与 kube-proxy 两个必要插件。配置 kubectl 访问集群按初始化输出末尾的提示在 master 节点执行如下命令配置 kubectlmkdir -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 命名空间中的系统组件 PodrootUbuntu-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 网络插件。本例选用canalCalico 与 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 基础插件之后可以按需扩展。这里列出几个与仓库配套的常用扩展方向集群 DNSCoreDNS/kube-dnskubeadm 在早期版本默认部署 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/HPAIngress 控制器可参考 Traefik Ingress 安装仓库中的 traefik.yaml 以 DaemonSet 加hostNetwork: true方式部署 Traefik 并监听 80 端口ingress-rbac.yaml 为 ingress ServiceAccount 绑定 cluster-admin 角色以读取 Ingress 规则存储与中间件后台存储可参考本书最佳实践中的 存储管理 相关内容如 NFS、Ceph、OpenEBS 等方案。常见问题与注意事项结合 Ubuntu 上 kubeadm 实战安装文档 中的实操经验总结以下常见问题镜像拉取卡住kubeadm init需要从 gcr 拉取控制平面镜像网络受限时安装会卡在[init] Waiting for the kubelet to boot up the control plane as Static Pods。解决方案是提前docker load导入离线镜像包或使用可访问的镜像仓库节点一直 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.200apt 源 GPG 报错未签名源导致的NO_PUBKEY报错可以忽略安装时使用--allow-unauthenticated参数即可生产环境建议正确导入官方 GPG 公钥kube-dns 处于 Pending这是网络插件尚未就绪的正常表现网络插件安装完成后会自动变为 Running加入集群的 token 过期kubeadm init输出的 token 默认有效期 24 小时过期后可在 master 上执行kubeadm token create --print-join-command重新生成版本一致性kubelet、kubeadm、kubectl 应尽量保持相同版本避免组件间 API 不兼容同时应关注 支持时间表 中的版本支持周期。总结kubeadm 将 Kubernetes 集群引导过程中最繁琐、最容易出错的环节证书、kubeconfig、控制平面自举、引导令牌、CSR 自动审批全部自动化同时刻意将网络插件等附加组件的选择权留给用户保持了最小可行集群的简洁与可组合性。它既适合新用户快速上手也适合作为 Terraform、Ansible 等更大规模部署体系中的构建块。通过本文的完整实战读者已经可以独立完成一套包含多节点的 Kubernetes 集群的搭建、网络打通与基础插件扩展。需要更深入理解集群内部工作原理的读者可以继续阅读本书的 二进制方式部署 Kubernetes 集群 系列含 创建 TLS 证书和秘钥、创建 kubeconfig 文件、部署 master 节点 等章节从手动部署的角度理解 kubeadm 自动化的每一步背后究竟发生了什么。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Kubernetes集群引导神器kubeadm快速创建生产级K8s集群的完整指南Kubernetes集群引导神器kubeadm快速创建生产级K8s集群的完整指南 kubeadm是Kubernetes官方提供的集群引导工具能够帮助用户快速robosuite渲染系统深度解析从基础渲染到照片级真实感的完整实现robosuite渲染系统深度解析从基础渲染到照片级真实感的完整实现 robosuite是一个模块化的机器人学习仿真框架和基准测试平台其强大的渲染系统支持从强化学习物理引擎终极指南使用CRI-O和kubeadm快速部署生产级Kubernetes集群终极指南使用CRI O和kubeadm快速部署生产级Kubernetes集群 想要快速搭建稳定可靠的Kubernetes生产环境CRI O作为专为Kuber云原生容器运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考