K8s学习笔记：踩坑记录与知识扩展

对应章节：第一章 环境搭建与Pod入门 / 1.1 Kind集群搭建 + 1.2 第一个Pod

---

坑 1：镜像名拼写 → ImagePullBackOff

你写的	应该是	现象
nginx:aplane	nginx:alpine	Pod 状态 ImagePullBackOff

原因：aplane 这个 tag 在 Docker Hub 上不存在，kubelet 尝试拉取失败后进入退避重试状态。

学到的：

• ImagePullBackOff 是 Pod 状态机里的”镜像拉不下来”状态
• 看 kubectl describe pod 的 Events 部分立刻能定位：

  Failed to pull image "nginx:aplane": ... not found
  Error: ErrImagePull
  Back-off pulling image "nginx:aplane"
  Error: ImagePullBackOff

---

坑 2：宿主机有镜像 ≠ Kind 里的 Pod 能用

操作	结果
宿主机 docker images	nginx:alpine 存在
宿主机 docker pull nginx:alpine	成功
Pod 状态	ErrImagePull

原因：Kind 集群跑在 Docker 容器里，每个”节点”是一个 Docker 容器，内部用的是 containerd 而非 Docker daemon。宿主机 Docker 的镜像仓库和 Kind 内部的 containerd 镜像是两个完全独立的仓库，互不相通。

┌─ 宿主机 ──────────────────────────┐
│  Docker daemon                     │
│  ├─ nginx:alpine  ← 宿主机镜像     │
│  └─ kindest/node 容器              │
│       └─ containerd                │
│            └─ (空的，没有 nginx)   │  ← Pod 只能从这里拉
└────────────────────────────────────┘

正常解法：kind load docker-image 可以把宿主机镜像灌进 Kind 节点（但部分镜像版本不兼容）。

---

坑 3：宿主机 Docker 加速 ≠ Kind 能用

宿主机 /etc/docker/daemon.json 配了镜像加速 docker.1ms.run，docker pull 很快，但 Pod 的 Pulling 阶段仍然报 connection refused（连 registry-1.docker.io 被墙）。

原因：Kind 内部的 containerd 不继承宿主机的 Docker 配置。它默认直连 registry-1.docker.io，在国内会因为网络问题拉不到镜像。

解决方案：创建 Kind 集群时通过 containerdConfigPatches 给 Kind 内部的 containerd 单独配置镜像加速：

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |-
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
    endpoint = ["https://docker.1ms.run"]

kind create cluster --name k8s-lab --config kind-config.yaml

本质：两个容器运行时（宿主机 Docker、Kind containerd）各自管各自的配置。这个问题在后续用 kubeadm 搭真实集群时还会再遇到——同样需要手动配 containerd 的镜像加速。

---

坑 4：port-forward 只绑定 127.0.0.1

命令	绑定地址	外部能否访问
kubectl port-forward pod/my-nginx 8080:80	127.0.0.1:8080	✗
kubectl port-forward --address 0.0.0.0 pod/my-nginx 8080:80	0.0.0.0:8080	✓

原因：kubectl port-forward 默认只监听 localhost，虚拟机外部的物理机浏览器无法连接。

注意：第三章学到 Service 之后，会有更正式的暴露服务方式（NodePort、LoadBalancer），port-forward 仅适合调试。

---

坑 5：port-forward 不是”卡住”

终端执行 kubectl port-forward 后停顿不动，看上去像卡死了。

真相：port-forward 是一个前台持续运行的进程，它在等待并转发流量。任何转发过来的 HTTP 请求都会实时显示在终端上。测试完后 Ctrl+C 即可停止。

---

扩展知识：Pod 事件链路

正常链路（你见到了）

Scheduled → Pulling(38s) → Pulled → Created → Started → Running

异常链路（你也见到了）

Scheduled → Failed(ErrImagePull) → BackOff → ImagePullBackOff

以后再遇到 Pod 起不来，直接看 Events 就知道卡在哪一步：

卡在	含义	排查方向
Pulling 超时	拉不到镜像	检查镜像名、网络、镜像加速
ImagePullBackOff	多次拉取失败已退避	镜像名错误或网络不通
CrashLoopBackOff	容器启动后崩溃	kubectl logs 看报错
Pending	调度失败	资源不足或节点不可用

---

架构认知：Kind 的运行模型

物理机/VM
├── Docker daemon
│   ├── kindest/node 容器 (control-plane)
│   │   ├── containerd        ← Pod 镜像从这里拉
│   │   ├── kubelet           ← 管理 Pod 生命周期
│   │   ├── kube-apiserver    ← kubectl 对话的入口
│   │   └── CNI (kindnet)     ← Pod 网络
│   └── 用户镜像 (nginx:alpine 等)
└── kubectl → 通过 kubeconfig 连接 apiserver

Kind 把一个完整的 K8s 控制平面塞进了一个 Docker 容器里，对学习来说足够用，但镜像管理和网络模型和真实集群有差异。