K8s入门到实战：Pod原理、Rancher部署与微服务迁移全解析-代码聚汇网

K8s入门到实战：Pod原理、Rancher部署与微服务迁移全解析

股海求生·2026-09-18·阅读 21 GEO检测（免费）

KubernetesPodDocker

|难度：普通|阅读约 39 分钟

先把丑话说在前面：K8s 入门最大的坎，不是概念多，而是大多数人把 Docker 和 K8s 之间的边界彻底搞混了。我见过不少同事，docker run 用得飞起，到了 K8s 里却连 Pod 和容器是什么关系都讲不清；也见过有人把 Pod 直接当成容器来管，遇到多容器 Pod 启动问题就当场懵掉。这篇内容不是官方文档的搬运，是我从 Pod 核心原理一路做到 Rancher 实战、再把单节点 K8s 上的整套微服务环境迁移上云的完整梳理。我会把 Pod 为什么要存在、kubectl 和原生 Dashboard 怎么配合日常管理、Rancher 部署业务容器并解决外部访问、以及若依（RuoYi）微服务不停服不丢数据迁移到阿里云 ECS 的全链路都讲一遍。适合刚学 K8s 的人建立整个体系，也适合准备上生产环境的同学直接对照操作。

1. Pod 到底是什么？一个容易被误解的 K8s 最小单元

1.1 K8s 为什么不直接管容器

很多从 Docker 转过来的朋友，第一个问题就是：K8s 里最小管理单位既然是容器，那为什么要多套一层 Pod？直接把容器扔给 K8s 管不是更简单吗？

这个问题想明白了，K8s 的整体架构也就通了一半。Docker 容器本身解决的是"单机上怎么打包和运行应用"，它天然不具备跨主机调度的能力。你在 Node1 上跑了一个 nginx，但 Node2 上怎么访问它？Docker 时代你得自己维护端口映射、自己写服务发现。K8s 出现就是为了解决大规模编排问题，它需要一个比容器更上层的概念来承载调度、网络、存储和生命周期的统一管理。

Pod 就是这一层的产物。按照官方说法，Pod 是 K8s 中最小的部署单元和调度单元。一个 Pod 里可以有一个容器，也可以有多个容器。K8s 不会单独调度某一个容器，而是把 Pod 整体调度到某个节点上，Pod 里的所有容器共享同一个 Network Namespace、共享同一个 IP 地址、共享挂载的存储卷。你可以把 Pod 理解成"一组需要紧密协作的进程的集合体"，这些进程被绑定在同一台机器上，用 localhost 就能互相通信。

这个过程里有个很关键的分工逻辑：API Server 负责接收请求、Scheduler 负责决定 Pod 落在哪个节点、kubelet 负责在节点上真正拉起容器、kube-proxy 负责维护网络规则。但所有动作的颗粒度都是 Pod，不是容器。

1.2 一个 Pod 多个容器：sidecar、init 容器与共享生命周期

单容器 Pod 没什么难理解的，真正容易出问题的是多容器 Pod。这里先说一个大家都很关心的场景：一个 Pod 里如果有多个容器，其中一个容器没有成功启动，会不会影响其它容器？

答案是：会，而且影响方式比你想的更直接。

先说多容器 Pod 的典型结构。常见的有两类角色：一类是 sidecar 容器，它跟主容器并行存在，负责辅助功能，比如日志采集、网络代理（Envoy、Istio 的 istio-proxy 就是典型的 sidecar）、指标上报；另一类是 init 容器，它必须先于主容器启动完成，主容器才会被创建，init 容器一般用来做初始化动作，比如等待数据库就绪、生成配置文件、预加载数据。

这两种角色对 Pod 状态的影响完全不同。init 容器只要有一个失败，整个 Pod 就会一直停留在初始化阶段，主容器根本不会启动。sidecar 容器虽然和主容器并行，但 K8s 判断 Pod 是否 Ready 的依据是所有容器都处于 Running 且通过就绪探针。假如日志采集的 sidecar 因为镜像版本问题一直 CrashLoopBackOff，主容器就算正常运行，整个 Pod 也会被标记为 NotReady。

实际影响是什么？Service 的 Endpoints 里会摘掉这个 Pod，负载均衡不会把新流量转发进来；如果配置了滚动更新，新版本 Pod 一直不 Ready，Deployment 会卡住，旧版本 Pod 也不会被删除。我踩过这个坑：一个应用的主进程好好的，就是因为 sidecar 的采集配置写错，导致整条链路的数据流全断了。

