企业官网建设流程全解析

k3d这个工具圈子里其实不算新了，但每次跟人聊到本地跑K8s，总还有人一脸懵地问"k3d和k3s到底啥关系""为啥不直接用Docker Desktop自带的K8s"。这问题我在各种场合被问过不下几十次。今天打算用一篇完整的入门指南，把k3d怎么在Docker里跑K3s这事彻底讲明白，从原理到实操，再到我踩过的一些坑，一次性说清楚。

我最初接触k3d，是因为某次需要在本地快速复现一个客户端连不上集群的问题。当时嫌minikube太重，kind又觉得节点启动得太慢，折腾了一圈之后发现k3d恰好卡在一个非常舒服的位置：轻量、快、配置灵活。如果你也跟我一样，需要在本地或者CI环境里频繁创建和销毁K8s集群，那这篇指南应该能帮你省下不少时间。

1. 内容整体设计与思路拆解

1.1 K3s和k3d到底是什么关系

先把概念理清楚。K3s是一个轻量级Kubernetes发行版，官方给它的定位是面向边缘计算和资源受限场景。它把K8s控制平面组件压缩进单个二进制，默认使用SQLite替代etcd作为存储，去掉了很多云服务商相关的控制器，整体内存占用可以压到几百兆。k3d做的事情更简单粗暴：它把K3s直接装进Docker容器里跑，这个容器既是控制平面节点，也可以作为工作节点，多个容器组合在一起就构成一个完整的K8s集群。

打个比方，K3s好比一个精简版的操作系统镜像，k3d则是帮你把这个镜像跑在一台虚拟机里。Docker容器就是那台虚拟机，只不过它比传统虚拟机轻得多，启动一个K3s节点通常只需要十几秒到三十秒。k3d通过Docker网络让各个节点容器互联互通，再通过Server负载均衡器把集群的API Server和Service端口暴露给宿主机。

1.2 为什么选择k3d而不是minikube或者kind

选型这事没有绝对的对错，关键看使用场景。我把k3d和几个常见的本地K8s方案放在一起对比过：

kind是使用Kubernetes官方组件在容器里搭建完整节点，所以它与真实集群的一致性很高，适合做需要复现线上环境的测试。但这也意味着它启动慢、占资源。k3d基于K3s，K3s本身对K8s做了大量裁减和优化，所以启动速度和内存占用都有明显优势。

我个人的经验是，如果只是在本地跑个Demo、验证一下Helm Chart、或者需要快速测试多集群交互，k3d是首选。如果是做非常贴近生产的集成测试，尤其是要验证etcd、kube-proxy这些底层组件的行为，用kind更合适。两者不冲突，像我平时就同时装了k3d和kind，按需使用。

1.3 k3d在本地开发工作流中的定位

把k3d放在一个更大的开发流程里看，它的优势会更明显。本地开发时，你通常会经历这几个阶段：编写代码、构建镜像、部署到K8s、观察日志、调试。如果你用的是云上的开发集群，每次构建镜像都要push到远程仓库，然后拉取，整个循环可能要好几分钟。用k3d，你可以把集群直接跑在本地，镜像构建完直接导入集群里，整个迭代循环压缩到几十秒。

更关键的是，k3d支持创建多集群。比如我在做某些微服务联调时，会同时起两个集群，一个模拟生产环境版本，一个跑最新的开发分支，通过端口映射让它们互访。这在minikube上是很难做到的，但k3d只需两条命令就能搞定。后面我会详细讲这个操作。

2. 核心原理与配置解析

2.1 k3d的工作原理与架构细节

k3d的核心机制就是利用Docker容器来模拟K8s节点。一个k3d集群通常由三类容器组成：

Server节点容器：承载K3s server进程，也就是K8s控制平面。默认情况下，这个容器还会运行一个名为traefik的Ingress Controller，用来处理集群内的七层负载均衡。在单Server模式下，工作负载也会调度到这个节点上。

Agent节点容器：相当于K8s的工作节点，只运行kubelet和容器运行时，接收来自控制平面的调度。可创建多个Agent容器来扩展集群容量。

Loadbalancer容器：这不是K3s自己的一部分，而是k3d额外创建的。它运行着一个轻量级的负载均衡器（基于HAProxy），作用是把宿主机上的端口流量转发到集群内对应的Service端口上。你通过-p "8080:80@loadbalancer"这样的参数宿主机端口映射到集群时，实际就是经过这个容器完成的。

