按说，使用kubeadm搭建k8s集群最权威的方法、步骤，应该是直接参考kubeadm官网，里边描述了从OS基础配置到containerd，再到kubeadm安装、init&join的全过程。

只是，kubernetes的官网对整个过程的描述并不是一种step by step的方式，而是把相关的步骤分散于各个富含上下文知识的页面中，它在描述操作方法的同时，讲了很多原理、注意事项及异常处理之类的内容。

如果我们想弄清楚整个过程的操作步骤，需要不断地在各个网页中穿梭，浏览遍历。我们在顺利完成环境搭建的的同时，也知道了它的许多运维技巧和运行原理。

对学习来说，这可能是正统的方式，因为这样可以让我们深谙操作步骤的原理，具备基本异常排错的能力。
而本文描述的过程可能更符合我们日常工作中那种快餐式的方式：“别扯太多，别扯周边，直接告诉我一步一步的命令。”，这样导致的问题就是，一、步骤不一定通用，二、出了问题容易让自己抓瞎。

本文也算是记录了自己一次kubeadm搭建k8s集群的过程，有些坎坷，所以也才有点收获。

总体步骤可以概括为以下几个阶段。

1. 准备机器
   1. 配置操作系统
   2. 安装基础依赖
   3. 安装containerd & cni
   4. 内核模块设置
2. 搭建k8s
   1. 安装kubeadm及其他组件
   2. 执行kubeadm init
   3. 运行kubeadm join
   4. 其他相关命令
   5. 关键配置文件

注意：

• 所有操作都在ubuntu22.04下用root完成。
• 下文涉及到的版本均经过验证，且针对k8s v1.27.2。
• 下文仅涉及操作步骤，至于概念和原理不过多涉及。
• 鉴于国内网络情况（github、k8s.io），可以提前一并下载好（通过代理的方式，maybe），再做剩余操作。

1. 准备机器

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目录下都有什么版本，替换成如下的方式：

# 原来的 focal 换成了bionic-updates
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

a. 下载containerd

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

b. 配置containerd 服务

wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service -O /lib/systemd/system/containerd.service
systemctl daemon-reload
systemctl enable --now containerd

c. 安装runc

wget https://github.com/opencontainers/runc/releases/download/v1.1.7/runc.amd64 
install -m 755 runc.amd64 /usr/local/sbin/runc

d. 安装cni

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

e. 启动containerd

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

# sysctl params required by setup, params persist across reboots
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

# Apply sysctl params without reboot
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

2. 搭建k8s

1) 安装kubeadm及其他组件

a. 国外可达的情况下

mkdir -p /etc/apt/keyrings # for 比较新的ubuntu版本
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

b. 国外不可达的情况下：

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

a. 可以连接registry.k8s.io的情况

kubeadm init --kubernetes-version 1.27.2

超级简单，暂时也没碰到什么问题。

b. 国内网络部署k8s环境

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 的方式修改:

containerd config default > config.toml   # 生成默认的containerd完整配置
sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.9"   # 找到sandbox_image 配置项，将其修改为想要的image
systemctl restart containerd  # 重启containerd，生效配置，注意：重启后相关的image会重新被下载。

那为什么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) 必要调试工具

这部分大家不一定碰到，有需要的时候可以从这里检索。

# 查阅containerd中的所有container运行时。
crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a

# 上文中已经提及，以此方法可以查询containerd的相关配置。
crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock \
	--debug=true info -o go-template --template '{{.config.sandboxImage}}'

注意circtl还有很多参数，我们可以用它查询或者操作容器运行时，在必要的时候。

# 查看containerd中各种images
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命令了，具体这里就不说了，它属于k8s使用日常的事宜。
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