企业官网建设流程全解析

说个有意思的事。我给团队新人讲容器编排，开场讲了半小时Deployment、Service、HPA，对方眼神完全是空的。后来我换了个说法：你就想象你在煮饺子。十分钟后，这位新人自己把Docker和Kubernetes之间的关系复述得明明白白。这套“煮饺子理论”后来被我用了很多年，几乎每个场合都管用。今天把它完整整理出来：Docker到底是什么、Kubernetes到底在编排什么、两者之间那条经常被绕晕的分界线，以及这个比喻在哪些地方有效、哪些地方会误导你。

这套理解方式特别适合三类人：刚接触云原生的开发，想从传统运维转容器方向的同学，以及要在团队里推动容器化、但一直不知道怎么跟同事讲清楚价值的负责人。看完你不仅能会“说”，还能在真实环境里明白自己到底在操作什么。

1. 为什么偏偏是煮饺子：容器编排的最佳心智模型

先说结论：煮饺子这套流程，跟容器化之后的部署流程契合度相当高，高到不像巧合。一口大锅、一锅水，水是共享的、火是共享的，但每只饺子都有自己的皮、自己的馅，捞出来放在盘子里互不干扰。这几乎就是容器和宿主机关系的原样复刻。

我最早试过很多类比，什么“集装箱”“标准化货运”“搬家打包”，都能讲通一部分，但都有硬伤。集装箱讲的是“把东西装进标准箱子”，但它讲不清楚资源共享、弹性伸缩、故障自愈这些容器编排里的核心动作。搬家的比喻更糟，因为搬家是“一次性动作”，而容器是会反复重建、复制、上下线的活物。

煮饺子不一样。它天然包含三个核心阶段：包饺子（构建镜像）、下锅煮（运行容器）、按桌上菜（调度与对外提供服务）。而且这三个阶段不是一次性的，是持续发生的。一个食堂一天要煮几百上千份饺子，每桌需求不同，有的要多放香菜，有的要少放醋，有的要吃素的，有的要免葱。要把这些安排明白，光靠一口锅、一个人是不够的，你得有个后厨管理体系。

这个体系就是Kubernetes。换句话说，Docker是“把饺子包好、煮熟”的工具，Kubernetes是“在高峰期让几百桌客人准时吃上饺子”的后厨管理平台。

用一张表把两者的映射关系摆出来，后面所有细节都好谈了：

之后的所有分析，其实都是在这张表上做细化。先记住一个大逻辑：Docker解决的是“单个容器怎么打包、怎么运行”，Kubernetes解决的是“成千上万个容器怎么协同、怎么不打架、怎么自动恢复”。它们不在同一个层次。用食堂的话说，Docker是后厨里的锅和手，Kubernetes是整座后厨的管理制度与排班系统。

2. 先从一只饺子说起：Docker到底做了什么

很多人把Docker理解成“虚拟机替代品”，这就跑偏了。虚拟机是把整间房子隔成一间间独立公寓，每间都有完整的水电、燃气、厨房、厕所，互相独立但极其浪费。Docker更像是同一口锅里煮饺子——水是那锅水，火是那个火，但每只饺子靠“皮”把自己和外面的水隔开来，互不串味。

这个“皮”，就是容器技术里的内核隔离能力。它不像虚拟机那样每个容器要装一个完整的操作系统，而是共享宿主的操作系统内核，只隔离文件系统、网络空间、进程视图、资源配额这些东西。结果是：启动一个容器只需要毫秒级时间，开销极小，一台普通服务器能同时跑几十上百个容器。

2.1 镜像为什么可以“分层”：饺子的皮、馅、蘸料可以分别预制

无论你是直接docker run拉别人做好的镜像，还是自己写Dockerfile构建，都会接触到镜像分层的概念。这个概念的直观类比就是：你包饺子不会每次从种小麦开始，而是去菜市场买现成的饺子皮、买提前剁好的肉馅、买现成的蘸料，回家直接包、直接煮。

Dockerfile里每一行指令，都会生成一个新的只读层。比如：