这些容器之间通过一个预先创建的Docker网络互联。k3d的镜像里预置了K3s二进制以及对应的启动脚本，容器启动时执行这些脚本，初始化节点并注册到集群中。

值得留意的是，k3d并不是完全环境无关的。它依赖Docker的网络和存储能力，所以你不能在一台没有Docker的机器上用k3d。同时，k3d中的K3s版本是由k3d镜像版本决定的，默认使用的镜像标签是rancher/k3s:latest，但你也可以用--image myregistry/k3s:custom指定任意包含K3s的镜像。

2.2 集群创建时的关键配置参数

k3d的配置方式很灵活，既可以写命令行参数，也可以用YAML配置文件。这里梳理几个日常使用频率最高的参数，我会把每个参数的用途和应用场景都展开说明。

控制平面与工作节点数量

创建集群时最基础的两个参数是--servers和--agents，它们决定了控制平面节点和工作节点的数量。

k3d cluster create mycluster --servers 1 --agents 2

单Server模式下，K3s默认使用SQLite存储状态，适合开发测试。如果你需要高可用控制平面，可以指定--servers 3，此时K3s会用内置的etcd模式运行，三个Server节点之间自动形成共识。不过要注意，etcd模式对磁盘I/O和内存的要求更高，资源紧张的机器可能会有点吃力。

以我自己的笔记本为例，16GB内存的机器上，一个Server节点加两个Agent节点，每个节点的内存限制在1GB以内，整个集群加起来大概占用2.5GB到3GB的内存，这个开销对本地开发来说完全可接受。

端口映射语法详解

k3d端口映射的语法看起来有点别扭，但拆开看其实不难：

k3d cluster create mycluster -p "8080:80@loadbalancer"

冒号前面的8080是宿主机端口，冒号后面的80是集群内的端口，@loadbalancer表示这个映射挂到负载均衡器上。你访问宿主机localhost:8080时，流量会经过Loadbalancer容器，再转发到集群内Service暴露的80端口。

这里有一个点很容易搞混：80并不是指某个Pod的端口，而是指集群内Service的端口。也就是说，你创建的Service类型如果是ClusterIP，端口为80，那通过-p "8080:80@loadbalancer"就能直接访问到它。如果Service端口是30080，那就得写成-p "8080:30080@loadbalancer"。

如果不想用Loadbalancer，也可以把端口映射挂到具体的Server或Agent节点上，比如-p "8080:30080@server:0"，这样流量会直接进到第一个Server节点的对应端口。这种做法偶尔会用到，比如调试Ingress或者NodePort类型的Service时。

存储卷挂载与镜像导入

本地开发经常需要把代码目录挂载进集群，让Pod直接读最新代码，避免每次改动都重新构建镜像。k3d通过--volume参数支持这个能力：

k3d cluster create dev-cluster --volume /Users/me/code:/code@all

@all表示挂载到所有节点。对于依赖本地文件做热加载的开发场景，这一步非常关键。不过要注意，K8s本质上是分布式系统，Pod可能被调度到任意节点，所以这种方法更适合单节点的开发环境。多节点环境下，还是应该用镜像或ConfigMap来管理代码和数据。

另外，k3d提供了k3d image import命令，可以把本地构建好的镜像直接导入集群：

k3d image import myimage:latest -c dev-cluster

这条命令会把镜像推送到集群内的所有节点上，省去了push到远程仓库再pull下来的环节，本地开发效率提升非常明显。

私有镜像仓库

k3d还支持直接创建一个内置的私有镜像仓库，免去你先跑一个registry容器再配置的麻烦：

k3d registry create myregistry --port 5000 k3d cluster create dev-cluster --registry-use myregistry:5000

创建完集群后，你就可以直接往localhost:5000推送镜像，然后在这些镜像上部署应用。这个功能在做微服务联调时很实用，多个人共享一套仓库和集群，互相之间不用再拷贝镜像文件。

2.3 配置解析表格速查

为了方便查阅，我整理了一张参数速查表，覆盖平时最常用的k3d配置：

3. 实操过程与核心环节实现

3.1 环境准备与安装步骤

