神秘墓后煮shi者上周有个朋友来问我，说网上搜“k8s在Ubuntu22.04的安装教程”，搜出来的帖子五花八门，有的让装Docker，有的让用Minikube，还有的从源码编译，折腾两天愣是没起来。我听完挺感慨的，这问题我太熟了，Ubuntu 22.04和Kubernetes本身的版本迭代都不慢，很多老教程确实已经过时了。
我自己的环境是几台实体服务器，装的Ubuntu 22.04 LTS，前前后后用kubeadm方式搭过好几遍集群，中间踩过的坑、看过的日志、改过的配置，都还在。这篇就按我实际成功的流程来写，把每一步的“为什么”也讲清楚。适合正在学k8s的运维、想在自己机器上搭一套环境测试的开发，以及准备在Ubuntu 22.04上正式部署集群、但不想被各种老旧教程带偏的人。只要你跟着这份教程走，一台Master加几台Node的集群是可以顺利起来的。
1. 装之前先想清楚：你选的这条路决定了一天能装完还是折腾一周
1.1 机器规划与版本选型
先别急着敲命令，规划阶段省下的时间，比之后排查问题省下的时间多得多。以我这次部署为例，用了三台机器，角色分配如下：
| 节点角色 | 主机名 | IP地址 | 推荐配置 |
|---|---|---|---|
| Master（控制平面） | k8s-master | 10.0.0.10 | 4核8G，磁盘50G以上 |
| Worker（工作节点） | k8s-node1 | 10.0.0.11 | 4核8G，磁盘50G以上 |
| Worker（工作节点） | k8s-node2 | 10.0.0.12 | 4核8G，磁盘50G以上 |
这个配置只是个参考基线。如果你只是学习测试，Master 2核4G也能跑起来，但再低就不建议了，后面我会单独讲内存不足会导致什么结果。磁盘尽量留足，容器镜像和日志增长都很快。
操作系统建议使用Ubuntu 22.04 LTS的Server版，内核版本是5.15，对cgroup v2、iptables这些都有比较好的支持。如果你用的是桌面版，其实也没关系，只是桌面版自带的Netplan配置和防火墙策略会多一些干扰项，Server版更干净。
版本选择上，我这次用的是Kubernetes v1.28.2。为什么不用最新版？因为和Ubuntu 22.04的apt源、systemd版本、内核都有兼容性问题需要时间消化，v1.28是当时足够成熟又不过旧的版本。后续你安装时可以选择更新一些的稳定版，基本原则是三个组件版本要一致：kubeadm、kubelet、kubectl必须同版本，否则会有一堆版本不匹配的报错。
1.2 为什么选kubeadm，而不是Minikube、K3s或二进制安装
很多人一上来会纠结用哪种方式装。我把常见方案整理了一下，各有各的适用场景：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| kubeadm | 官方推荐、生产可用、支持多Master高可用 | 步骤较多，需要理解组件关系 | 学习完整k8s机制、生产环境部署 |
| Minikube | 一条命令起集群 | 只适合单节点，很多功能被简化 | 本地快速体验k8s API |
| K3s | 轻量，资源占用小 | 默认使用traefik和sqlite，与标准k8s有差异 | 边缘计算、资源受限环境 |
| 二进制手动部署 | 完全可控，理解最深 | 需要自行管理证书、组件守护进程 | 进阶学习、特殊定制 |
我的建议很直接：如果你是想正经学k8s、乃至为生产做准备，就选kubeadm。 它通过kubeadm init和kubeadm join把证书生成、组件配置、集群引导这些复杂操作自动化了，但每一步做了什么都可以看见、可以排查，不会像Minikube那样把问题遮住。K3s更像是个玩具，能跑但很多机制不标准，学完再到正式环境还是得重新学。
1.3 kubeadm、kubelet、kubectl三个工具的分工
这三个名字相似的工具，职责完全不同，先理解清楚后面才不会懵：
- kubeadm：负责“搭骨架”。初始化集群、生成证书、配置组件，典型的一次性命令。
- kubelet：每个节点上都要运行的核心agent，负责把Pod跑起来。它以systemd服务的方式常驻后台，工作内容是从API Server接任务。
- kubectl：命令行客户端，让你能查看和控制集群。它本身不常驻，是你和集群交互的“遥控器”。
记住一个比喻：kubeadm是施工队，负责把房子框架搭好；kubelet是管家，长期住在房子里管理日常；kubectl是你手里的遥控器，随时可以指挥房子里的设施。后面排查问题时，要先判断是“施工队没搭好”还是“管家没干活”，方向不一样，排查命令也完全不同。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Ubuntu 22.04系统层面的前置配置：这几步不做，后面kubeadm init必报错
2.1 主机名与hosts映射——不然后面全是玄学报错
集群内的每台机器都需要有唯一的hostname，而且彼此之间要能通过hostname互相访问。很多教程忽略这一步，结果kubelet和API Server之间的通信各种超时，日志刷屏，谁看了都头大。
在Master上执行：
bash复制sudo hostnamectl set-hostname k8s-master
然后在每台节点的/etc/hosts里加上集群所有机器的映射：
bash复制cat <<EOF | sudo tee -a /etc/hosts
10.0.0.10 k8s-master
10.0.0.11 k8s-node1
10.0.0.12 k8s-node2
EOF
这里有个Ubuntu 22.04的特殊点：系统默认用的DNS解析工具是systemd-resolved，/etc/resolv.conf指向127.0.0.53。某些网络环境下这会导致集群内部域名解析出问题。最简单稳妥的做法是修改Netplan配置，把自己的DNS服务器地址加进去，同时保证/etc/hosts完整。另外，Ubuntu 22.04的Cloudinit和NetworkManager可能会覆盖hostname，我有一次就是改完重启又变回去了，最后发现是Netplan里设置了hostname。检查一下/etc/netplan下的yaml文件，如果有hostname字段，直接改掉。
2.2 关闭swap，以及为什么kubelet对swap这么敏感
Kubernetes官方要求安装时必须关闭swap。原因是kubelet的cgroup资源管理模型默认假设节点没有swap，如果开了swap，Pod的内存配额会被打破，节点内存不足时k8s无法通过OOM Kill回收内存，而可能去使用swap，这会导致Pod的实际表现与资源限制严重偏离，调度器也无法准确决策。
在Ubuntu 22.04上，关闭swap分两步：
bash复制# 临时关闭
sudo swapoff -a
# 永久关闭，注释掉或删除swap相关行
sudo sed -i '/ swap / s/^/#/' /etc/fstab
检查swap是否真的关掉了：
bash复制free -h
看到Swap那行的值都是0就对了。我遇到过刚装好的Ubuntu 22.04默认没开swapfile，但有些云厂商的镜像或手动创建的swap分区是存在的，必须确认。
从kubeadm v1.28开始，初始化时如果检测到swap开启，会直接报错。虽然有一个--ignore-preflight-errors=Swap参数可以跳过，但这不是真正的解决办法，只是治标不治本。别看网上有人说开了swap也能跑，生产环境早晚要出事。
2.3 内核模块与网桥参数：overlay和br_netfilter的正确操作
容器运行需要overlayfs支持，而k8s的网络需要br_netfilter模块来处理iptables规则。这两个模块在Ubuntu 22.04默认内核里都有，但不会自动加载，需要手动启用。
bash复制cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
然后是sysctl参数，让iptables规则能作用于桥接流量：
bash复制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
EOF
sudo sysctl --system
这些参数的含义：
net.bridge.bridge-nf-call-iptables：让桥接的IPv4流量经过iptables处理。如果不开，k8s的Service转发规则在网桥场景下不生效，表现为Pod间能通但Service访问不通。net.ipv4.ip_forward：允许IP转发。容器网络默认使用NAT和路由转发，这个不开，Pod出不去外网。
这个位置有个新手很容易忽略的点：执行sysctl --system后，用下面命令验证参数是否真的生效：
bash复制sysctl net.bridge.bridge-nf-call-iptables
如果输出net.bridge.bridge-nf-call-iptables = 1，说明没问题。如果提示文件不存在，说明br_netfilter模块没加载成功，多半是内核版本太老或模块名不对。Ubuntu 22.04默认5.15内核不会遇到，但如果你用了HWE内核或自己编译的内核，就要单独排查。
2.4 时间同步确认
这个点经常被忽略，但k8s的证书机制对时间偏差极其敏感。如果Master和Node之间时间差超过5分钟，kubelet连API Server时证书校验会直接失败，报错信息是x509: certificate has expired or is not yet valid，看着像证书问题，实际上是时间问题。
Ubuntu 22.04默认安装了systemd-timesyncd，只需确认它在运行并正常工作：
bash复制timedatectl status
输出里System clock synchronized: yes和NTP service: active就对了。如果显示未同步，手动开启一下：
bash复制sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd
这里有个替换建议：如果你的集群节点数量比较多、对时间精度要求高，建议全部换成chrony，配置一台作为时间服务器，其他节点指向它。对于学习环境，systemd-timesyncd足够了，没必要额外折腾。
3. 容器运行时：为什么是containerd，以及怎么装
3.1 先说清楚k8s和docker的关系变化
Kubernetes从1.24版本开始正式移除了内置的dockershim组件，这意味着kubelet不再直接管理Docker容器。很多网上的老教程还在让你装Docker作为运行时，这在当前版本下是跑不通的，除非额外安装cri-dockerd这种适配器。
那能不能只装containerd？可以，而且这正是Container Runtime Interface（CRI）设计的本意。kubelet只需要通过CRI协议和容器运行时通信，containerd就是一个很好的CRI运行时，它比Docker更轻量，去掉了Docker CLI、Docker daemon的额外封装。
这里有个常见的误解需要澄清：我不用Docker，不代表我不能构建和使用Docker镜像。 containerd完全支持OCI镜像规范，Docker Hub上所有镜像都能直接拉取运行。日常开发时你想用docker命令构建镜像也完全可以，只要在机器上额外装一个docker-ce但不要让它充当kubelet的运行时就行。换句话说，k8s集群运行时用containerd，和开发机用Docker，两者不冲突。
3.2 containerd安装：推荐二进制方式
containerd的安装可以用apt源，也可以下载官方二进制包。我在Ubuntu 22.04上踩过apt版本过旧的坑，所以更推荐直接下载官方release包。以containerd 1.7.14为例：
bash复制# 下载，这个版本在Ubuntu 22.04上测试很稳定
wget https://github.com/containerd/containerd/releases/download/v1.7.14/containerd-1.7.14-linux-amd64.tar.gz
# 解压到/usr/local
sudo tar Cxzvf /usr/local containerd-1.7.14-linux-amd64.tar.gz
# 安装systemd服务文件
sudo mkdir -p /usr/local/lib/systemd/system
sudo wget -P /usr/local/lib/systemd/system https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
sudo systemctl daemon-reload
sudo systemctl enable --now containerd
注意tar解压命令里的大写C参数，意思是先进入/usr/local目录再解压，这个细节容易漏，漏了文件会散落一地。
3.3 config.toml里必须改的两个地方
containerd默认配置跑不了k8s，需要改/etc/containerd/config.toml。一开始这个文件不存在，先生成默认配置：
bash复制sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
然后修改两个地方：
第一处：SystemdCgroup改为true
toml复制[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
为什么要改这个？Ubuntu 22.04的systemd版本是249，默认使用cgroup v2。containerd如果不把cgroup驱动切换为systemd，而是继续用cgroupfs，那么kubelet（用systemd驱动）和containerd（用cgroupfs）对cgroup的管理会出现冲突。直观表现就是Pod启动不了，kubelet日志报Failed to start container或unable to find cgroup。在Ubuntu 22.04上，这个必须改，没有例外。
第二处：sandbox_image改为国内可拉取的pause镜像
kubelet启动每个Pod前会先启动一个pause容器作为“占位符”，这个镜像默认是registry.k8s.io/pause:3.9，国内网络拉取很慢甚至失败。改成国内镜像仓库：
toml复制[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.9"
改完别忘重启：
bash复制sudo systemctl restart containerd
3.4 验证containerd底层可用
用crictl命令验证containerd是否正常，但crictl需要单独安装或用k8s自带的版本。最简单的方式：
bash复制sudo ctr version
能输出版本信息就说明containerd服务活着。也可以用：
bash复制sudo systemctl status containerd
看看状态是不是active (running)。这一步做好了，你已经迈过整个安装过程中最容易出错的坎。
4. 集群初始化：kubeadm init的完整执行之路
4.1 安装kubeadm、kubelet、kubectl三件套
在Master和所有Node节点上都要安装这三个工具。Ubuntu的官方源和默认apt源里都没有kubenetes组件，需要添加Google的apt源或国内镜像源。这里直接用阿里云镜像。
bash复制# 安装依赖
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
# 下载并添加GPG key
sudo mkdir -p /etc/apt/keyrings
sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg
# 添加软件源
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
# 更新并安装
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
# 锁定版本，防止意外升级
sudo apt-mark hold kubelet kubeadm kubectl
这里有个细节：kubernetes源路径里写的是kubernetes-xenial，这是历史遗留的命名，Ubuntu 22.04依然用这个路径，不要折腾改成jammy，会导致404。
apt-mark hold这一步很重要。系统做apt upgrade时如果没锁定版本，kubelet、kubeadm、kubectl可能会被升级到不兼容的版本，集群就起不来了。所有节点都要执行同样的操作。
安装完成后，kubelet服务会自动注册到systemd，但此时它还没有配置，会在后台反复尝试启动失败重启，这是正常的，等kubeadm init之后它会恢复正常。
4.2 kubeadm init参数选择，以及初始化前的一次演练
在Master节点上执行初始化之前，强烈建议先用dry-run模式跑一遍，检查所有前置条件是否满足，同时把要下载的镜像拉下来：
bash复制sudo kubeadm init \
--apiserver-advertise-address=10.0.0.10 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.28.2 \
--pod-network-cidr=192.168.0.0/16 \
--dry-run
逐个说参数的含义：
--apiserver-advertise-address：API Server对外通告的IP地址，填Master节点的IP。如果节点有多个网卡，必须明确指定，否则kubeadm会随机选一个。--image-repository：镜像仓库地址。默认是registry.k8s.io，国内拉不动，这里用了阿里云的google_containers镜像仓库。--kubernetes-version：明确指定版本，避免默认值和你apt安装的版本对不上。--pod-network-cidr：Pod网段CIDR，这个和后面Calico的配置必须一致。这里用的192.168.0.0/16，也是Calico默认的网段。
dry-run如果成功，会输出类似于真正init结果的信息，但不会实际创建集群。看到[dry-run]字样就说明前置校验基本过了。
4.3 正式初始化：kubeadm init完整过程详解
执行dry-run没问题后，去掉--dry-run参数正式初始化：
bash复制sudo kubeadm init \
--apiserver-advertise-address=10.0.0.10 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.28.2 \
--pod-network-cidr=192.168.0.0/16
整个过程分几个阶段：先检查环境，然后生成证书，写配置文件，启动etcd和control plane组件。每一项都有[etcd]、[control-plane]、[kubelet-finalize]这样的标识。如果卡在某个阶段超过几分钟，多半是镜像拉取卡住，可以用docker images或crictl images检查镜像是否拉全了。
初始化成功后会输出一大段提示信息，最关键的是三块：
- 配置kubectl的指令
- 让Worker节点加入集群的kubeadm join命令，里面包含token和hash
- Pod网络插件的安装提示
记得把第2条保存下来，后面加入节点要用。万一丢了，还可以用到kubeadm token create --print-join-command重新生成，但先保存最省事。
4.4 初始化失败怎么办：kubeadm reset的规范流程
kubeadm init失败大概是新手遇到最多的情况。别慌，记住这个流程，比反复重装系统省无数时间：
bash复制# 回滚已创建的配置
sudo kubeadm reset -f
# 清理网络插件残留
sudo rm -rf /etc/cni/net.d
# 清理kubelet配置
sudo rm -rf /var/lib/kubelet
# 如果之前配置过kubectl，清理
sudo rm -rf ~/.kube
然后根据失败报错修正问题，再重新init。很多论坛里的人遇到问题第一反应是重装系统，其实大部分时候都是配置或网络问题，kubeadm reset是完全可逆的，不需要重来一遍。
5. Calico网络插件：这步做完集群才真正“活”过来
5.1 为什么要网络插件，以及在Flannel、Calico、Cilium之间怎么选
kubeadm init成功后，其实集群还是“瘸腿”的，因为Pod之间的网络还没有打通。没有网络插件，你会发现kubectl get nodes显示Master状态是NotReady，coredns一直处于Pending状态。
网络插件负责实现Pod的网络模型，一般需要满足以下要求：
- 为每个Pod分配独立的IP
- 支持Pod跨节点通信
- 实现Service的转发规则
- 可选的支持NetworkPolicy网络策略
主流的CNI方案我简单对比一下：
| 方案 | 特点 | 适用场景 |
|---|---|---|
| Flannel | 简单、轻量，基于VXLAN/overlay | 对网络性能要求不高，只需要基本连通 |
| Calico | 支持NetworkPolicy，性能好，基于BGP路由 | 生产环境标配，学习k8s网络策略的首选 |
| Cilium | 基于eBPF，性能最强，功能丰富 | 云原生网络进阶，依赖较新的内核特性 |
教程里选Calico是因为它覆盖面广、功能全，学到NetworkPolicy时你会体会到它的价值。Calico在Ubuntu 22.04的5.15内核上跑得很顺利，没有eBPF组件出现的兼容性问题。
5.2 安装Calico的步骤
以Calico v3.27为例：
bash复制curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml
kubectl apply -f calico.yaml
如果你所在的网络环境访问GitHub也慢，可以先下载再传输到master，或者用代理。这里的yaml里声明了大量自定义资源，Calico会自动创建对应的CRD和控制器。
有一条经验：给Calico指定Pod网段时，必须和kubeadm init里设置的--pod-network-cidr一致。 我用的是192.168.0.0/16，正好是calico.yaml的默认值，所以不用改。如果你init时用了别的网段，需要下载yaml后搜索CALICO_IPV4POOL_CIDR，改成你设置的网段。
5.3 等待收敛：多久才算真的成功
可以先用这个命令观察：
bash复制watch kubectl get pods -n kube-system
正常情况下会看到calico-node和calico-kube-controllers的pod启动，最终进入Running状态。这个过程中可能出现短暂的CrashLoopBackOff或Pending，给点耐心等几分钟。
判断网络是否正常的核心指标是：
bash复制kubectl get nodes
只有所有节点状态都变成Ready，然后：
bash复制kubectl get pods -n kube-system
coredns和calico全部Running，才算真正的成功。看到Ready的那一刻，说明网络插件已经正确发了IP。
这里有一个比较隐蔽的坑：Calico默认使用节点的默认网卡IP作为BGP通信地址。如果你的机器有多个网卡，Calico可能选错IP，导致节点间BGP peer无法建立，表现为node状态一直NotReady或Pod无法跨节点通信。解决方法是给Calico的DaemonSet加一个环境变量IP_AUTODETECTION_METHOD=interface=<你的网卡名>，比如interface=eth0，然后重建Calico pod。
6. 工作节点加入与一步步可视化验证
6.1 如果token过期了怎么办
kubeadm init输出的join token默认有效期24小时。如果你过几天才想加节点，或者输出信息丢了，可以在Master上重新生成：
bash复制kubeadm token create --print-join-command
它会直接打印出完整的kubeadm join命令，形如：
bash复制kubeadm join 10.0.0.10:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>
直接把这条命令在Worker节点上执行即可。
6.2 Worker节点join的注意事项
在Worker节点上，需要先把前面第2章和第3章的前置配置都做一遍：hostname、关闭swap、内核模块、containerd安装配置。然后执行join命令：
bash复制sudo kubeadm join 10.0.0.10:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>
如果加入过程中出现如下报错：
bash复制[ERROR FileContent--proc-sys-net-ipv4-ip_forward]: /proc/sys/net/ipv4/ip_forward contents are not set to 1
说明前面第2章的内核参数没配好，回去检查sysctl。如果报证书相关的错，检查时间同步。
执行成功后，回Master上验证：
bash复制kubectl get nodes
应该看到新节点处于NotReady状态，过一两分钟后变成Ready。期间这个节点的calico-node和kube-proxy pod会被自动调度启动。
6.3 全链路验证：部署一个Nginx并开放服务
节点全部Ready后，部署一个简单的应用验证集群工作是否完整：
bash复制kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --type=NodePort --port 80
先看Pod状态：
bash复制kubectl get pods -o wide
等状态变成Running，然后看Service暴露的端口：
bash复制kubectl get svc nginx
输出可能长这样：
code复制NAME TYPE CLUSTER-IP PORT(S) AGE
nginx NodePort 10.103.43.100 80:31654/TCP 20s
用任意节点IP加端口访问：
bash复制curl http://10.0.0.11:31654
如果能返回nginx的欢迎页，恭喜你，这个k8s集群已经真正可以跑了。这个验证流程看起来简单，但能一次性通过，说明你的网络插件、kube-proxy、工作节点调度、容器运行时全都正常工作。
7. 我在Ubuntu 22.04上踩过的坑，按痛苦程度排序
7.1 cgroup驱动不一致：kubelet反复重启的根因
这是我第一次搭建时遇到最“诡异”的问题。kubeadm init都成功了，但kubelet就是起不来，journalctl里刷满了Failed to start ContainerManager之类的错误，后来定位到是cgroup驱动不一致。
具体来说，Ubuntu 22.04使用systemd管理cgroup，kubelet默认驱动是systemd。但containerd如果没改config.toml里的SystemdCgroup，运行时用的是cgroupfs。两者不一致，kubelet一启动就去检测cgroup，发现对不上，直接拒绝工作。
排查命令：
bash复制journalctl -u kubelet -f
看到类似"cgroup driver: cgroupfs" doesn't match with "systemd"，就是这个坑。去把containerd配置改好，重启。这个问题最容易出现在直接照搬网上老教程的人身上，因为老教程都默认用cgroupfs，在Ubuntu 22.04上已经不行了。
7.2 重启后集群卡死：kubelet无法自动拉起Pod
这个问题在云服务器上还好，在实体机上特别常见。节点关机重启后，kubelet虽然自动起来了，但Pod一直不恢复，或者coredns一直Pending。
排查思路：先看节点状态：
bash复制kubectl get nodes
如果节点显示NotReady，到节点上看kubelet：
bash复制systemctl status kubelet
journalctl -u kubelet -f | tail -50
我遇到过一次是因为swap在fstab里没彻底关掉，Ubuntu 22.04重启后swap又挂载回来了，kubelet检测到swap开启就直接罢工。还有一次是containerd服务没启用开机启动，重启后containerd没起来，kubelet自然创建不了容器。
解决： 把containerd设置为开机自启：
bash复制sudo systemctl enable --now containerd
然后彻底关闭swap，步骤在第2章已经写了。这些做完再重启，问题一般就消失了。
7.3 内存不足：kubeadm init直接失败
我第一次是在一台2G内存的机器上尝试，系统直接卡死到完全无响应。kubeadm init对控制平面节点的要求是至少2G可用内存，这还只是最低要求，实际操作中如果你同时跑etcd和API Server，2G非常勉强。
如果你只有2G内存，分配时注意轻量运行，关掉不必要的图形界面服务，或者临时加swap过渡（但kubelet又要求swap关闭，这是个死循环）。建议直接升级到4G以上，反正现在云主机和二手服务器都便宜，不值得为这里折腾。
如果初始化时真的因为内存卡住，现象是init命令在[wait-control-plane]阶段一直转圈。查看kubelet日志会看到etcd内存不足导致的OOM相关记录。所以规划阶段就把内存配到位，比啥都强。
7.4 containerd配置改完忘了重启：看起来一切正常但Pod起不来
这个坑特别阴险。我改完config.toml，继续执行kubeadm init，所有控制平面组件都起来了，但后续调度Pod时一直卡在ContainerCreating。排查日志发现是containerd还在用旧的cgroup fs配置和旧的sandbox_image。
教训： 每次修改/etc/containerd/config.toml，都必须执行sudo systemctl restart containerd，没有例外。你可以用下面命令确认当前生效的sandbox_image是不是自己改的那个：
bash复制crictl config --list | grep sandbox_image
不过实际crictl配置不完全等价于containerd配置，最稳妥的还是restart后看containerd日志确认配置加载成功。
7.5 Calico镜像拉取超时：Pod进入ImagePullBackOff
Calico的镜像包括calico-node、calico-kube-controllers，有些镜像默认是从quay.io拉取的。quay.io在国内访问速度不稳定，经常出现ImagePullBackOff。
解决方式是提前手动把镜像拉下来并打上对应的tag。以上面的calico.yaml为例，你可以这样处理：
bash复制# 先看calico.yaml里用到的镜像
grep image: calico.yaml
# 手动拉取，比如
ctr -n k8s.io images pull docker.io/calico/node:v3.27.0
然后按calico.yaml里的名字和tag手动打标签。不过更省心的做法是给containerd配置registry mirror，把quay.io的拉取代理到国内镜像站。在config.toml的registry.mirrors节点下添加quay.io的mirror地址即可。这一条建议大家提前配置好，否则装Calico时基本必踩。
8. 集群装完后的一个小建议
装完集群只是开始，我的体验是，第一周你一定会遇到各种奇怪现象，不要急着拔电源或重装系统。多看kubectl describe pod、journalctl -u kubelet、journalctl -u containerd这三个来源的日志，大部分问题都能找到明确线索。
最后分享一个我实际操作中很受益的小习惯：我会把搭建过程中的关键命令、输出、坑记录成一个Shell脚本和一个Markdown笔记，之后再搭新环境时直接复用，避坑效率高很多。你在自己的Ubuntu 22.04上第一次搭建时也可以这样做，折腾一次以后就再也不慌了。