所以记住一个结论：在 Pod 层面，容器之间不是"各管各的"，而是一荣俱荣、一损俱损。这也是为什么多容器 Pod 里的每个镜像都要做好健康检查，别指望某个容器挂了其它容器还能独善其身。

1.3 Pod 从创建到销毁：生命周期与常见故障定位

Pod 的生命周期在不同阶段有不同的状态，这是排查问题的基本功。

一个 Pod 大致会经历这几个阶段：

Pending：Pod 已被 API Server 接受，但还没有分配到节点，或者正在拉取镜像、初始化存储。卡在这通常是资源不足、镜像拉取太慢、PVC 没绑定成功。
Running：Pod 已绑定节点，所有容器已创建，至少有一个容器还在运行。
Succeeded：所有容器正常退出，一般用于 Job 类任务。
Failed：至少有一个容器以非零状态退出。
Unknown：kubelet 跟 API Server 失联，通常是节点本身出了问题。

除了这几个大阶段，K8s 内部还有一组 Conditions 可以帮助判断细节，最常用的四个是：PodScheduled、Initialized、ContainersReady、Ready。用 kubectl describe pod 能看到它们的状态和最后变更时间，排查卡在哪个环节非常有用。

举个例子，Pod 一直 Pending，你第一反应不是去看容器日志，而是 kubectl describe pod xxx，看 Events 区域写的什么原因。最常见的是 0/1 nodes are available: 1 Insufficient cpu，意思是所有节点都满足不了 CPU 请求，解决办法要么扩容节点，要么调小 requests 配置。如果节点选了，但容器一直 ImagePullBackOff，那大概率是镜像地址写错、私有仓库认证没配置，或者镜像根本不存在。

实操里我习惯按这个顺序排查：看 Pod 状态 -> 看事件 -> 看容器日志 -> 看节点资源，四个方向基本能覆盖 90% 的启动类问题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 从 docker run 到 kubectl：高频命令与原生 Dashboard 实操对照

2.1 K8s 和 Docker 到底区别在哪

面试也常被问到，但很多人回答得云里雾里。我一般用一句话概括：Docker 解决的是"容器怎么构建、怎么在单机运行"，K8s 解决的是"容器怎么在成百上千台机器上调度、编排、自愈、伸缩"。两者根本不是同一个层面的东西。

Docker 自带的 Compose 也可以定义多容器应用，但它只能在单台机器上生效，没有跨节点的服务发现、没有自动恢复、没有弹性伸缩。K8s 做的事情是把这些能力都收编进控制平面，然后以声明式的方式让你描述"最终应该是什么样"，剩下的交给控制器去演算和收敛。

所以日常使用中，你会发现在 Docker 上跑一个 MySQL 和用 K8s 跑一个 MySQL，思维方式完全不同。Docker 是命令驱动的：你执行 docker run，它就起来一个容器。K8s 是声明驱动的：你写一个 Deployment YAML，K8s 会不断检查"当前状态"和"期望状态"，一旦有偏差，立刻调谐回去。你必须接受一件事：在 K8s 里，手动去操作某个容器的习惯要彻底扔掉，你要操作的是控制器，是副本数，是 Pod 模板。

2.2 kubectl 高频命令：日常运维必备清单

kubectl 是操作 K8s 的入口命令，不需要全背，但下面这些高频命令应该形成肌肉记忆。

操作	docker 习惯	kubectl 习惯
查看运行实例	docker ps	kubectl get pods
进入容器	docker exec -it xxx bash	kubectl exec -it xxx -c container-name -- bash
查看日志	docker logs -f xxx	kubectl logs -f xxx -c container-name
删掉实例	docker rm -f xxx	kubectl delete pod xxx
查看描述信息	docker inspect xxx	kubectl describe pod xxx
临时跑一个实例	docker run --rm xxx	kubectl run tmp --image=xxx --restart=Never --rm -it

有几个容易忽略的细节值得单独说。

第一，kubectl logs 在多容器 Pod 里必须带 -c 参数指定容器名，否则会提示你选择一个容器。这个在排查 sidecar 问题时用到最多。

第二，kubectl get events --sort-by=.metadata.creationTimestamp 比单独 describe 单个 Pod 能看到的全局信息更全，尤其是当问题出在节点层面而不是 Pod 层面时，比如磁盘压力、网络插件异常，Events 里都会留痕迹。