在开始之前，先确认你的机器满足两个硬性条件：Docker可以正常运行，且版本不能太老。k3d依赖Docker API的大部分现代特性，建议Docker版本在20.10以上。检查Docker是否正常：

docker version --format '{{.Server.Version}}'

能正常输出版本号就说明Docker可用。接下来安装k3d。我用的方式是通过官方安装脚本：

curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash

如果你用的是macOS，也可以直接用Homebrew：

brew install k3d

Linux用户还可以用包管理器安装，Debian或Ubuntu用户可以使用apt源。安装完成后验证一下：

k3d version

能正常输出版本信息就说明安装成功。k3d CLI会与K3s镜像解耦，所以即使k3d本身版本较新，你依然可以在创建集群时指定使用旧版K3s镜像，这个灵活性在实际项目里真的救过我一次。

提示：安装完k3d之后，别忘了确认kubectl也可以使用。k3d本身不依赖kubectl，但集群创建后你需要它来管理资源。

3.2 创建集群的完整演示范例

创建一个最基础的集群，一行命令搞定：

k3d cluster create demo

这个命令会创建一个名为demo的集群，默认包含一个Server节点。执行过程中k3d会拉取K3s镜像，创建Docker网络，启动容器，整个流程通常在几十秒内完成。看到输出中出现Cluster 'demo' created successfully就说明成功了。

查看当前所有集群：

k3d cluster list

你会看到类似这样的输出，能直观看到集群的状态信息：

NAME SERVERS AGENTS LOADBALANCER demo 1/1 0/0 true

接着把Kubeconfig合并到本地默认配置，让kubectl能直接连上这个集群：

k3d kubeconfig merge demo --kubeconfig-merge-default

然后验证连通性：

kubectl cluster-info

如果一切正常，会输出集群的API Server地址和CoreDNS信息。到这里，一个K3s集群已经在Docker里跑起来了。

创建带有Agent节点的集群也很简单：

k3d cluster create demo \ --servers 1 \ --agents 2 \ -p "8080:80@loadbalancer" \ --volume /tmp/k3d-demo:/data@all

这条命令创建的集群有两个工作节点，把宿主机8080端口映射到集群的80端口，并且把/tmp/k3d-demo目录挂载到所有节点。在这个集群里，你可以体验多节点调度、跨节点通信这些更接近生产的特性。

3.3 部署一个真实应用走通全流程

集群跑起来之后，光看状态没意思，得实际部署点东西才有感觉。我先用一个最简单的Nginx来演示端口映射和Ingress的工作方式。

先创建一个Nginx Deployment：

kubectl create deployment nginx --image=nginx:alpine kubectl scale deployment nginx --replicas=2

创建一个Service暴露端口：

kubectl expose deployment nginx --port=80 --target-port=80

再创建一个Ingress，让访问nginx.localhost时能进到Nginx：

cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx spec: rules: - host: nginx.localhost http: paths: - path: / pathType: Prefix backend: service: name: nginx port: number: 80 EOF

等一下Ingress Controller生效，然后访问测试：

curl -v http://nginx.localhost

如果返回了Nginx的默认页面，说明整条链路已经通了。你看到K8s自带的Traefik作为Ingress Controller，自动监听了新创建的Ingress资源，并通过Host头路由到对应的Service。本地开发时，这种*.localhost域名的方式非常方便，不用配置本地DNS都能访问。

3.4 镜像导入与本地开发循环

在这个阶段，我想分享一个真正的高频操作：基于本地镜像的开发循环。绝大多数K8s开发者的痛点，在于每次改代码都要走完整的"构建-推送-拉取"循环。k3d可以通过k3d image import直接把镜像塞进集群里。

假设你的本地构建了一个叫myapp:dev的镜像：

docker build -t myapp:dev . k3d image import myapp:dev -c demo

导入完成后，直接在Deployment里使用这个镜像，K3s会自动从本地Docker存储中取用：

kubectl create deployment myapp --image=myapp:dev

之后每次修改代码，只需重复执行构建和导入两条命令，再重启一下Deployment：

kubectl rollout restart deployment/myapp

这样一轮迭代大概能控制在几十秒内，比推到远程仓库再拉下来快了不是一点点。

3.5 创建多集群进行隔离测试

使用k3d进行多集群操作时，每个集群都有独立的集群名称。它们的配置互不影响。我在做两个版本对比测试时，通常会同时创建两个集群：