FROM node:20-alpine # 基础镜像，相当于买现成饺子皮 WORKDIR /app # 相当于收拾好案板 COPY package*.json ./ # 把馅料配方单拿进来 RUN npm install # 开始剁馅、调馅 COPY . . # 把今天要用的鲜肉彻底包进去 CMD ["node", "app.js"] # 写下这锅饺子要煮多久、怎么捞

每一层都会被Docker缓存。你改一次代码，只需要重新跑最后一次COPY之后的那几层，前面已经跑过的层直接从缓存里拿。这就像食堂师傅今天只需要换新一批馅料，饺子皮不用重新擀。我见过很多新手反复踩同一个坑：把COPY . .写在RUN前面，导致每次代码变动都让依赖安装层缓存失效——相当于每次包饺子都要重新种麦子，构建时间从几十秒变成十几分钟。

2.2 容器运行时：那只正在锅里翻滚的饺子

镜像构建出来是静态的，存储在磁盘上或者镜像仓库里——它还没下锅。当你执行docker run的时候，Docker引擎才会在这个镜像之上加一层可写的运行层，把进程拉起来，这只“饺子”才算真正在锅里翻滚。

运行中的容器有几个边界特征值得注意，它们都能在煮饺子的场景里找到对应：

• 文件系统隔离：每只饺子咬开是自己的馅，不会窜到隔壁饺子那里。容器拥有自己独立的文件系统视角。
• 网络隔离：每个容器默认有自己的网络命名空间。本机访问容器内端口，要做端口映射，比如-p 8080:3000。相当于后厨煮好了饺子，要端到前厅窗口，得通过指定窗口递出去。
• 进程隔离：容器内看到的进程树是独立的一套。这个隔离是好事，但也有副作用——很多基础镜像里没有完整的init系统，进程成为孤儿之后容易无人回收，这就是常说的“僵尸进程”问题，具体表现是明明容器还活着，里面的子进程却越堆越多。

2.3 数据卷：共用的蘸料碟和可以带走的调味罐

容器是临时的。你删掉一只饺子，那饺子里带的东西就没了。但生产环境里绝对有大量需要留存的数据——数据库文件、日志、上传的附件。这时候就要用到数据卷。

数据卷的类比很贴切：它像食堂里那个“共用的蘸料碟”或者“可以带走的大调料罐”。容器（饺子）可以被删掉、被替换，但数据卷（调料罐）是独立于容器之外的生命周期，换一只新饺子照样能蘸到同一罐料。你在docker命令里看到-v mysql-data:/var/lib/mysql，意思就是：把名为mysql-data的“调料罐”挂到容器（饺子）的某个固定位置，容器重建后数据不丢。

注意：Docker里的数据卷如果用的是本地目录，请务必搞清楚持久化语义。部署到单机没问题，但一旦上Kubernetes，本地数据卷意味着“这罐调料只能放在某一个灶台上”，调度到别的机器就找不到了。这会直接引出后面要讲的有状态服务难题。

2.4 Docker Compose：先学会煮一整套宴席套餐

单只饺子当然不够。本地开发一个应用，经常要同时起前端、后端、数据库、缓存好几个服务。如果挨个docker run加参数，命令很快变成天书。

Docker Compose就是“提前排好的菜单套餐”。你写一个docker-compose.yml，把几个容器、端口映射、网络关系、环境变量都声明好，一条docker compose up -d把整套宴席端上桌。这个工具在单机环境里非常够用，我甚至认为很多项目根本不需要更重的东西。它对应煮饺子的场景是什么呢？是一桌人点了不同馅的饺子，师傅把需求写在一张小单上，按单下锅，出锅按桌分好。

本地开发阶段，Compose几乎是体验最好的编排工具，够轻、够直观、调服务方便。但它的上限非常明显：只能在单机上跑，跨多台机器、自动伸缩、故障漂移这些高级后厨管理功能它一点都没有。这就是下面要提到的，为什么你需要认真评估是不是要上Kubernetes。

3. 中央厨房与家庭厨房的差距：Kubernetes到底在管什么

先把一个常被误解的点说清楚：Kubernetes不是“能管Docker的Docker”。它跟Docker不是上下级关系，而是不同层级的系统。Docker是单机容器运行时的具体实现，Kubernetes是一个跨多台机器的集群编排系统，它对“要跑什么、跑多少个、怎么暴露网络、怎么升级”做声明式管理，底层的具体容器运行时可以由Docker承担，也可以是其他容器运行时。

