按说，使用kubeadm搭建k8s集群最权威的方法、步骤，应该是直接参考kubeadm官网，里边描述了从OS基础配置到containerd，再到kubeadm安装、init&join的全过程。
只是，kubernetes的官网对整个过程的描述并不是一种step by step的方式，而是把相关的步骤分散于各个富含上下文知识的页面中，它在描述操作方法的同时，讲了很多原理、注意事项及异常处理之类的内容。
如果我们想弄清楚整个过程的操作步骤，需要不断地在各个网页中穿梭，浏览遍历。我们在顺利完成环境搭建的的同时，也知道了它的许多运维技巧和运行原理。
对学习来说，这可能是正统的方式，因为这样可以让我们深谙操作步骤的原理，具备基本异常排错的能力。
而本文描述的过程可能更符合我们日常工作中那种快餐式的方式：“别扯太多，别扯周边，直接告诉我一步一步的命令。”，这样导致的问题就是，一、步骤不一定通用，二、出了问题容易让自己抓瞎。
本文也算是记录了自己一次kubeadm搭建k8s集群的过程，有些坎坷，所以也才有点收获。
总体步骤可以概括为以下几个阶段。
注意：
- 所有操作都在ubuntu22.04下用root完成。
- 下文涉及到的版本均经过验证，且针对k8s v1.27.2。
- 下文仅涉及操作步骤，至于概念和原理不过多涉及。
- 鉴于国内网络情况（github、k8s.io），可以提前一并下载好（通过代理的方式，maybe），再做剩余操作。
1) 配置操作系统
首先，我们需要确保ubuntu 22.04上配置的/etc/apt/sources.list是否可用。执行 apt update 时没有报错即可。
如果报错
E: The repository 'http://nova.clouds.archive.ubuntu.com/ubuntu focal Release' does not have a Release file 则，我们需要调整下/etc/apt/sources.list中的源。
其实，sources.list文件中列的http://nova.clouds.archive.ubuntu.com/ubuntu都是可以访问的，如果不能访问，说明国内访问这些源不可达，直接换源：
deb http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse 如果能访问，则说明源是正常的，但是没有这个ubuntu版本的distribution 目录。更改一下sources.list中的ubuntu版本，比如这里报错“focal Release’ does not have a Release file”，意思是说，没有ubuntu focal版本，则，我们可以打开http://nova.clouds.archive.ubuntu.com/ubuntu 看看 dists目录下都有什么版本，替换成如下的方式：
deb http://nova.clouds.archive.ubuntu.com/ubuntu bionic-updates main restricted universe multiverse sed -i 's/hirsute/kinetic/g' /etc/apt/sources.list 这种方式不是很安全，最简单的方式还是直接换源。这里推荐大家去看下
- ubuntu的版本系列
- sources.list 文件格式
- gpg pgp加密的基础概念
2) 安装基础依赖
apt-get update apt-get install -y apt-transport-https ca-certificates curl 3) 安装containerd & cni
wget https://github.com/containerd/containerd/releases/download/v1.7.2/containerd-1.7.2-linux-amd64.tar.gz tar Cxzvf /usr/local containerd-1.7.2-linux-amd64.tar.gz wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service -O /lib/systemd/system/containerd.service systemctl daemon-reload systemctl enable --now containerd wget https://github.com/opencontainers/runc/releases/download/v1.1.7/runc.amd64 install -m 755 runc.amd64 /usr/local/sbin/runc wget https://github.com/containernetworking/plugins/releases/download/v1.3.0/cni-plugins-linux-amd64-v1.3.0.tgz mkdir -p /opt/cni/bin tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-v1.3.0.tgz rm -rf /etc/containerd/config.toml systemctl restart containerd 4) 配置内核模块
cat <<EOF | tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF modprobe overlay modprobe br_netfilter cat <<EOF | 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 EOF sysctl --system lsmod | grep br_netfilter lsmod | grep overlay sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward 1) 安装kubeadm及其他组件
mkdir -p /etc/apt/keyrings curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | \ gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | \ tee /etc/apt/sources.list.d/kubernetes.list apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl echo deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main > /etc/apt/sources.list.d/kubernetes.list curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | \ apt-key add - apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl 2) 运行kubeadm init
kubeadm init --kubernetes-version 1.27.2 超级简单，暂时也没碰到什么问题。
kubeadm init \ --image-repository registry.aliyuncs.com/google_containers \ --kubernetes-version 1.27.2 k8s版本更新很快，正当各种调试折腾v1.27.2的搭建时，kubeadm init 提示新的部署版本是v1.27.3，所以我们需要在init时加上参数 –kubernetes-version 1.27.2，否则kubadm会开始下载新版本的相关image。
–image-repository 修改默认image的下载地址：registry.k8s.io。原因显而易见。
需要注意的是，我们仍然需要下载 registry.k8s.io/pause:3.8，因为在containerd 这个版本（1.7.2）的默认配置中，他还是默认采用pause:3.8, 这是containerd的缺省行为，编译入containerd可执行文件中了。
所以我们会看到kubeadm总是在输出"sandboxImage":“registry.k8s.io/pause:3.8”。
究其原因，这个默认行为来自于containerd代码，默认配置：
pkg/cri/config/config_unix.go#L88
// DefaultConfig returns default configurations of cri plugin. func DefaultConfig() PluginConfig { ... return PluginConfig{ ... SandboxImage: "registry.k8s.io/pause:3.8", ... 这个值可以通过 /etc/containerd/config.toml 的方式修改:
那为什么crictl会从containerd返回registry.k8s.io/pause:3.8呢，查看kubeadm的代码cmd/kubeadm/app/util/runtime/runtime.go可以知道：
// SandboxImage returns the sandbox image used by the container runtime func (runtime *CRIRuntime) SandboxImage() (string, error) { args := []string{"-D=false", "info", "-o", "go-template", "--template", "{{.config.sandboxImage}}"} out, err := runtime.crictl(args...).CombinedOutput() if err != nil { return "", errors.Wrapf(err, "output: %s, error", string(out)) } sandboxImage := strings.TrimSpace(string(out)) if len(sandboxImage) > 0 { return sandboxImage, nil } return "", errors.Errorf("the detected sandbox image is empty") } 它相当于执行了如下命令：
crictl是我们预先安装的crictl管理客户端。在本文后边的调试工具部分也会提及它。
crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock \ --debug=true info -o go-template --template '{{.config.sandboxImage}}' kubeadm init 执行结束后，会有类似这样的输出：
mkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config ... kubeadm join 10.250.16.103:6443 --token 724zwh.95geawagieraqscz --discovery-token-ca-cert-hash sha256:2627b4645fb280cd077396171881b92bcff31c6ca0be13487af9d981d6cfc200 我们接下来就可以使用以上给出的kubeadm join命令添加worker node了。
3) 运行kubeadm join
kubeadm join 10.250.16.103:6443 --token 724zwh.95geawagieraqscz \ --discovery-token-ca-cert-hash sha256:2627b4645fb280cd077396171881b92bcff31c6ca0be13487af9d981d6cfc200 注意这里的token可以通过kubeadm token list获取，也可以通过kubeadm token create创建。
--discovery-token-ca-cert-hash的参数注意有“sha256:”前缀。
参数--discovery-token-ca-cert-hash sha256:2627b4645fb280cd077396171881b92bcff31c6ca0be13487af9d981d6cfc200数值部分可以通过以下命令获取：
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | \ openssl rsa -pubin -outform der 2>/dev/null | \ openssl dgst -sha256 -hex | sed 's/^.* //' 输出为 2627b4645fb280cd077396171881b92bcff31c6ca0be13487af9d981d6cfc200
如果不想加这个sha256，可以用以下命令避免校验。
kubeadm join 10.250.16.103:6443 \ --token 724zwh.95geawagieraqscz \ --discovery-token-unsafe-skip-ca-verification 4) 必要调试工具
这部分大家不一定碰到，有需要的时候可以从这里检索。
crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock \ --debug=true info -o go-template --template '{{.config.sandboxImage}}' 注意circtl还有很多参数，我们可以用它查询或者操作容器运行时，在必要的时候。
ctr -n k8s.io images list 注意 使用ctr时候加上 -n k8s.io ，否则看不到已经下载的image，也就是说它是有命名空间的。
ctr和crictl的区别是ctr是containerd的操作客户端;
而crictl是所有容器虚拟技术的客户端，通过--runtime-endpoint unix:///var/run/containerd/containerd.sock的方式和具体的容器实现（比如containerd docker-shim）交互.
kubectl get all -A 5) 关键配置文件
k8s部署完成后 kubelet以systemd 服务的形式存在，可以通过systemctl status kubelet 查看服务状态。
kubelet配置文件：/var/lib/kubelet/config.yaml
进程：
/usr/bin/kubelet \ --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf \ --kubeconfig=/etc/kubernetes/kubelet.conf \ --config=/var/lib/kubelet/config.yaml \ --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \ --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.9 基础服务配置目录：
/etc/kubernetes/manifests
- etcd.yaml
- kube-apiserver.yaml
- kube-controller-manager.yaml
- kube-scheduler.yaml
具体做什么的就不必说了。需要注意的是，修改这些文件可以实现调整k8s集群的作用，修改保存后，相应的服务会自动重启，不需要执行kubectl apply -f xxxx.yaml。
比如修改 kube-controller-manager.yaml：
spec: containers: - command: - kube-controller-manager - --allocate-node-cidrs - --cluster-cidr=10.0.0.0/16 那么配置的node就会添加podCIDR字段，即ipam.mode == kubernetes
spec: podCIDR: 10.0.2.0/24 podCIDRs: - 10.0.2.0/24 原文链接：https://blog.csdn.net/zongzw/article/details/131237062
