企业官网建设流程全解析

第一次真正上手Kubernetes，是在一次线上服务扩容的“惨案”之后。当时我用一个脚本把新起的容器实例分发到三台机器上，结果其中一台突然宕机，整个集群的负载瞬间分布失衡，服务超时、接口报错，值班同事连轴转了一个通宵才勉强恢复稳定。后来我逐步研究K8s，才后知后觉地意识到：容器只是解决了应用打包的问题，真正让你省心的，是容器之上的那层编排能力。

Kubernetes，也就是大家常说的K8s，本质上是一个容器编排平台，解决的是“容器数量一多、环境一复杂、管理成本就指数上升”这个核心矛盾。它能干的事情，概括起来就是四件：自动调度、自动伸缩、故障自愈、服务治理。如果你正在维护多个容器实例，想统一管理它们并保证线上稳定，或者正准备从单机容器走向集群化，这篇文章值得你花点时间从头读一遍。下面我会从K8s的诞生背景、整体架构、核心功能，到一次完整的部署实操，再到高频问题的排查方法，一层一层拆开讲。

1. 从一个容器的烦恼说起：为什么需要K8s

真正让我下决心去学的K8s，不是靠别人推荐，而是一次典型的“三台机器三份配置”事故。当时我负责的一个内部系统跑了十几个容器，每台服务器上手动维护一套启动脚本。某个流量高峰期间，一台机器磁盘写满，容器不断重启，偏偏那天没有值班的人盯着监控。等我们发现异常时，已经有大量请求超时，用户侧体验已经受到了实际影响。

复盘的时候我意识到，容器虽然保证了应用运行环境的一致性，但它解决不了三个问题：容器到底怎么分布到多台机器上才算合理？机器挂了之后，容器怎么自动迁走？多个容器之间怎么实现互相发现和通信？这三个问题在容器数量少的时候，靠人肉运维勉强能应付，但一旦规模上到几十上百个容器，人肉路径就彻底走不通了。

后来我才真正理解，K8s不是某个锦上添花的工具，而是从单机容器走向集群化之后的基础设施底座。

1.1 单机容器管理的“三个噩梦”

很多人刚开始接触容器时都会觉得：有镜像，跑起来不就行了吗？确实，单机上一个容器跑起来很轻量，一条命令就能启动。但真正放到生产环境里，问题会接踵而至。

第一是调度问题。你有五个实例，到底怎么分配到几台机器上？内存敏感的放哪台？CPU密集的放哪台？如果所有实例都堆在同一台机器上，机器一挂就是全军覆没。第二是网络问题。容器A要访问容器B，怎么知道B的地址？B重启了地址变了怎么办？A和B之间的流量怎么做负载均衡？这些在裸容器时代全都要自己去解决。我见过不少团队，靠写脚本、维护一个IP列表来硬撑，每次发布都会遇到各种说不清的访问异常。第三是状态与存储问题。容器本身是无状态的，但业务往往需要数据落地。数据库容器重启后，数据还在吗？日志分散在各节点上，要怎么统一收集？

这三个问题单独拆开，各自都有专门的工具可以处理。但如果你有一个统一的编排层，让平台自己管理这些问题，整体的运维复杂度会下降不止一个量级。

1.2 K8s到底接管了什么

Kubernetes接手之后，你的角色会发生变化。以前你是直接面对容器、操作容器，现在你只需要告诉K8s“我期望系统最终是什么状态”。比如“我要三个副本的Nginx，每个需要128Mi内存，镜像带v2.0标签”，剩下的创建、调度、健康检查、重启，全部交给控制器完成。

这正是K8s最核心的思想——声明式管理。你描述期望状态，平台持续收敛到期望状态。某个Pod挂了，控制器会拉一个新的起来；流量大了，它会自动扩副本；节点宕机了，Pod会被驱逐并重建到健康节点上。整个过程如果不出意外，基本上不需要人干预。

这个概念可以用恒温器来类比。你设定好希望的温度，温度低了就加热，温度高了就降温，系统一直在循环检测和修正。K8s的控制循环就是这样运行的，它不是在“执行某一条命令”，而是在“不断纠正现实，让现实向期望状态靠拢”。

