🧯 K8S 使用问题总汇 安装失败 / 磁盘 / 挂载 / 权限 / 拉不下镜像 / 线上数据库磁盘 —— 现象 → 原因 → 解决方案,按报错关键词对号入座

01集群安装失败 —— kubeadm 高频报错

90% 的安装失败都卡在 kubeadm init 的预检(preflight)阶段,报错会直接告诉你原因,逐条修复即可:

标准修复流程(命令可直接复制)

# 1. 关闭 swap(新手第一大坑,处理完重启也不会复活)
swapoff -a
sed -ri 's@^(/.*\sswap\s.*)@#\1@' /etc/fstab
free -h                        # Swap 一行必须全是 0

# 2. 容器运行时自检
systemctl enable --now containerd
crictl ps                      # 能正常执行(哪怕空列表)说明 runtime OK

# 3. 上次失败后的"彻底重来"(试错阶段最常用)
kubeadm reset -f
rm -rf /var/lib/etcd/* /etc/cni/net.d/* $HOME/.kube/config
iptables -F && ipvsadm -C 2>/dev/null

# 4. 重新 init(image-repository 建议直接给国内源,避免第 05 节的坑)
kubeadm init \
  --image-repository=registry.aliyuncs.com/google_containers \
  --pod-network-cidr=10.244.0.0/16 \
  --service-cidr=10.96.0.0/12

# 5. init 成功后按提示三连(否则 kubectl 连不上)
mkdir -p $HOME/.kube && cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
kubectl get nodes              # 能打印节点表即成功

02磁盘问题 —— 磁盘满 / DiskPressure 驱逐

节点磁盘可用率低于阈值(默认 nodefs.available<10%、imagefs.available<15%)时,kubelet 会把节点标记为 DiskPressure 并驱逐 Pod。

典型现象

# 节点被打了磁盘压力标签
kubectl describe node qingfeng | grep -A2 DiskPressure
  DiskPressure   True   KubeletHasDiskPressure   kubelet has disk pressure

# 大批 Pod 被驱逐(Evicted)
kubectl get pods -A | grep -i evicted
harbor   harbor-core-5d7c9f8b-x2k9p   Evicted   0   23h

# 应用写文件直接报错(数据库最常见,见第 06 节)
IOError: [Errno 28] No space left on device

排查:先找到磁盘被谁吃掉

# 1. 总览:运行时与 kubelet 所在分区
df -h /var/lib/containerd /var/lib/kubelet

# 2. 三大户逐一定位(镜像层 / 容器日志 / journald)
du -h --max-depth=1 /var/lib/containerd | sort -rh | head
du -h --max-depth=1 /var/log/pods     | sort -rh | head   # 容器 stdout 日志
journalctl --disk-usage

清理(按安全顺序执行)

# 1. 删"没有任何 Pod 在用"的镜像(最安全、见效最快)
crictl rmi --prune

# 2. 收缩 journald 系统日志,只保留 3 天
journalctl --vacuum-time=3d

# 3. 清理已被驱逐/失败的 Pod 残留
kubectl delete pods -A --field-selector=status.phase=Failed

# 4. 长效:限制单容器日志体积(/var/lib/kubelet/config.yaml)
containerLogMaxSize: 50Mi
containerLogMaxFiles: 3
# 改完 systemctl restart kubelet

兜底:临时下调驱逐阈值(只救急,清完就改回)

# /var/lib/kubelet/config.yaml
evictionHard:
  nodefs.available: "5%"
  imagefs.available: "5%"
# systemctl restart kubelet 后 DiskPressure 会自动恢复为 False

03挂载问题 —— Volume / PVC 挂载失败

Pod 卡在 ContainerCreating 十有八九是挂载问题,Events 里必有答案:

第一步:看 Events 定位

kubectl describe pod mysql-0 | sed -n '/Events:/,$p'
kubectl get events -A --sort-by=.lastTimestamp | grep -iE 'volume|mount|attach'

# PVC 是否 Bound?Pending 多半是 PV/StorageClass 没配好
kubectl get pvc -A

高频报错对照表

# NFS 服务端标准配置(/etc/exports)示例
/data/nfs/mysql  *(rw,sync,no_subtree_check,no_root_squash)

# 服务端生效 + 客户端验证(节点上先手工 mount 一次,能通 K8S 里才能通)
exportfs -rv
mount -t nfs 192.168.10.10:/data/nfs/mysql /mnt && ls /mnt && umount /mnt

04权限问题 —— Permission denied / RBAC

① 挂载目录没写权限(数据库类应用第一名坑)

# 现象:Pod 反复 CrashLoopBackOff,logs 里是经典的 permission denied
kubectl logs mysql-0 -n prod
mkdir: cannot create directory '/var/lib/mysql': Permission denied

# 解决:Pod securityContext 加 fsGroup(让 kubelet 把卷 chown 给该组)
#      fsGroup 的值 = 镜像内运行业务的系统用户组 id(mysql 官方镜像为 999)
spec:
  securityContext:
    fsGroup: 999
    runAsUser: 999
    runAsGroup: 999

② SELinux 拦截(CentOS / RHEL 常见)

# 快速判断:临时关闭后能写了,就是 SELinux 的锅
setenforce 0          # 临时 Permissive(重启失效)

# 正确做法(别长期关闭):给目录打容器标签
chcon -Rt svirt_sandbox_file_t /data/nfs/mysql
# 永久生效用 semanage fcontext -a -t svirt_sandbox_file_t "/data/nfs/mysql(/.*)?" && restorecon -Rv /data/nfs/mysql

③ RBAC / 认证类报错

# 权限自检两连:我是谁 / 我能不能
kubectl config current-context
kubectl auth can-i get pods -n prod          # 回答 yes/no,一目了然
kubectl auth can-i '*' '*' --as=system:serviceaccount:prod:deploy-sa

# 看证书还剩多久
kubeadm certs check-expiration

05拉不下镜像 —— ImagePullBackOff

典型现象与四类根因

kubectl get pods -n web
nginx-6b7f5d8c-x9k2p   0/1   ImagePullBackOff   0   3m

kubectl describe pod nginx-6b7f5d8c-x9k2p -n web | grep -A3 "Failed to pull"
  Failed to pull image "nginx:1.27": failed to pull and unpack ... i/o timeout

方案 A:先确认镜像真的存在

# 在任意节点上手工拉一次,报 not found 就是名字/Tag 写错
crictl pull nginx:1.27

方案 B:containerd 配置国内加速(一劳永逸)

# 1. /etc/containerd/config.toml 启用 certs.d 目录(v2 推荐方式)
[plugins."io.containerd.grpc.v1.cri".registry]
  config_path = "/etc/containerd/certs.d"

# 2. 给 docker.io 配加速源:/etc/containerd/certs.d/docker.io/hosts.toml
server = "https://docker.io"
[host."https://docker.m.daocloud.io"]
  capabilities = ["pull", "resolve"]
#   ★ 加速器对某些仓库(如 bitnamilegacy)可能挂起/不回源 → pull 卡住不动:
#     先 rm hosts.toml 恢复直连(机器 curl 通 docker.io 就直连可拉);
#     直连也不行再换源:docker.1ms.run / dockerproxy.net 等,改 [host."..."] 后重启 containerd

# 3. 重启生效(改了配置不重启 = 白改)
systemctl restart containerd
crictl pull nginx:1.27        # 现在应该秒拉

# 4. sandbox/pause 镜像也超时的话,init 第一步就卡死 —— 顺手改同文件里
#    sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.10"

方案 C:离线导入(内网/保密环境终极方案)

# 有网机器上导出,拷进内网节点导入(注意必须是 k8s.io 命名空间)
ctr -n k8s.io images import nginx-1.27.tar
crictl images | grep nginx   # 能看到即成功,Pod 会自动重试拉起

方案 D:私有仓库认证(Harbor 等)

# 1. 建拉取凭证(用户名里 $ 记得转义,Robot 账号常见)
kubectl create secret docker-registry regcred -n web \
  --docker-server=harbor.qingfeng.local \
  --docker-username='robot$ci' \
  --docker-password='Harbor12345'

# 2. Pod/Deployment spec 里引用
spec:
  imagePullSecrets:
  - name: regcred

06线上数据库磁盘满 —— 止血 → 扩容 → 防复发

数据库是最怕磁盘满的工作负载:一旦写不进 binlog/数据文件,MySQL 会把自己挂起来,业务直接中断。处理顺序永远是先止血保服务,再扩容,最后防复发。

现象确认(告警 90%+ 或已写入失败)

# 1. PVC 使用率告警
kubectl get pvc data-mysql -n prod
NAME        STATUS   VOLUME     CAPACITY   ...
data-mysql  Bound    pvc-8f3..  20Gi

# 2. 进容器看实际占用(看挂载点,不是根分区)
kubectl exec -it mysql-0 -n prod -- df -h /var/lib/mysql
/dev/sdb   20G   18.5G   1.5G  93% /var/lib/mysql

# 3. 是数据涨了还是日志涨了?
kubectl exec -it mysql-0 -n prod -- sh -c 'du -sh /var/lib/mysql/* | sort -rh | head'
# binlog.0000xx  动辄几十 G —— 最常见的元凶
# ibdata1 / ib_logfile0 —— 真实数据/redo,不能删

第一步:止血(只清日志,绝不动数据文件)

# 1. binlog 立刻瘦身:只保留最近 2 天
kubectl exec -it mysql-0 -n prod -- \
  mysql -uroot -p"$PW" -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 2 DAY;"

# 2. 慢日志/错误日志轮转(>> 清空不换句柄,不断连接)
kubectl exec -it mysql-0 -n prod -- sh -c '> /var/log/mysql/slow.log'

# 3. 临时表/备份残留确认后再删(先看时间戳,别一把梭)

第二步:PVC 在线扩容(业务不中断)

# 前提 1:StorageClass 必须允许扩容
kubectl get sc
NAME       PROVISIONER      ALLOWVOLUMEEXPANSION
nfs-sc     nfs-provisioner  true        ← 允许,继续
local-sc   kubernetes.io/no-provisioner  false   ← 本地盘不支持在线扩,只能迁移

# 直接 patch 目标容量(只能扩大,永远不能缩小!)
kubectl patch pvc data-mysql -n prod \
  -p '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'

# 盯进度:先等 controller 扩 PV,再等文件系统在线 expand(xfs/ext4 均支持)
kubectl get pvc data-mysql -n prod -w

# 容器内验证(无需重启 Pod)
kubectl exec -it mysql-0 -n prod -- df -h /var/lib/mysql
/dev/sdb   50G   18.5G   32G  37% /var/lib/mysql

第三步:防复发

# 1. binlog 自动过期(my.cnf [mysqld],3 天)
binlog_expire_logs_seconds = 259200
max_binlog_size            = 512M

# 2. 容器日志限制(见第 02 节 containerLogMaxSize)
# 3. 监控告警阈值提前到 75%,别等 90% 才动手

07通用排障三板斧 + 状态速查表

不管什么问题,先跑这三条,80% 的答案就在输出里:

kubectl describe pod <pod> -n <ns>                    # Events 区 = 病历本
kubectl logs <pod> -n <ns> --tail=100 --previous   # 应用自己的报错(--previous 看上一次崩溃)
kubectl get events -A --sort-by=.lastTimestamp | tail -20   # 全集群最近发生了什么

08节点能跑多少 Pod —— maxPods 查询与调整

查询命令(两条就够)

# 1. 最多能跑几个:读节点 status.allocatable.pods(kubelet 上报的可分配上限)
kubectl get node qingfeng -o jsonpath='{.status.allocatable.pods}'; echo
110

# 2. 已经用了多少:describe 的 Allocated resources 段,盯 pods 那一行
kubectl describe node qingfeng | grep -A8 'Allocated resources'
  Resource           Requests      Limits
  cpu                850m (21%)    300m (7%)
  memory             690Mi (9%)    512Mi (7%)
  ephemeral-storage  0 (0%)        0 (0%)
  pods               7 (6%)        0 (0%)      ← 已分配 7 个 / 上限 110

# 附加:所有节点容量一览表
kubectl get nodes -o custom-columns='NODE:.metadata.name,MAX-PODS:.status.allocatable.pods'
NODE       MAX-PODS
qingfeng   110

# 多节点集群:全部节点的 Pod 容量"总和"(jsonpath 逐行取出再 awk 累加)
kubectl get nodes -o jsonpath='{range .items[*]}{.status.allocatable.pods}{"\n"}{end}' \
  | awk '{s+=$1} END{print "集群 Pod 总容量:", s}'

# 明细 + 合计一起看(表格末尾追加 TOTAL 行)
kubectl get nodes -o custom-columns='NODE:.metadata.name,MAX-PODS:.status.allocatable.pods' \
  | awk 'NR>1{print; s+=$2} END{print "--------"; printf "TOTAL\t%d\n", s}'

# 对比"已经用了多少":集群当前 Pod 总数 / 只数 Running
kubectl get pods -A --no-headers | wc -l
kubectl get pods -A --field-selector=status.phase=Running --no-headers | wc -l

110 是怎么评估出来的?

• 不是算出来的,是默认值:110 来自 kubelet 参数 --max-pods(即 KubeletConfiguration 的 maxPods: 110),kubelet 启动时把它写进 status.capacity.pods 并上报 apiserver —— 这是社区经验值,兼顾每个 Pod 的进程/内存开销。
• 默认值不一定真是 110:发行版/云厂商常会定制(实测 FKE 集群节点为 100) —— 所以别硬编码 110,以 allocatable.pods 查询结果为准;"集群总容量" = 各节点 allocatable.pods 逐个相加(见上方 jsonpath+awk 命令)。
• 真正还能不能调度,是调度器综合判断:min(maxPods, 剩余 CPU requests, 剩余内存 requests, CNI 剩余 IP)。所以即便 pods 显示 (6%) 很空闲,CPU 100% 照样 Pending(见第 07 节状态表)。
• 隐性上限还有三个:CNI 每节点 Pod CIDR(Flannel 默认 /24 = 254 个 IP)、节点级 PID 上限(每 Pod 至少 1 个容器进程)、云厂商 CNI(如阿里云 Terway / AWS VPC CNI 按 ENI×辅助 IP 数限制,此时 maxPods 由厂商参数决定)。

后期可以修改吗 —— 可以,只改 kubelet,不用动集群

# 1. 先确认当前生效值(节点上的 kubelet 配置)
grep maxPods /var/lib/kubelet/config.yaml
maxPods: 110

# 2. 改成目标值(如 200)
sed -i 's/^maxPods:.*/maxPods: 200/' /var/lib/kubelet/config.yaml

