Docker Desktop自带Kubernetes是本地开发最省事、兼容性最好、调试效率最高的方案，因其共享宿主机containerd运行时，镜像构建后可直接被K8s拉取，无需额外加载或推送，避免Minikube常见的ImagePullBackOff等问题。
直接用 Docker Desktop 自带的 Kubernetes 功能，是本地开发最省事、兼容性最好、调试效率最高的方案。其他方式（如 Minikube、k3s、kubeadm 单节点）要么多一层虚拟化开销，要么网络/镜像复用不透明，容易卡在 ImagePullBackOff 或 Failed to pull image 上。
为什么 Docker Desktop 的 K8s 比 Minikube 更适合日常开发
Minikube 启动的是独立 Linux VM，它和宿主机的 Docker 守护进程完全隔离。你用 docker build 打的镜像，默认不会出现在 Minikube 的节点里，必须手动 minikube image load 或推到本地 registry；而 Docker Desktop 的 K8s 节点就运行在同一个容器运行时（containerd）上，构建完就能直接 kubectl apply，零同步成本。
常见错误现象：
-
ErrImagePull或ImagePullBackOff—— Minikube 场景下高频报错，本质是镜像没加载进去 -
Unable to connect to the server: EOF—— Docker Desktop 的 K8s 服务被意外关闭（比如切换了 Kubernetes 版本或重装了 Desktop） - Ingress 不生效 —— Minikube 需额外
minikube addons enable ingress，Docker Desktop 默认已启用且监听localhost
实操建议：
- 确保 Docker Desktop 设置中启用了 Kubernetes：
Settings → Kubernetes → Enable Kubernetes - 不要勾选
Deploy Docker Stacks to Kubernetes by default（容易干扰本地 compose 流程） - 验证是否就绪：
kubectl get nodes -o wide应返回一个docker-desktop节点，状态为Ready - 默认命名空间是
default，但所有系统组件（如 CoreDNS、metrics-server）都在kube-system，别误删
如何让本地镜像免 push 直接被 K8s 使用
Docker Desktop 的 K8s 共享宿主机的 containerd 命名空间，所以只要镜像存在于 docker images 列表里，K8s 就能拉取。但要注意两个关键点：
- Pod 的
imagePullPolicy必须设为IfNotPresent或Never；设成Always会强制走远程拉取，必然失败 - 镜像 tag 不能是
latest（尤其当本地有同名但不同内容的镜像时），推荐用具体 commit hash 或语义化版本，比如myapp:v1.2.0 - 如果用 Helm，记得在
values.yaml中显式覆盖image.pullPolicy: IfNotPresent
示例 Pod YAML 片段：
apiVersion: v1
kind: Pod
metadata:
name: my-dev-app
spec:
containers:
- name: app
image: myapp:dev-20260904
imagePullPolicy: IfNotPresentkubeadm init 单节点部署在本地电脑上为什么不推荐
在 macOS 或 Windows 上直接跑 kubeadm init 几乎不可行：它要求 Linux 内核、cgroups v1/v2 支持、iptables/nftables 规则管理能力，而宿主机不具备这些条件。即使你在 WSL2 或虚拟机里装，也会立刻撞上三个硬伤：
- 网络不可达：WSL2 的 IP 是动态的，
--apiserver-advertise-address很难稳定配置，kubectl连不上 - 存储路径混乱：
/var/lib/kubelet映射到 Windows NTFS 或 macOS APFS，权限和 inotify 行为异常，导致 volume mount 失败 - 资源争抢严重：kubeadm 启动的 etcd + apiserver + controller-manager 全挤在一个节点上，没有资源限制，容易吃光内存触发 OOM killer
如果你真需要 kubeadm 体验（比如备考 CKA），请用轻量级 Linux VM（如 Multipass + Ubuntu），而不是在宿主机上硬刚。
遇到 Connection refused 或 context deadline exceeded 怎么快速恢复
这是 Docker Desktop 的 K8s 服务崩溃或未启动的典型表现，不是集群配置问题。别急着重装或改配置，先做这三件事：
- 重启 Docker Desktop：菜单栏图标右键 →
Restart（比 kill 进程更可靠） - 检查后台进程：
ps aux | grep kube应能看到kube-apiserver、kube-controller-manager等进程；没有说明服务根本没起来 - 清空旧上下文：
kubectl config delete-context docker-desktop，再重启 Desktop，它会自动重建上下文 - 如果仍不行，临时禁用 Hyper-V / WSL2（Windows）或 Rosetta（macOS M 系列芯片）相关兼容选项，再试一次
真正麻烦的从来不是“怎么部署”，而是“怎么让本地镜像、Ingress、StorageClass 三者行为一致”。Docker Desktop 方案把这三件事的耦合度压到了最低——这也是它至今仍是开发者首选的原因。