用食堂来理解：Docker是灶台，Kubernetes是排班表、巡检制度、菜单管理系统、食材库存系统、厨具维修流程的总集合。它的问题不是“怎么把一只饺子煮好”，而是“高峰期300桌都在催菜的时候，怎么保证每桌都能吃到对的饺子、熟透的饺子、上菜顺序不乱的饺子”。

3.1 声明式管理的核心：告诉食堂“要多少盘饺子”，而不是“去煮饺子”

如果你用过最原始的运维方式，一定是命令式的：去服务器上执行什么操作，把容器起起来，把进程杀掉，把端口改掉。哪天服务器宕了，你得亲自跑过去手动拉起一切。

Kubernetes把这个逻辑整个倒过来。你做的事情不是“执行动作”，而是“声明期望”。你写一个Deployment清单，里面写明：我要跑3个副本，镜像版本是某个Tag，容器需要多少CPU和内存。这个清单提交之后，Kubernetes的内部控制器会一直盯着一件事——“系统当前的Pod数量是不是3个？镜像是不是对的？Pod是不是健康？”

这个模式类比过来就是：你不需要打电话告诉后厨“现在去煮3盘猪肉白菜饺子”，只需要在食堂管理看板上挂一个牌子“猪肉白菜饺子：3盘在制”，后厨主管会不断巡场，发现只有2盘就补到3盘，发现那盘饺子糊了就倒掉重做。这叫调谐循环，是Kubernetes几乎所有功能的底层思想。

这里也解释了一个新手常见困惑：为什么我改了Deployment的镜像版本，容器不会立刻变，要等一会儿？因为控制器的巡查不是即时的，它按自己的节奏不断比对“期望状态”和“实际状态”，直到收敛。有点像后厨主管每30秒巡一圈台面，发现不对才动手。

3.2 Pod：一盘饺子而不是一口锅

很多人上来就学Kubernetes，首先看到的不是“容器”，而是“Pod”，脑子里就开始打架：我明明是学容器，怎么Kubernetes里最小的调度单位成了Pod？

Pod这个概念用饺子类比需要稍微调整一下。之前说Docker的容器是饺子，到了Kubernetes，准确的类比应该是：Pod是一个餐盘，上面可以放一只饺子，也可以放一只主饺子和两碟蘸料小菜。餐盘上的所有东西共享同一个“餐桌身份”（IP地址、网络命名空间、存储卷），它们一起被端上桌、一起被撤走。

为什么这样设计？真实场景里有大量“几个进程必须紧挨着一起运行”的需求，比如：主业务容器旁边要配一个sidecar容器专门收集日志，或者主容器旁边配一个容器负责同步配置文件。这两个容器必须共享网络、共享存储，生命周期也必须一致。把它们放进同一个Pod，调度到同一台机器上，Kubernetes才能保证“这盘菜一起上桌，不拆散”。

实际经验：Pod里尽量只放真正有“共生关系”的容器，不要把Pod当成一个Mini虚拟机塞七八个业务进程。很多新手把主业务和辅助业务堆进一个Pod，看起来运行正常，但一旦其中一个容器OOM，整个Pod被整体重建，影响面会被无谓放大。

3.3 Deployment、ReplicaSet、Service：管理“卖完就补”和“按窗口取餐”

说回Deployment。你在生产环境日常打交道最多的就是这个对象。它管理着一组相同配置的Pod副本。Deployment内部还有一层ReplicaSet，负责精确控制“当前有多少个Pod在跑”，Deployment则管更高层的版本策略。

手写YAML之前，先记住它们分工，否则填字段时会很困惑。

Service这个对象又解释了一个高频困惑：Pod的IP是不断变化的，因为Pod会重建、会漂移，那别的服务怎么稳定地访问它？方案是Service。它像前厅那个固定窗口——不管后厨内部怎么换人换锅，窗口始终在那儿，外面客人只需要记住“到6号窗口取餐”。Service背后维护一份Pod地址列表，Pod挂了重建，列表自动更新。

3.4 从“手动发布”到“滚动更新”：一次真实的两个版本转换经历