k3d cluster create v1 --servers 1 --agents 1 k3d cluster create v2 --servers 1 --agents 1

然后分别操作对应的Kubeconfig上下文：

kubectl config get-contexts kubectl config use-context k3d-v1 kubectl config use-context k3d-v2

两个集群互不干扰，可以同时跑不同的应用版本，做对比测试。等测试完，直接删除对应集群即可：

k3d cluster delete v1

这种多集群模式还特别适合测试多集群ServiceMesh、跨集群通信等场景。在我做过的一次模拟中，两个集群通过--volume挂载共享数据目录，再配合--network让它们处于同一个Docker网络内，实现了跨集群的网络互通，测试效果非常理想。

3.6 删除集群与资源清理

开发完不用的集群就应该果断删除，别让它一直占着内存。删除单个集群：

k3d cluster delete demo

执行完后，检查是否还有残留：

docker ps -a | grep k3d

正常情况下列表应该是空的。如果发现有残留容器，手动清理：

docker rm $(docker ps -a | grep k3d | awk '{print $1}')

k3d的容器在删除集群时默认会同步删除，但Docker网络有时会残留，需要手动确认一下：

docker network ls | grep k3d

如果还有残留，同样手动删除：

docker network rm k3d-demo

4. 常见问题与排查技巧实录

4.1 集群创建失败的排查思路

k3d在创建集群时挂掉的场景不算少见，但绝大多数问题都出在几个固定环节。我把实际遇到过的问题整理成了一张速查表：

其中，镜像拉取问题是最常见的。如果你所在环境的网络访问Docker Hub比较慢，建议在创建集群前手动拉取镜像一次：

docker pull rancher/k3s:latest

这样避免了k3d在创建过程中因为拉取超时而中断。如果网络长期不稳定，也可以修改Docker的镜像加速配置，把Docker Hub的镜像拉取加速。

4.2 Kubeconfig相关的典型问题

K3s集群创建成功，但kubectl执行任何命令都报connection refused，这个问题的排查思路其实非常固定。

先检查上下文：

kubectl config current-context

然后检查k3d里的集群状态：

k3d cluster list

如果集群是健康的，但kubectl连不上，那多半是Kubeconfig文件里的集群地址不对。k3d集群的API Server默认绑定在0.0.0.0:6443，但你在容器外部访问时需要通过映射端口或者使用宿主机地址。解决办法是重新合并：

k3d kubeconfig merge demo --kubeconfig-merge-default -f

-f的意思是强制覆盖之前的配置。然后验证：

kubectl cluster-info

正常情况下输出里会有Kubernetes control plane is running at，这样就说明连接正常。

4.3 端口映射不生效的排查

端口映射不生效也是高频问题之一。有时候集群正常、服务正常、Ingress也建了，但访问localhost:8080就是没有任何响应。

排查顺序是这样三步：

第一步，确认宿主机端口确实被Docker的端口转发监听了：

lsof -i :8080

如果输出空，说明k3d的Loadbalancer容器没有正确绑定端口。查看Loadbalancer容器状态：

docker ps --filter "name=k3d-demo-serverlb"

正常状态应该是Up。如果容器反复重启，基本可以断定负载均衡器启动失败，原因多半是端口冲突或者配置问题。

第二步，检查集群内的Service是否正常：

kubectl get svc kubectl get endpoints

如果Endpoints为空，说明Pod没有正常运行或者标签选择器不对，Service没有可用的后端。

第三步，检查Ingress规则是否指对了Service名和端口。这里有个经常踩的坑：Service的端口名称和Ingress里写的端口号不匹配，导致路由失败。

4.4 使用私有镜像仓库

如果团队内部有私有镜像仓库，或者你需要使用自建的Registry来管理镜像，k3d也内置了支持。最推荐的方式是创建集群时直接指定Registry：

k3d registry create myregistry --port 5000 k3d cluster create demo --registry-use myregistry:5000

然后配置Docker客户端允许不安全的HTTP Registry：

{ "insecure-registries": ["localhost:5000"] }

修改完Docker配置后重启Docker服务，就可以直接往这个registry里推送镜像了：

docker push localhost:5000/myapp:v1