第三，如果你要临时把本地端口映射到集群里的某个服务，用 kubectl port-forward svc/xxx -n namespace 8080:80，不需要改 Service 类型，调试期很香。

第四，YAML 相关操作是使用频率最高的。想快速生成一个 Deployment 模板，用 kubectl create deployment nginx --image=nginx --dry-run=client -o yaml，再改一改就是现成的清单。想查看当前对象的完整配置，用 kubectl get deployment nginx -o yaml > nginx-deploy.yaml，导出来就是当前集群里实际生效的内容。

2.3 通过 Kubernetes Dashboard 发布一个新 Pod/Service

原生 Dashboard 是老牌管理界面，虽然很多团队已经转向 Rancher 或者 Lens，但了解原生 Dashboard 的发布路径，能帮你更好地理解 K8s 对象之间的关系。

部署 Dashboard 很简单，官方 YAML 拉下来直接 apply 即可：

bash复制kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

默认情况下 Dashboard 需要 token 登录，而且只允许通过 HTTPS 访问。开发环境图省事，可以用 kubectl proxy 方式绕一下认证：

bash复制kubectl proxy

然后浏览器打开 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/，登录时选 token，从 service account 里取 secret 填进去。

登录之后，要发布一个新服务，核心操作是在顶部选择好 namespace，然后点右上角的"+"号，进入创建界面。这个入口很有意思，它给了你两个选择：一个是用表单逐步填写，一个是直接粘贴 YAML。我强烈建议直接粘贴 YAML，理由很简单：表单创建只能覆盖最简单场景，一旦涉及到探针、资源限制、多容器，表单就没法表达了。而 YAML 本身就是 K8s 的"源代码"。

一个最小可对外访问的服务，YAML 大致是这个样子：

bash复制apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-demo
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-demo
  template:
    metadata:
      labels:
        app: my-demo
    spec:
      containers:
      - name: demo
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-demo-svc
  namespace: default
spec:
  type: NodePort
  selector:
    app: my-demo
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080

在 Dashboard 里粘贴这份 YAML 并点击上传，Deployment 和 Service 就都创建好了。Dashboard 上能看到这个 Service 被分配了一个 NodePort：30080。外部访问时，用任意节点 IP + 30080 就能访问到服务，前提是云厂商安全组和节点防火墙放通了 30080 端口。

这里有一个新手非常容易困惑的点：port、targetPort、nodePort 三个端口分别代表什么。port 是 Service 在集群内部的虚拟端口，其它 Pod 访问服务时用 服务名:port；targetPort 是容器内实际监听的端口，也就是镜像里应用真正监听的端口；nodePort 是暴露到宿主机上的端口，范围被固定在 30000-32767 之间。理解这三个端口的对应关系，外部访问的很多坑都可以避免。

3. Rancher 实战：部署方式、Nacos 外部访问与本地桌面方案

3.1 为什么团队最终选择了 Rancher

原生 Dashboard 能做基本的管理和发布操作，但真要到了多集群、多团队、多项目的场景，它的组织能力就不太够用了。Rancher 的价值，首先是把多个 K8s 集群的管理入口收拢到一个控制台。你可以在 Rancher 里导入现有的 K8s 集群，也可以直接用 RKE/RKE2 一键创建新集群，Web UI 上就能完成节点添加、集群升级、ingress 配置、应用商店部署，不需要每个人都去记 kubectl 的上下文切换。

Rancher 还有一个让我很喜欢的点：它以"项目（Project）"为单位组织资源，一个项目下可以有多个 namespace，可以统一配置 RBAC 权限。研发、测试、运维各配一套账号，权限隔离就做得比较清楚了。对于小团队来说，Rancher 提供了一个不算重、但足够完善的治理层。

3.2 Rancher 本体部署与 Rancher Desktop 的取舍

先分清两个东西：Rancher 是一个可以部署在 K8s 集群里的管理平台，Rancher Desktop 是面向本地开发的桌面程序，类似 Docker Desktop，预装了 k3s 或 dockerd(moby) 运行时。两者的用途完全不一样，不要混为一谈。

生产环境部署 Rancher 最省事的方式，是准备一台独立节点，用 Docker 直接启动：

bash复制sudo docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  --privileged \
  --name rancher \
  rancher/rancher:stable