举一个我们团队的实际例子，更能说明Kubernetes带来的体感变化。早先某个Java服务部署十几台机器，发布流程是：先拉一台机器下线、备份旧包、上传新包、重启进程、观察日志、再把机器加回来，一台一台挪，大概要40分钟，中间出问题要手工回滚，手忙脚乱。

迁移到Kubernetes之后，配置好Deployment的滚动更新策略，发布基本就是改镜像Tag然后kubectl rollout restart。Kubernetes自己控制节奏：先起一个新的Pod，等它通过readiness探针，再把一个旧Pod撤下来，然后再起下一个。整个过程相当于食堂换馅料配方，不是一下子把几百份饺子全倒掉重煮，而是先做两盘给熟客试吃，确认没问题再逐步增加新品比例。

这背后是Deployment的strategy字段。默认RollingUpdate策略，你可以设置maxUnavailable和maxSurge，控制滚动过程中最多允许几个旧Pod不可用、最多允许比目标数量多几个新Pod。这两个参数是最容易被新手忽略的——设得太保守，发布极慢；设得太激进，发布瞬间容量塌掉。我一般建议第一版先用maxUnavailable: 0、maxSurge: 1，保证整个滚动过程中营业执照始终满量，等跑熟了再逐步加码。

3.5 探针：怎么判断“饺子熟了”和“饺子能上桌了”

做后厨管理，最怕的不是饺子没熟，而是你以为熟了、其实没熟，端上桌客人咬一口发现还是面粉。Kubernetes里的探针就是后厨的质检员。它分三种，对应三个不同检查目的：

• 存活探针（livenessProbe）：检查饺子还有没有在锅里，如果坏了就倒掉重煮。对应到容器，就是检查进程是不是假死，失败就让Kubernetes杀掉并重建。
• 就绪探针（readinessProbe）：检查这盘饺子能不能端上桌给客人。对应到容器，就是服务有没有完成初始化、能不能接收流量，失败时Pod会被暂时从Service的“可服务列表”里摘掉，但不会被杀掉。
• 启动探针（startupProbe）：检查新饺子下锅之后，多久算正式开始煮。适合启动很慢的应用，给它一个宽容期，别让另外两个探针过早误判。

最常见的错误是把liveness探针写得太敏感。比如探针请求一个耗时接口，接口因为业务高负载变慢，探针超时，Kubernetes杀掉Pod；Pod重建后继续变慢又被杀，形成“崩溃循环”。说白了，这是质检员手太痒，一只饺子翻动太频繁，最后破皮了。合理做法是liveness探针用最轻的路径（比如看进程或看一个极简health端点），把业务上的复杂检查放到readiness里，让慢启动的应用先摘流量而不是被反复杀死。

4. 不是所有馆子都需要中央厨房：从Docker走向K8s的真实评估

聊到这里，你可能会觉得Kubernetes什么都是好的，赶紧上一个集群再说。慢着。我见过太多团队在最不合适的阶段硬上K8s，最后运维复杂度爆炸、排障难度飙升，反而拖垮了发布效率。

核心判断标准不是“这个技术火不火”，而是“你到底有没有那么多饺子要同时煮”。如果你平时只有一台服务器、十几个容器、流量平稳、两三个月才发一次版本，用Docker Compose加crontab做点简单健康检查完全足够。硬装一个K3s集群就是拿大炮打蚊子，运维成本比那点弹性收益高得多。

4.1 五个维度评估：到底要不要上Kubernetes

我自己习惯用一个很朴素的二维判断：规模是否大到“手动操作已经明显出错”。展开说就是五个指标。

前两者基本决定了“该不该上”。我之前接触过一个做内部工具的小团队，服务只有七八个容器，硬上了K8s，结果光排网络问题就排了两周。后来退回去用Compose，世界清净了。工具没有高下之分，只有合不合适。

4.2 迁移中最容易翻车的三件事：配额、探针、有状态数据

假设你已经决定迁移，再讲三个真实环境里一定踩得到的坑。

第一，资源配额没设对，导致大量OOMKilled。Kubernetes不是把所有资源自动管理好的“黑科技”，你必须在Deployment里写清楚每个容器要多少CPU和内存。不写的后果是调度器只能“瞎猜”，一台机器上可能塞爆；写了但不对的后果更常见——limit设得太小，Pod在业务高峰期直接被内核杀掉。我们线上有个服务，迁移后一到大促就重启，排查半天发现内存limit写的是200Mi，实际Pod峰值要500Mi。相当于给一家店限死“每锅只能装10只饺子”，硬塞20只，锅盖直接掀飞。