K3s集群内的节点能够拉取到这个Registry中的镜像，是因为k3d在创建集群时自动在所有节点上配置了对应的镜像仓库地址。这块配置通常不需要手动处理，但如果你的Registry配置了认证信息，就需要在k3d的配置文件中进行更详细的定义。

4.5 性能调优与资源控制技巧

k3d虽然轻量，但如果不注意资源控制，多个集群叠在一起还是可能把本地机器拖垮。下面几个做法在实际项目里很有用。

限制每个节点可用的内存和CPU。k3d的--agents-memory和--agents-cpu可以分别限制Agent节点的资源用量：

k3d cluster create demo \ --agents 2 \ --agents-memory 1g \ --agents-cpu 2

对于Server节点，可以传递K3s参数来减少资源占用：

k3d cluster create demo \ --k3s-arg "--disable=metrics-server@server:*" \ --k3s-arg "--disable=traefik@server:*"

@server:*是k3d的一个特性语法，表示该参数只作用于所有Server节点。禁用Metrics Server和Traefik后，集群内存占用能再降一截。不过要注意，禁用Traefik之后，Ingress功能不可用，你需要自己安装其他Ingress Controller或改用NodePort方式暴露服务。

另外一个容易被忽略的点是，K3s默认会在集群里启用一些额外的控制器和特性，但不是每个开发场景都需要它们。在资源紧张的机器上，可以考虑禁用掉不需要的组件，让系统资源集中在真正要测试的负载上。

4.6 k3d与CI环境的集成

聊完本地开发，k3d在CI环境里的价值同样值得单独说一下。在CI流水线中，你经常需要一套干净的K8s环境来跑集成测试。k3d因为启动快、不需要嵌套虚拟化、只依赖Docker，所以非常适合作为GitHub Actions等CI平台里的测试集群。

在CI里使用k3d的基本套路是这样：

- name: Start k3s cluster run: | k3d cluster create ci-cluster \ --servers 1 \ --no-lb

--no-lb会跳过Loadbalancer容器的创建，因为CI里通常不需要端口映射，这样可以再省一点资源。

测试完成后直接删掉集群，保证CI环境是干净的：

- name: Clean up run: k3d cluster delete ci-cluster

在这个模式中，有几个CI特有的坑值得提前预防。比如一些CI环境默认没有安装Docker CLI，或者Docker daemon用户权限不同，需要先在CI脚本里安装或确认Docker环境。再比如CI环境中K3s需要系统权限来创建iptables规则，如果agent运行在非特权模式可能会失败。这些在初始化流水线时都要考虑到。

5. 进阶使用技巧与扩展场景

5.1 通过K3s参数定制集群行为

k3d一个很强大的地方，是可以把任意K3s参数透传进去。这意味着你可以非常细致地定制集群的行为。比如关闭Traefik，改用自己熟悉的Ingress Controller：

k3d cluster create demo --k3s-arg "--disable=traefik@server:0"

比如配置K3s的日志级别和存储路径：

k3d cluster create demo \ --k3s-arg "--log-level=debug@server:*" \ --k3s-arg "--data-dir=/var/lib/k3s@server:*"

再比如开启K3s的Docker容器运行时模式，而不是默认的containerd：

k3d cluster create demo --k3s-arg "--docker@server:*"

这个模式在调试本地镜像时非常有用，因为Docker运行时可以直接访问宿主的Docker守护进程，使用本地缓存的镜像，省去了镜像导入的步骤。不过这个模式只建议在单节点开发环境中使用，多节点集群下的行为可能会与预期不一致。

5.2 多集群配置与集群切换

前面提到过可以用多个集群做隔离测试，这里再把集群切换的细节讲透。k3d创建的每个集群，都会有一套对应的Kubeconfig上下文，命名格式通常是k3d-<集群名>。

使用k3d kubeconfig merge可以把多个集群的配置都合并到一个Kubeconfig文件中，然后通过标准的kubectl上下文切换来管理：

k3d cluster create alpha k3d cluster create beta k3d kubeconfig merge alpha --kubeconfig-merge-default k3d kubeconfig merge beta --kubeconfig-merge-default kubectl config get-contexts kubectl config use-context k3d-alpha

切换上下文之后，你的kubectl操作就作用于对应的集群了。如果经常要在多个集群间切换，建议结合一些shell别名来减少输入成本，比如在~/.zshrc里加：