# 3. 重启 kubelet 生效(节点上执行,秒级,不影响已运行 Pod)
systemctl restart kubelet

# 4. 验证:上报的 allocatable.pods 已变成新值
kubectl get node qingfeng -o jsonpath='{.status.allocatable.pods}'; echo
200

易混点:node 和 namespace 是两种东西,别搞混

kubectl get node qingfeng 查的是节点(一台真实的机器,本集群单节点就叫 qingfeng) —— maxPods 是节点属性,所以要 get node;而 namespace 是集群里的逻辑分区(default / kube-system / harbor ...),只负责把资源分组隔离,和节点没有包含关系。

# 查看某个命名空间
kubectl get ns                       # 列出全部命名空间
kubectl get ns harbor -o wide        # 看某个 ns 的状态
kubectl describe ns harbor           # 详情:标签、资源配额(Quota)、状态

# "看一个 ns 里的东西"(最常见诉求,用 -n 指定)
kubectl get pods -n harbor           # 该 ns 的 Pod
kubectl get all -n harbor            # Pod/Svc/Deploy 一次全看
kubectl get pods -A                  # 想全看就去掉 -n 加 -A

# ns 级别的 Pod 数上限 = ResourceQuota(不建就没有限制)
kubectl get resourcequota -n harbor
# 给 harbor ns 限制最多 50 个 Pod:
kubectl create quota pod-limit -n harbor --hard=pods=50