第二，就绪探针缺失，流量在Pod刚启动时就打进来了。很多应用初始化要好几秒，如果readiness没有配，Service会把还没就绪的Pod也登记为可服务，前几个请求直接失败。等你看到“连接拒绝”的时候，问题早就发生过了。这个必须配，而且要留足初始化的缓冲，配合startupProbe给慢启动应用一个宽限。

第三，把有状态服务直接跑在本地存储上。数据库、消息队列这类服务的数据必须持久化。Kubernetes里本地卷跟节点强绑定，Pod一旦被调度到别的节点，旧数据就“丢”在原来那台机器上。小规模场景用hostPath还能凑合，规模一上去迟早要接分布式存储的持久卷，或者干脆把有状态中间件放在Kubernetes之外托管。不要觉得这是偷懒，很多大厂实际也是这么干的——让K8s专心管理无状态业务容器，中间件单独用云托管省心得多。

4.3 一个稳妥的分阶段迁移路线

再给一套建议路径，避免一上来全量搬空：

1. 先把无状态业务服务容器化，本地用Docker Compose跑通。
2. 搭一个最小K8s集群，把非核心、流量低的业务先迁上去，跑熟Pod、Deployment、Service、Ingress这四个对象。
3. 配置好命名空间和资源配额，让多个团队在各自“档口”干活，互不抢资源。
4. 然后才逐步迁移有状态服务，或者直接购买外部托管数据库方案。
5. 最后再做自动伸缩、监控告警、日志采集这些锦上添花的东西。

我见过最快翻车的做法，是第一天就引入十几个云原生组件，Helm、Istio、Prometheus全家桶齐上，结果连基础发布都不稳。云原生这事跟做菜完全一样：先学会颠勺，再开连锁店。

5. 从后厨到前厅：把云原生生态的全流程串起来

Docker和Kubernetes只是容器化这套流程里的两个核心节点。真正到生产环境，你还会遇到一票经常一起出现的工具。如果只盯着这两个，很容易只见树木不见森林。我用食堂场景把整条链路串一遍，这样你看任何云原生架构图时，都能快速在心里给它贴上“这是后厨哪个环节”的标签。

一条完整流水线是这样的：代码提交后CI自动构建镜像，镜像推向镜像仓库，K8s从仓库拉新镜像并滚动更新Pod，外部请求通过Ingress进入集群，再由Service分发到具体Pod，Prometheus监控整个集群状态，日志系统收集所有容器的输出。每一个环节都有对应的食堂岗位。

5.1 Helm：把几百行YAML打包成一张菜单

写K8s配置最痛苦的就是YAML实在太多。一个服务往往要Deployment、Service、ConfigMap、Secret、Ingress好几个文件，每个文件动辄几十行。Helm做的事就是把这些文件打包成一个“排好版的菜谱包”，安装时用一个命令部署整套服务，升级、回滚也都有对应命令。

用饺子类比：你不需要每天跟后厨讲“皮要擀多薄、馅要搅多少下、蘸碟里放几克醋切几根香菜”，只要说“给我来一份猪肉白菜套餐”，后厨照着标准菜单执行就行。你在生产环境里用Helm Chart部署一套基础服务，相当于直接找食堂管理层要了一份成熟菜谱，比自己从零配调味要靠谱得多。

5.2 Ingress与Service Mesh：从“取餐窗口”到“传菜滑轨”

Service解决的是集群内部访问的稳定入口，而集群外部的流量要进来，就轮到Ingress。你对外暴露服务时，不需要给每个服务都申请一个公网入口，而是让Ingress像饭店门口的大接待员一样——看客人的招牌菜点单（域名/路径），把他领到对应档口。

Service Mesh这个概念很多人觉得抽象，其实用食堂类比也顺：它是在各后厨档口之间架设的一条传菜专用滑轨，每个档口之间传菜不用人跑、不用喊话，统一走这条索道。它解决了服务之间调用的超时重试、熔断、观测等问题，而且对业务代码零侵入。不过我得诚实说一句：Service Mesh带来的运维复杂度相当高，如果服务数量没有大到跨团队治理的规模，不要上，这是典型的“大食堂才需要的传菜系统”。