启动后浏览器访问 https://<节点IP>，第一次打开会让你设置 admin 密码。注意 Rancher 默认有自签名证书，浏览器会提示不安全，开发测试环境直接忽略即可。启动后它会在本地创建一个叫 local 的集群，这个 local 集群其实就是 Rancher 自己所在的 K8s 集群，可以直接在上面部署业务。

Rancher Desktop 则是我在本地折腾 Pod 和验证镜像时常用的。它的特色在于可以切换两种底层运行时：dockerd(moby) 和 containerd。如果你想在本地保持 Docker CLI 的习惯，就在设置里把运行时切到 dockerd(moby)，这样 docker build、docker run 这一套命令依然可用，同时又有了 K8s 集群能力，适合本地开发和调试。

3.3 用 Rancher 部署 Nacos 并实现外部访问的完整链路

Nacos 是目前国内微服务场景里用到最多的注册中心和配置中心之一。Rancher 部署 Nacos 这件事在网上被问了很多次，核心问题就是：在 Rancher 里把 Nacos 部署起来很容易，但怎么让外部访问到 Nacos 控制台和 API？

先说部署。在 Rancher 管理界面里，进入某个集群，选择目标 namespace（建议专门开一个 middleware 之类的项目空间），点"工作负载"->"创建"，选"Deployment"。镜像填 Nacos 官方镜像，比如 nacos/nacos-server:v2.3.2。关键的环境变量要配好：

环境变量	值	说明
MODE	standalone	单机模式，测试环境够用
NACOS_AUTH_ENABLE	true	开启鉴权，生产环境必开
NACOS_AUTH_TOKEN	自定义密钥	需要 base64 再 MD5 处理
NACOS_AUTH_IDENTITY_KEY	serverIdentity	配合鉴权使用
NACOS_AUTH_IDENTITY_VALUE	security	配合鉴权使用

如果你打算用 MySQL 存储配置，还要加 SPRING_DATASOURCE_PLATFORM=mysql 以及数据库连接相关变量。这里有个坑：Nacos 默认使用内嵌 Derby 存储，重启容器后配置会丢，所以但凡数据重要一点，就别省掉 MySQL 连接配置。

工作负载创建好后，要让外部访问，实际上取决于你所在环境的网络形态。我按常见场景分三种：

场景一：Rancher 跑在云服务器上，外部直接访问。 最直接的方式是给 Nacos 的 Service 选择 NodePort 类型，映射端口比如 8848 -> 30848。节点安全组里放行 30848 即可。访问路径是 http://节点IP:30848/nacos。

场景二：Rancher 跑在公司内网，想通过域名访问。 优先用 Ingress。Rancher 的界面里可以直接配 Ingress，指向 Nacos Service 的 8848 端口。域名解析到 ingress controller 所在节点，访问 http://nacos.example.com/nacos。

场景三：kubectl port-forward 临时调试。 不想暴露端口，只在本机看一眼控制台，在 Rancher 的 WebUI 里找到工作负载的"三个点"菜单，里有一个"在浏览器中打开"或"SSH/执行"的入口，命令行场景则用 kubectl port-forward 直接把本地端口映射过去。

需要留意的是，Nacos 微服务客户端跨网络访问时，注册上去的 IP 可能不对。因为 Nacos 在容器里默认会以 Pod IP 注册，如果客户端和 Nacos 不在同一个 K8s 集群网络里，客户端拿到 Pod IP 是访问不通的。解决办法是在 Nacos 容器环境变量里加 NACOS_SERVER_IP=节点IP（单机部署时指定对外 IP），或者在 Service 层做 DNAT。这个细节不处理，外部访问 Nacos 控制台能通，但服务注册发现问题一大堆。

4. 单节点 K8s 若依微服务不停服、不丢数据迁移到阿里云 ECS 的完整方案

4.1 迁移难点拆解：不停服、不丢数据意味着什么

把若依（RuoYi）微服务整套环境从单节点 K8s 迁到阿里云 ECS，如果允许停机，事情会简单很多：镜像导过去、数据导过去、启动服务，完事。但加了"不停服、不丢数据"这个前提，难度立刻上了一个档次。

先拆一下若依微服务架构里有哪些依赖：