1.3 一句话理解K8s和Docker的关系

很多人喜欢把K8s和Docker对立起来，其实它们根本不是同一个层面的东西。Docker解决的是“怎么把应用打包和运行”，K8s解决的是“怎么把打包好的容器管好、调度好、治理好”。打个比方：Docker是集装箱，K8s是港口操作系统——它负责决定集装箱放哪个堆场、用哪台吊机、坏了的怎么换新、船来了先装哪些。

当前主流的容器环境里，K8s管理的是容器运行时，容器运行时往往是Docker或其他兼容方案。K8s并不绑定Docker，它依赖的是标准化的容器运行时接口。换句话说，K8s是站在容器之上的一层平台，而不是容器的替代品。搞清楚这一点，很多初学者的困惑会一下子少掉大半。

2. K8s架构：控制面与工作节点的“大脑”和“四肢”

先说说大框架。一个K8s集群由两部分组成：控制面和工作节点。控制面是大脑，负责决策；工作节点是四肢，真正运行容器。你平时敲的kubectl命令最终都会打到控制面，由它决定下一步怎么干活。

我刚开始学K8s的时候，总觉得组件列表太长、太散，记不住。后来发现，本质上就是四个控制面组件加三个节点组件，把它们类比成一家公司的管理架构，就很容易理解了。

2.1 控制面组件：平台的决策中心

控制面有四个核心组件。

第一个是API Server，它是所有请求的统一入口。相当于公司的前台和行政中心，所有kubectl命令都通过它进入集群，它会做身份认证、权限校验，然后把请求写入数据库。

第二个是etcd，这是K8s的“记忆”，一个分布式键值数据库。它保存着集群的全部状态信息：有哪些节点、在跑哪些Pod、每个资源的期望状态是什么。etcd是整个集群最重要的一块，因为数据一旦丢失，整个集群的管理信息就全乱了。

第三个是Controller Manager，可以理解成一群控制器的大管家。它负责维持集群的期望状态。比如Deployment控制器发现实际运行的Pod数量比期望少了，就会创建新的Pod；节点控制器发现某个工作节点失联了，就会把上面的Pod标记为需要重建。所有的自愈逻辑，都由这一群控制器在背后默默工作。

第四个是Scheduler，也就是调度器。它决定一个新Pod要放到哪台工作节点上。调度时会考虑资源剩余量、节点亲缘性、污点容忍等规则，尽量做到合理分配。如果集群里资源紧张，调度器会把Pod放在Pending状态等待。

2.2 工作节点组件：真正干活的执行层

工作节点上有三个关键角色。

kubelet是节点上与主控通信的代理，相当于节点上的车间主任。控制面说“这个节点要跑三个Pod”，kubelet就负责把对应的容器启动起来，持续上报状态。Pod的重建、销毁、健康探测，到最后都是通过kubelet来执行的。

kube-proxy负责节点上的网络规则和负载均衡。它让Service有了稳定的虚拟IP和端口，让访问流量能按规则分发到后端的Pod上。没有它，Service的“服务发现和负载均衡”能力就是一句空话。

容器运行时才是真正启动容器的软件。kubelet和容器运行时之间通过标准接口对话，所以K8s可以无缝替换底层运行时，而不影响上层逻辑。我实际排障中发现，很多线上怪问题都出在kubelet和容器运行时之间的沟通上，老版本之间的兼容性尤其容易踩坑。

2.3 声明式API：K8s区别于传统运维的灵魂

K8s与传统脚本自动化最大的区别，就是声明式API。

传统脚本是命令式的：先执行A，再执行B，顺序写死了。而K8s的yaml描述的是“最终状态”，不关心内部执行顺序。比如我写一个Deployment，只描述“我要3个Pod、镜像版本是v2、端口是8080”，至于这3个Pod怎么创建、创建顺序如何、失败怎么重试，都是平台内部的事。

声明式的设计带来的好处非常明显。状态永远是可控的，因为平台会不断把集群状态收敛到期望值；审计变得清晰，yaml就是一套“唯一真相”，任何版本变更都能用代码仓库来管理；运维也简单了，不需要为每个流程写堆脚本，改yaml就是一次变更。