alias k3d-alpha='kubectl config use-context k3d-alpha' alias k3d-beta='kubectl config use-context k3d-beta'

5.3 模拟高可用控制平面

k3d也支持模拟高可用控制平面。方法很简单，直接指定多个Server节点：

k3d cluster create ha-demo --servers 3 --agents 2

当--servers等于3时，k3d会启用K3s的内置etcd模式，三个Server节点组成一个etcd集群，任意一个节点宕机，集群仍能正常工作。这种模式适合验证高可用相关的行为，比如控制平面节点故障时Pod如何调度、Leader选举是否正常等。

需要提醒的是，3个Server节点加2个Agent节点的集群，内存开销会显著增加，建议在资源充足的机器上运行。我在8GB内存的笔记本上跑过一个这样的集群，明显能感觉到系统有压力，不推荐在低配置机器上长期运行。

5.4 与Helm和Kustomize的结合

集群跑起来之后，部署应用通常不会只用kubectl apply，而是会用到Helm或Kustomize。k3d对这些工具没有任何限制，因为它们都是直接通过Kubeconfig与API Server交互的。

使用Helm部署应用，只需要确保kubectl当前上下文指向k3d集群：

helm install myapp ./chart --kube-context k3d-demo

使用Kustomize也很常见：

kubectl apply -k ./overlays/dev

这样一个完整的开发闭环就非常清晰了：代码改动 -> 构建镜像 -> 导入集群 -> helm upgrade -> 验证 -> 销毁集群。整个循环几乎全部在本地完成，没有网络延迟，没有配额限制，开发体验非常顺畅。

5.5 k3d配置文件方式的进阶用法

命令行参数适合简单场景，但如果你需要一组固定的集群配置供团队复用，k3d的配置文件方式会更加方便。k3d官方支持YAML格式的配置。

一个典型的配置文件示例：

apiVersion: k3d.io/v1alpha5 kind: Simple metadata: name: dev-cluster servers: 1 agents: 2 ports: - port: 8080:80 nodeFilters: - loadbalancer volumes: - volume: /tmp/data:/data nodeFilters: - all options: k3s: extraServerArgs: - --disable=traefik

保存为k3d-config.yaml，然后创建：

k3d cluster create --config k3d-config.yaml

配置文件的好处是可重复、可版本控制。团队新成员加入时，不再需要手工敲一堆命令，拉取仓库，一条命令就能得到一套完整且一致的K3s环境。这种标准化方式在团队协作中特别有价值。

5.6 k3d在边缘计算模拟中的角色

最后再聊一个容易被忽视的使用场景：边缘计算模拟。K3s本身主打边缘，所以k3d天然适合在本地模拟多节点边缘部署。你可以为每个边缘站点分配一个k3d集群，再通过--volume挂载不同的配置文件来模拟不同的站点状态。

比如模拟一个边缘站点的资源受限环境：

k3d cluster create edge-sim \ --servers 1 \ --agents 1 \ --agents-memory 512m \ --agents-cpu 1 \ --volume /tmp/edge-config:/config@all

这种方式对测试边缘场景下的应用行为非常有帮助，特别是验证资源限制、断网重连、数据同步这些场景。因为每个k3d集群都是独立的Docker网络，你甚至可以通过切断某个集群的网络来模拟边缘节点离线，观察应用的整体表现。

写在最后的几点经验

我在实际使用k3d的过程中，踩过几次坑，也积累了一些心得。最想说的一点是：k3d虽好，但别忘了它本质上是为开发环境设计的。它的目标不是模拟生产环境的所有细节，而是让你在本地快速获得一个可用的K8s集群，用来验证代码、跑通流程、调试问题。如果你需要验证的是生产环境的复杂网络策略、存储插件、或者大规模的调度行为，那还是应该老老实实用kind或者云上的托管集群。

另外，k3d的官方文档更新速度很快，新的参数和特性经常在版本迭代中出现。如果你在一个旧版本上遇到了莫名的问题，不妨先检查一下k3d和K3s镜像的版本是否匹配，在升级k3d之后，把之前创建的集群删除并重新创建一遍，很多奇怪的问题都会自愈。

如果你之前一直是在远程集群上做开发，我强烈建议你花一天时间把本地k3d环境搭起来。那种改完代码二十秒就能在K8s里看到变化的体验，真的会改变你的开发习惯。