多个微服务模块：Gateway 网关、System 系统模块、Auth 认证模块、File 文件服务等，每个模块都是一个 Deployment。
Nacos：注册中心和配置中心。Nacos 里的配置需要同步同步，注册的服务实例需要重新注册。
Redis：缓存、分布式 session。
MySQL：业务数据，这是"不丢数据"里最关键的部分。

迁移方案的核心思路是：先让新旧两套环境并行跑一段时间，通过数据同步工具把新环境不断追平旧环境，等数据一致性和服务状态都确认没问题后，再切换流量。 这样才能做到在线迁移，而不是停机搬运。

4.2 四条同步链路：镜像、数据、配置、流量

我把整个迁移拆成四条同步链路，每一条都有独立的处理方式和验证方法。

第一条链路：镜像同步。 源环境的镜像在本地仓库或者私有 Harbor，阿里云侧则使用容器镜像服务 ACR。用 docker pull 拉下来、docker tag 打上 ACR 地址标签、docker push 推上去。如果镜像数量多，建议写个脚本批量处理。这里注意架构一致性，迁移到云上后节点通常是 x86_64，如果源镜像有 arm 版本，务必重新构建。

第二条链路：数据库同步（最容易出问题的一条）。 MySQL 采用主从同步思路。先把旧库做一次全量备份再恢复到新库，随后新库设置为旧库的从库，通过 binlog 持续同步增量数据。等两边数据追平后，切换时直接提升新库为主库。如果你不想手动搭建复制关系，阿里云 DTS 数据传输服务也支持从自建 MySQL 迁移到云数据库 RDS，支持全量+增量同步，界面化配置，省不少事。

实际执行顺序可以这样：

bash复制# 1. 在旧库执行全量备份
mysqldump --single-transaction --master-data=2 \
  -u root -p ruoyi > ruoyi_full.sql

# 2. 将全量备份导入新库
mysql -h 新库地址 -u root -p ruoyi < ruoyi_full.sql

# 3. 配置增量同步
# 新库执行 CHANGE MASTER TO，指定旧库的 binlog 文件和 position
# 或者用云上 DTS 配置同步任务

# 4. 验证追平进度
# 对比两边一张核心表的数据量和最新时间

Redis 的同步相对简单。如果只是少量缓存，直接重启数据后冷启动慢一点也能接受；想要平滑一点，可以用 AOF 文件迁移，或者用 redis-shake 工具做同步。若依的会话信息放在 Redis 里，切换时如果能保留会话对用户体验影响最小。

第三条链路：配置同步。 Nacos 里的配置先导出，再导入到新环境的 Nacos。若依的各个服务在 bootstrap 配置文件里会指定 Nacos 地址，迁移后要改这些地址指向新环境的 Nacos。这里最隐蔽的坑是配置里如果写的是旧的 ECS IP 或内网 IP，迁移后一定要全局搜一遍替换掉。

第四条链路：工作负载清单同步。 把旧 K8s 集群里的 Deployment、Service、ConfigMap、Secret 导出为 YAML，然后统一修改镜像地址、环境变量中的连接地址，再 apply 到新集群。

在切换流量前，我会建议做一个"双跑观察期"，时间根据业务可接受度来定，短则半小时，长则半天。双跑期间密切关注新环境的日志、错误率、数据库连接数，确认无异常后，再把网关流量切到新环境。切流量的动作，可以改域名解析指向新集群的 Ingress/NLB，或者改 Nginx 上游，保证旧环境在观察期内继续保留，随时可以回滚。

4.3 迁移完成后 jmeter 压测：验证云上承载能力

迁移完成不代表结束，压测才是验证云上环境能不能扛住生产流量的关键一步。这一步通常由专门的压测人员来完成，但作为负责迁移的运维，你至少需要知道他要测什么。

压测方案一般包含三个维度：容量基准测试（确定最大吞吐）、稳定性测试（持续施压看资源水位是否平滑）、异常恢复测试（杀掉 Pod 看恢复速度）。

用 jmeter 脚本做高并发测试时，几个关键指标要盯紧：

QPS：每秒请求数，衡量系统吞吐能力。
RT（响应时间）：重点关注 TP99，如果 TP99 随着并发上升呈线性恶化，说明存在资源瓶颈。
错误率：压测过程中一旦出现 5xx，优先看是网关限流还是后端线程池耗尽。
资源水位：ECS 的 CPU、内存、磁盘 IO，数据库的连接数，Redis 的内存命中率。