说到底，K8s不是在教你写脚本，而是在帮你建立一套“声明状态、持续收敛”的运维心智。

3. 核心功能拆解：K8s家族的主要能力项

K8s功能很多，但真正日常用得上的，其实就那么几条。我按使用频率和重要程度，把它们分成六个方向来聊：服务发现与负载均衡、滚动更新与回滚、自动伸缩、存储编排、配置与密钥管理、故障自愈。

3.1 服务发现与负载均衡：门卫和总机干的活

容器IP是动态的，Pod一重建就变，这困扰过很多人。K8s解决的方式是引入Service这个概念。

Service是一个稳定的虚拟IP和端口，后面挂着一组Pod。当客户端访问Service的虚拟IP时，流量会被转发到后端Pod上。底层配合工作的，是kube-proxy和集群内的DNS组件。在DNS方面，K8s集群内每个Service会自动注册一个域名，Pod之间可以通过“服务名.命名空间”直接访问，不需要关心IP变化。这就像公司内部电话系统，你只需要拨分机号，不需要记住每个人的座机号码。

Ingress则是集群入口的总闸。Service解决的是集群内部的负载均衡，Ingress负责把集群外部进来的HTTP和HTTPS请求转发到Service。比如你有一个域名，希望按路径把 /api 转发到A服务，把 /web 转发到B服务，这就是Ingress的典型场景。对于很多小团队来说，Ingress也是对外暴露服务最主流的方式。

在我自己用过的方案里，Service和Ingress的组合基本包办了从集群外部到Pod内部的所有流量路径。只要把这两层搞清楚，网络问题的大半就解决了。

3.2 滚动更新与优雅回滚：发布不停机

版本升级是所有业务都跑不掉的事。如果粗暴地杀掉旧Pod再创建新Pod，必然有服务中断。K8s的Deployment默认采用滚动更新策略：先创建新版本Pod，等它就绪之后开始接流量，然后逐步销毁旧Pod。整个过程中新旧版本会短暂共存，但对用户来说是平滑的。

如果新版本上线后发现问题，一条回滚命令就能回到上一个版本。这个能力我实操中救过不少次火，线上发布翻车的时候，几乎是秒级回到旧版，不用像以前那样手动改配置、重启一整批进程。

滚动更新的行为可以用两个参数控制：最多可超出期望副本数的数量，以及最多允许不可用的旧副本数。比如允许多出一个Pod，同时允许一个旧Pod先停掉，这样更新期间服务容量基本不会掉。

3.3 自动伸缩：容量跟着流量走

在线业务最怕的就是流量突然变大。K8s的HPA可以根据CPU、内存或自定义指标动态调整Pod副本数。控制器会周期性采集指标，如果当前资源使用率超过设定阈值，就增加副本数；低于阈值，则减少副本数。

HPA的配置不复杂，但生产环境一定要设好上下限和冷却时间。我见过有团队把冷却时间设得太短，导致流量稍微抖动，副本数就来回震荡，反而给自己制造了新的故障。另一个经验是：基于CPU的伸缩适合大多数常规业务，但真正面向用户的业务，最好还是结合QPS、连接数这种业务指标做伸缩，响应会更贴近真实压力。

垂直方向的VPA调整的是单个Pod的资源规格而不是副本数，它适合固定副本数、但资源规格需要动态调整的场景。因为调资源规格通常要重启Pod，VPA在实际生产中的使用频率反而不如HPA。

3.4 存储编排：给容器接上持久化的“数据盘”

容器默认是无状态的，容器一重建，数据就没了。对于数据库、文件服务这类需要持久化的业务，K8s用PV和PVC来解决。

PV可以理解成一块已经准备好的存储资源，PVC则是业务对存储的“需求单”。开发只需要在yaml里声明“我要5Gi存储，读写权限是什么”，系统会自动分配对应的PV给Pod挂载。存储的底层介质可以是本地磁盘、网络存储或者云盘，只要实现了标准接口都能接入。

