前言

作为前端，你是否遇到过以下困惑？

• 上线时运维说“Pod 起不来”，你点头却没听懂。
• 看到 SRE 发来的 K8s deploy yaml。replicasServiceIngress 一堆词，每个都认得，但连起来就不知道在说什么。
• 自己设了NODE_OPTIONS=--max-old-space-size=结果运维说 Pod 要给 8GB 内存，多出来那一半内存被谁吃了？
• 项目里同时出现Ingress和OpenResty / Nginx搞不清它们是不是同一个东西，谁替代谁？老实说，

这些痛点源于前端训练让我们对“客户端如何渲染”很熟悉。却几乎没有清晰模型去理解“我们的代码到底是怎么跑在服务器上的”。K8s 是容器编排领域的标准基础设施，对前端来说名词程序有点陡峭。老实说，这篇文章用一张嵌套图与贯穿例子。 把 K8s 最主要的五个名词讲透。 你不需要成为运维，只要能在跨团队沟通和读 yaml 时“对上号”。

一、先看这张图：五个名词的空间关系

flowchart LR
EXT
SVC
EXT --> SVC
subgraph DEP
direction TB
subgraph POD1
C1
end
subgraph POD2
C2
end
subgraph POD3
C3
end
end
SVC -.-> POD1
SVC -.-> POD2
SVC -.-> POD3
style EXT fill:#fff4e6,stroke:#d97706,color:#1f2937
style SVC fill:#fef3c7,stroke:#a16207。color:#1f2937
style DEP fill:#dcfce7,stroke:#15803d,color:#1f2937
style POD1 fill:#dbeafe,stroke:#1d4ed8,color:#1f2937
style POD2 fill:#dbeafe,stroke:#1d4ed8,color:#1f2937
style POD3 fill:#dbeafe,stroke:#1d4ed8,color:#1f2937
style C1 fill:#ede9fe,stroke:#6d28d9,color:#1f2937
style C2 fill:#ede9fe,stroke:#6d28d9,color:#1f2937
style C3 fill:#ede9fe,stroke:#6d28d9,color:#1f2937

怎么看这张图？

• 嵌套矩形 = 包含关系：Container 在 Pod 里；N 个 Pod 在 Deployment 里——真实层级。
• 实线箭头 = 请求流向：外部请求通过反向代理进入 Service。不过，
• 虚线箭头 = 选中关系：A Service 用 label selector “认领”一组 Pod。自动维护哪些可用——不是物理包含。
• 颜色对应章节： 橙=外部入口； 紫=Container，蓝=Pod；绿=Deployment；黄=Service，

The whole article will use a single case study—deploying a Next.js service called my-web-app v0.x → v0.y.

二、五大主要概念：一次讲清楚

再一句话说明边界，它不管什么事。)

Container

 把 Node + server.js + node_modules + Alpine OS 打成不可变快照。运行就是一个 container，即

没有它会怎样?按理说， 本地 pnpm dev 没事。上服务器报错——Node 版本不匹配、native 模块编译失败、glibc 不兼容…容器把运行环境+代码打包为不可变快照，消除“我机器好”问题。

 CI 把代码打成镜像

docker buildx build --push \
--platform linux/amd64 \
-t registry.example.com/my-web-app:v0.x .

📌 Image vs Container = 类 vs 实例

• image: 不可变 tar.gz 存放于仓库，不“运行”。
• container: 从 image new 出来的一次具体运行。
• Même image can spin up many containers。
• Dockerfile 是 image 的建立脚本。

类比 OOP：image 是类，container 是实例 )。

Pod

 N 容器一起开机跑的最小单位。通常只跑业务 container。但可携带 sidecar，共享网络/存储，并获得临时 IP。

没有它会怎样? You only have images and isolated container processes—no unified namespace/network/store or lifecycle control. Pods are what scheduler sees.

 A v0.x pod spins up on some node—each pod gets its own IP. When it restarts IP changes—*** do we need Service for stable name.

'NODE_OPTIONS' 4GB ≠ Pod 4GB

• User often sets NODE_OPTIONS=--max-old-space-size=4096MB and thinks Pod memory must be exactly that..
• The difference stems from: – V8 JS heap – V8 internal buffers – Native allocations – Sidecar containers memory – Runtime peak buffer overhead

Rule of thumb: Pod memory ≈ Node heap × ~ ×  to accommodate native & sidecar & peaks.

Deployment

•  A YAML that declares “I want N pods running this image forever”. It manages replica count & rolling updates.
• 没有它会怎样?话说回来， If a pod dies re's nothing automatically replacing it. Upgrading v0.x→v0.y requires manual scripts to spin up new pods n tear old ones down.
• yaml apiVersion: apps/v1 再看kind，Deployment metadata: name的观点是。my-web-app spec的观点是，replicas: template: spec这方面，containers: - name: app 说到image，registry.example.com/my-web-app:v0.x When CI pushes new image v0.y K8s performs rolling update—one pod at a time replaced while keeping desired replicas.