5.3 可观测性：没有仪表盘的后厨没法开连锁店

一台机器跑几个容器，出了错SSH上去看日志就行。一旦上了K8s，Pod会漂移、会重建，你很难再靠“人肉登机器”排障。这时候需要一套可观测性体系：指标、日志、链路追踪三件套。

这就像食堂开了十几家分店之后，后厨主管不可能天天蹲一家店里看火候，得靠总控室的大屏幕监控：每个灶台温度多少、每道菜出餐耗时多长、哪个档口异常报警。K8s里的监控大概也是这个地位，它不是部署完之后“有空再加”的插件，而是和业务服务同等重要的一等公民。

6. 这个类比最危险的三个地方：什么时候必须放下饺子

类比是拐杖，不能当腿。用过头的比喻会让人在真实问题上产生错误直觉，这一节专门讲三个最容易误伤人的点，都是我在实际带人的时候反复纠正过的。

6.1 Pod不是“锅”，更像“餐盘”

前面强调过，Pod里可以放多个容器。但很多人画着画着又把它画成“一口锅里有几只饺子”。这个偏差会直接影响你写YAML的判断。真实场景里，同一个Pod里如果只有一个主容器，倒是无妨；但如果把日志收集、配置同步这些辅助逻辑都往一个Pod里塞，Pod就会变成一个越来越难以排障的“杂烩套餐”。边界一定要用“餐盘”而不是“锅”来想：同一个餐盘上的东西必须共享网络和存储且生死与共，否则就应该拆成独立的Pod。

6.2 Kubernetes不关心菜好不好吃，它只关心“有没有熟”

调度器并不会理解你的业务逻辑。它不关心这个服务是支付网关还是博客评论，它只知道Pod声明了要多少CPU和内存、当前集群哪个节点有足够资源。换句话说，Kubernetes提升的只是“运行层的稳定性”，业务代码的逻辑缺陷它救不了。有些人以为上了K8s就能解决所有故障，这是很危险的误解。就像食堂再高级的后厨管理系统，也救不了一位把盐当糖放的师傅。

这个边界在实际运维里表现为：你可以设计优雅的探针来发现“饺子没熟”，但探针永远基于特定的健康检查接口，不会告诉你“馅的配方是不是过时了”。业务侧的灰度逻辑、错误率阈值、用户体验指标，仍然需要你自己去定义和建设。

6.3 资源声明不是“饭店订餐数量”，有可能会超卖

Kubernetes的调度器在调度Pod时，主要看的是“请求值”（request），而不是“限制值”（limit）。这意味着如果每个服务都把request写得很保守，节点实际负载可能远超理论值。这在食堂里的对应是什么？是“一个灶台明明只能同时煮10盘饺子，预订登记时只记了6盘，结果一高峰挤进来20盘”。

解决这个问题没有银弹，只能靠真实负载观测不断调整。我的经验是：先给每个服务设置合理的request等于日常稳定用量，limit留出1.5到2倍的峰值余量，再用监控数据逐步修正。不要盲目相信“K8s会自动搞定”，它只是忠实地执行你给的数值。

说回到学习路径。我在带新人时总是先讲一遍煮饺子，然后立刻让他们去干两件事：装一个本地的单节点集群，亲手把一个小服务部署上去；再手动写一个带就绪探针的Deployment，故意把端口写错，观察Pod的状态流转。类比给了你发力方向，真正让技术长在身上的是这些动手撞墙的过程。

这套理解框架到现在还留在我的工具箱里。后来面试候选人，遇到对方说“K8s原理很熟但没怎么用过的”，我也会让他讲讲Pod和Deployment的关系，很多人讲两句就开始背文档。能把它们放回“后厨怎么按时出几百份饺子”这个具象场景里的人，通常对系统的理解会更深一层。最后给你一个我越来越坚定的建议：如果你的项目还在早期，不要急着集齐所有云原生组件，先把Docker、Deployment、Service这三样彻底玩明白，那才是真正的大厨基本功。