这个设计把存储的提供方和使用方解耦了。开发不需要关心底层存储在哪，运维只需要在集群里规划好PV池。结合StorageClass，还能做到动态创建存储，业务侧连PV都不用等了。

3.5 配置管理与密钥管理：ConfigMap和Secret

应用配置和敏感信息如果直接写进镜像，每改一次配置就要重新构建镜像，既低效又不安全。K8s提供两个资源来解决：ConfigMap存放非敏感配置，比如环境变量、配置文件内容；Secret存放敏感信息，比如数据库密码、Token。两者都可以被Pod以环境变量或文件卷的形式引用。

这里我必须提醒一个常见误区：Secret并不是绝对安全的。它默认只是Base64编码，不是加密。生产环境里的密钥，要么配合集群的加密能力，要么交给外部密钥管理服务，才能真正把敏感信息保护起来。我在不少分享里看到有人把数据库密码原样写在Secret的yaml里提交到代码仓库，这种做法实际上相当于把密钥明文暴露在了团队里。

3.6 故障自愈：把“救火”变成“自动巡检”

前面提到的声明式控制循环，最直接的收益就是故障自愈。Pod因为内存超限被杀死，控制器会自动拉一个新的；节点宕机，控制面检测到后会把Pod重新调度到其他节点；存储挂载失败，平台也会产生事件供排查。

但有一条原则希望大家记住：K8s的自愈解决的是“容量和可用性收敛”，业务层的数据异常、接口逻辑错误、外部依赖抖动，平台是一概不管的。所以K8s能帮你保证两个9的基础稳定性，但业务可观测性依然要靠监控系统来补。不要以为上了K8s就不再需要告警和监控了，恰恰相反，它让监控的价值更聚焦在业务层。

4. 上手实操：从最小集群到一次滚动更新

理论讲再多，不如动手跑一遍。这一节我带你从零部署一个最基本的应用，完整走一遍创建Deployment、暴露Service、滚动更新、扩容缩容的流程。

4.1 本地环境怎么搭

如果你想快速上手体验，最简单的方式是装一个单节点本地集群工具。装完之后，它会自动提供kubectl命令行和默认命名空间，足够跑大多数入门例子。具体安装步骤这里不展开，核心就两大步：

1. 装好需要的容器运行时；
2. 安装对应的集群工具并启动。

启动完成后，用下面的命令确认节点状态是Ready：

kubectl get nodes

如果这一步卡住，大概率是镜像拉取超时。换个网络环境，或者配置好镜像加速，基本都能解决。

4.2 第一个Deployment长什么样

假设我们要跑一个Nginx，创建Deployment的yaml如下：

apiVersion: apps/v1 kind: Deployment metadata: name: web-demo spec: replicas: 2 selector: matchLabels: app: web-demo template: metadata: labels: app: web-demo spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi

保存为web-demo.yaml后，执行：

kubectl apply -f web-demo.yaml

再看一下Pod状态：

kubectl get pods

等状态变成Running，第一个应用就在K8s里跑起来了。

这里要专门提醒：resources这一段别省。很多初学者觉得这是多余的配置，但如果不设置资源请求和上限，Pod在节点资源紧张时会成为被优先回收的对象，因为它在调度优先级里属于最低等级。生产环境务必给每个容器都配置requests和limits，前者是资源预留，后者是资源上限。

4.3 用Service把流量暴露出来

Pod起来了，但集群外部还访问不到它。创建一个Service：

apiVersion: v1 kind: Service metadata: name: web-demo-svc spec: selector: app: web-demo ports: - port: 80 targetPort: 80

执行：

kubectl apply -f service.yaml

然后用kubectl get svc查看Service，可以看到它分配了一个虚拟IP。Service会自动把流量均衡到标签匹配的Pod上，副本数变了也不用改Service。

如果只是想在本地测试，推荐用端口转发：

kubectl port-forward service/web-demo-svc 8080:80

浏览器打开localhost:8080，就能看到Nginx默认页面。这个命令在临时调试时特别好用，不用改任何集群配置。

4.4 体验一次滚动更新和回滚

把镜像从1.25换成1.26，执行：

kubectl set image deployment/web-demo nginx=nginx:1.26

