记录一次 Kubernetes Pod启动异常处理 - 运维

中午午饭期间，手动通过 helm upgrade 升级公司内部k3s集群一个核心应用的image tag，发现 Pod 一直处于 ContainerCreating 状态，通过 kubectl describe pod 查看Pod event 发现以下报错：

Warning  FailedCreatePodSandBox  4m18s (x47 over 14m)  kubelet                  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to get sandbox image "hub.example.net/hub.example.com/library/rancher/mirrored-pause:3.6": failed to pull image "hub.example.net/hub.example.com/library/rancher/mirrored-pause:3.6": failed to pull and unpack image "hub.example.net/hub.example.com/library/rancher/mirrored-pause:3.6": failed to resolve reference "hub.example.net/hub.example.com/library/rancher/mirrored-pause:3.6": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

发现pause镜像地址不对，本想通过 helm回滚应用，但想到这是 pause 容器拉取问题，问题可能不在应用或者Helm Chart，而是在于集群，于时询问另一个负责集群维护的同事，同事说是k3s服务参数设置错误了。

这个k3s集群有8个节点，其中4个节点是master，其中两个节点的 k3s.service 文件不正确，比其他节点的 service 文件多了一条--system-default-registry 参数。

# cat /etc/systemd/system/k3s.service
[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target
After=network-online.target
[Install]
WantedBy=multi-user.target
[Service]
Type=notify
EnvironmentFile=-/etc/default/%N
EnvironmentFile=-/etc/sysconfig/%N
EnvironmentFile=-/etc/systemd/system/k3s.service.env
KillMode=process
Delegate=yes
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
TimeoutStartSec=0
Restart=always
RestartSec=5s
ExecStartPre=/bin/sh -xc '! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service'
ExecStartPre=-/sbin/modprobe br_netfilter
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/k3s \
  server \
    --tls-san kubeapi.haogs.cn \
    --tls-san apiserver.cluster.local \
    --tls-san kubeapi.oop.cc \
    --cluster-cidr 10.42.0.0/16 \
    --token K1070e07b3adb57eb487d36715363de876b30934c342ce32e3ec2a3fd47fade16e9::server:ca62b715778ae018093eddbdac313cd1 \
    --service-cidr 10.43.0.0/16 \
    --datastore-endpoint mysql://kubeadmin:Oog3gequi9eePie6Nahw2aih8Iefei2i@tcp(k3smysql.example.cc:3306)/k3s \
    --disable servicelb,traefik,local-storage \
    --disable-cloud-controller \
    --disable-network-policy \
    --disable-helm-controller \
    --data-dir /opt/quickon/platform \
    --system-default-registry hub.example.net \
    --pause-image hub.example.com/library/rancher/mirrored-pause:3.6 \
    --kube-proxy-arg "proxy-mode=ipvs" \
    --kube-proxy-arg "masquerade-all=true" \
    --kube-proxy-arg "ipvs-strict-arp=true" \
    --kube-proxy-arg "metrics-bind-address=0.0.0.0"

可见 --system-default-registry hub.example.net 和 --pause-image hub.example.com/library/rancher/mirrored-pause:3.6 参数冲突了。移除 --system-default-registry hub.example.net 或者改成 --pause-image hub.example.net/rancher/mirrored-pause:3.6 即可解决。

修改k3s systemd service文件，重启k3s。

vim /etc/systemd/system/k3s.service
systemctl daemon-reload
systemctl restart k3s

复盘：

大概有以下问题：

四个master节点，修改了2个，节点之间服务启动参数有差异；
修改后未能验证修改的结果是否有效，或者验证不完整，如果只有一个master节点或许能发现问题；
hub.example.net 和 hub.example.com 两个镜像服务没有统一成一个，如果只有一个镜像服务也许就没问题了，不过这可能是历史原因；

可能的后续改进：

尽可能消除配置差异；
测试环境验证修改没问题后发到生产环境，修改参数必须充分验证；
使用版本控制记录修改，有发布或变更记录；
减少不必要的镜像服务，避免同时使用不同的镜像服务域名；