压测最常见的两个问题，一个是数据库连接池被压垮，另一个是 Nacos 服务发现在频繁注册注销时出现延迟。这两个问题如果在压测阶段暴露，基本就说明上线前还需要做连接池参数调优和 Nacos 健康检查配置优化。

压测时一定要用独立的测试数据，别一上来就打生产核心表。我见过压测把线上数据写乱的案例，复盘时大家都很狼狈。

5. 从 Service 到 Mesh：K8s 服务治理的下一层演进

5.1 原生 Service 能干的事和不能干的事

K8s 原生 Service 解决了最基础的服务发现和负载均衡问题，但它能做到的粒度非常有限。Service 只做四层负载均衡，或者通过 Ingress 做七层 HTTP 路由，但像熔断、限流、超时重试、灰度发布、全链路追踪这些微服务治理能力，原生 Service 是不具备的。

很多团队用 Spring Cloud 或 Dubbo 框架时，这些治理逻辑都写在业务代码里或者注册中心里。但到了 K8s 原生环境，大家发现一个问题：框架层面的治理能力和 K8s 的调度能力是两套系统，互相不感知。这个矛盾直接催生了 Service Mesh。

5.2 Dubbo Mesh 的落地思路：把治理能力下沉到 Sidecar

Dubbo Mesh 是阿里在微服务框架向云原生演进时提出的一条路径。它的核心逻辑和 Istio 类似：不用改业务代码，在 Pod 里注入一个 sidecar 代理，由这个代理拦截所有的进出流量，把服务发现、负载均衡、熔断、限流这些能力从 SDK 里抽出来，下沉到基础设施层。

这套思路放到 K8s 里，你依然在写 Deployment、Service，但每个 Pod 里除了业务容器，还会多一个 mesh 容器。流量经过 sidecar 时，sidecar 通过控制面拿路由规则，然后执行转发。这样带来的好处是：服务治理规则可以统一配置、动态下发，业务团队不用再依赖特定的 SDK 版本。

在实际演进时，不必一步到位。可以先让 Dubbo 服务在 K8s 上跑稳定，再逐步引入 mesh sidecar 接管流量。从运维视角看，mesh 接管后，原来框架自带的重试、超时配置和 K8s 的探针、滚动更新策略要重新对齐，否则会出现 sidecar 层重试 + K8s 滚动更新同时触发导致的"雪崩式重试"。

5.3 这些知识点，面试时怎么讲出深度

这一整套内容里其实藏着很多经典面试问题。我帮你把这些问题的回答思路串一下。

问：Pod 和容器的关系是什么？答：Pod 是 K8s 的最小调度单元，封装一个或多个容器，共享网络和存储，生命周期由 Pod 统一管理。更好一点的回答会主动补充多容器场景下的 sidecar 和 init 容器区别。

问：多容器 Pod 中某个容器崩溃，会不会影响其它容器？答：会，因为 Pod 的 Ready 状态由所有容器和探针共同决定，容器崩溃重启不影响其它容器进程，但会导致 Pod 不 Ready，从而被 Service 摘除。init 容器失败则整个 Pod 无法进入 Running。

问：Deployment、StatefulSet 区别？答：Deployment 适合无状态应用，Pod 可以被随意替换；StatefulSet 适合有状态应用，保证稳定的网络标识和稳定的存储，如 Nacos、MySQL、ZooKeeper。

问：K8s 和 Docker 区别？答：Docker 是容器运行时和单机管理工具，K8s 是分布式容器编排系统，以 Pod 为最小调度单元，提供声明式管理、服务发现、弹性伸缩、自愈能力。

问：如何实现服务外部访问？答：四层用 Service NodePort/LoadBalancer，七层用 Ingress，本地调试用 kubectl port-forward。

如果你能把这些问题结合实际的 Rancher 部署和迁移经验来回答，基本能证明你不只是背过概念，而是真的在环境里折腾过。

说实话，K8s 这条路我从入门到能独立完成迁移改造，中间走了不少弯路。如果让我重新走一遍，我最想改的一点是：不要一开始就扎进 YAML 细节里，先把 Pod、Service、Deployment 这三个对象的关系彻底想清楚。 这三个概念就像房子的地基，地基稳了，Rancher 界面、Dashboard、迁移脚本、压测调优这些都只是往上添砖瓦而已。希望这篇从原理到实战的完整梳理，能帮你少踩几个我已经替你踩过的坑。