再观察滚动过程：

kubectl rollout status deployment/web-demo

你会发现新Pod先创建，等它Ready之后再销毁旧Pod，整个过程中Service的IP一直保持不变。这个平滑升级的过程，正是生产发布不中断的关键。

如果新版本出问题，回滚命令一定要熟：

kubectl rollout undo deployment/web-demo

一条命令就能回到上一个版本。我建议在重大发布前提前演练一下回滚流程，真到线上救火阶段，手掌心出汗的时候，脑子里的命令必须是清晰的。

4.5 扩容到五个副本

业务压力变大，扩容是最常做的操作：

kubectl scale deployment/web-demo --replicas=5

几秒之内，新的Pod就会被调度并加入Service的负载均衡池。这个命令在日常运维中太常用了。不过从长期来看，我更建议用HPA来做按需伸缩，让平台根据指标自动决策，而不是靠人肉盯着流量手动扩容。

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

这部分是我最想分享的内容。K8s初学者最容易卡在几个问题上，我整理了一份高频问题列表，附上排查路径，希望能帮你少走弯路。

5.1 Pod一直Pending，究竟在等什么

Pending最常见的原因是资源不足或调度不出去。第一步永远是看事件：

kubectl describe pod <pod-name>

Events字段会直接告诉你答案。常见几种情况：

• 节点资源不足：输出会提示CPU或内存不够，要么加机器，要么调低requests。
• 调度失败：可能是因为节点被污点排除，或者亲和性规则不匹配。
• 节点状态NotReady：说明节点的kubelet和控制面失联了，要先恢复节点。

我遇到过一次比较隐蔽的问题，节点上有残留的旧Pod占着端口，新Pod一直端口冲突。这种问题靠describe看事件基本就能找到线索。

5.2 CrashLoopBackOff：容器反复启动失败

这个状态说明容器启动后崩溃了，然后被K8s反复重启。排查顺序我一般是这样：

1. 先看日志：kubectl logs 。
2. 如果日志没有明显异常，再看启动命令是否依赖了未注入的资源。
3. 然后检查资源配置，尤其是limits给得太低，容器一启动就被系统杀掉，describe里能看到被终止的原因。

我遇到最多的一个场景，是应用启动依赖某个环境变量，但环境变量没有在ConfigMap里注入，进程启动即退出。这种问题看一眼日志就能定位，方向和成本都很低。

5.3 服务访问不通，按链路逐层排查

Pod运行正常但服务访问不通，是另一个高频问题。我的排查路径固定如下：

1. 确认Pod本身正常：kubectl get pods，状态是否都是Running。
2. 确认Service后端正常：kubectl get endpoints ，看后端Pod地址是否都在。
3. 确认DNS解析正常：在任意Pod里执行nslookup服务名，看能否解析到虚拟IP。
4. 最后确认网络策略是否阻断了访问。

很多访问不通的问题，最后都出在endpoints为空这一步，而原因往往是Service的selector和Pod的label对不上。这个坑我踩过太多次，写selector的时候一定要反复核对标签，多一个空格或少一个标签，流量就全断了。

5.4 几个容易踩坑的配置细节

这里整理一个速查表，都是我实际翻车中总结出来的：

这里最后再说一遍Secret的问题。很多人觉得把密码放进Secret类型里就是安全了，这个看法必须要纠正。Secret只是在资源类型上做了区分，不是保险箱。真正重要的敏感信息，要么走外部密钥存储，要么在集群级别开启动态加密，否则仓库泄露等于密钥泄露。这块我见过太多团队踩坑，趁早重视起来，后面能少很多麻烦。

最后再分享一点体会。刚上手K8s的前几周，我也觉得它复杂，组件多、概念多、yaml又长。但坚持把一次滚动更新、一次服务暴露、一次故障排查完整走下来之后，我最大的收获不是记住了多少命令，而是理解了一种新的运维方式：你不再盯着进程看，而是盯着期望状态看。只要掌握了声明式和控制器循环这两个核心思想，后面那些功能都是在这套主框架上长出来的。踩过的坑确实不少，但每次排完一个故障，对这套系统的理解都会更深一层。