Kubernetes 实用概览
如果你构建过一个在单台服务器上运行良好、却在真实流量下崩溃的 Web 应用，那么你已经理解了 Kubernetes 要解决的问题。在多台机器上大规模管理容器——实现零停机部署和自动恢复——确实非常困难。Kubernetes（K8s）正是业界公认用来应对这一挑战的工具。
本文将为你提供一份清晰的 Kubernetes 概览：它是什么、它的架构如何运作，以及它的核心组件如何协同工作来运行现代 Web 应用。
核心要点
- Kubernetes 是事实上的容器编排平台，能够在机器集群中自动完成调度、扩缩容、自愈和流量路由。
- 集群分为两层：负责决策的控制平面（API Server、Scheduler、Controller Manager、etcd）和运行工作负载的工作节点（Kubelet、容器运行时、kube-proxy）。
- Pod 是最小的可部署单元，但通常你会通过 Deployment 和 ReplicaSet 来管理它们，由它们处理副本和滚动更新。
- Service 为短暂存在的 Pod 提供稳定的网络端点，而 Ingress 或更新的 Gateway API 则负责外部 HTTP/HTTPS 路由。
- ConfigMap 和 Secret 将配置和敏感数据从容器镜像中剥离出来，使部署更具可移植性和安全性。
什么是 Kubernetes？为什么会有它？
Kubernetes 是一个开源的容器编排平台，最初由 Google 开发，并于 2015 年捐赠给云原生计算基金会（CNCF）。它已被广泛采用，被视为容器编排的标准平台。
简而言之：Docker 将你的应用打包成容器，Kubernetes 则在机器集群中运行和管理这些容器，自动处理调度、扩缩容、自愈和流量路由。
Kubernetes 架构基础：集群是如何组织的
一个 Kubernetes 集群包含两个截然不同的层级。
控制平面（大脑）
控制平面为整个集群做出决策。它的关键组件包括：
- API Server — 所有命令的统一入口。每一次
kubectl调用都会到达这里。 - Scheduler — 根据可用资源决定由哪个工作节点来运行某个 Pod。
- Controller Manager — 持续将集群的实际状态与你期望的状态进行调谐。
- etcd — 一个分布式键值存储，保存所有集群配置和状态。它是唯一可信的数据源。
工作节点（应用真正运行的地方）
工作节点运行你的容器化工作负载。每个节点包含：
- Kubelet — 节点代理，确保容器按规范运行。
- 容器运行时 — 拉取镜像并运行容器（现代集群中通常是 containerd）。
- Kube-proxy — 管理网络规则，使 Pod 之间以及 Pod 与 Service 之间能够通信。
面向 Web 应用的 Kubernetes 核心概念
Pod
Pod 是 Kubernetes 中最小的可部署单元。它包装了一个或多个共享网络和存储上下文的容器。你很少直接创建 Pod，因为工作负载控制器会替你管理它们。
Deployment 和 ReplicaSet
Deployment 是你描述期望运行内容的方式：使用哪个容器镜像、需要多少副本，以及更新应如何推出。它在底层管理一个 ReplicaSet，确保始终有正确数量的 Pod 副本在运行。如果某个 Pod 崩溃，ReplicaSet 会自动替换它。
对于一个前端应用，Deployment 让你可以说”运行 3 个我的 React 应用副本”，而 Kubernetes 会处理其余一切，包括零停机的滚动更新。
Service
Pod 是短暂的，它们的 IP 地址会发生变化。Service 为你的 Pod 提供一个稳定的网络端点。主要类型如下：
| 类型 | 使用场景 |
|---|---|
ClusterIP | 服务之间的内部通信（默认类型） |
NodePort | 在静态端口上暴露服务以供测试 |
LoadBalancer | 由云厂商管理的外部访问（生产环境最常用） |
Ingress 和 Gateway API
对于 HTTP/HTTPS 路由——例如将 /api 流量发送到一个服务，而将 / 发送到另一个——你可以使用 Ingress 或更新的 Gateway API。Gateway API 是生态当前的发展方向，提供了更高的灵活性和基于角色的配置方式。如果你是从零开始，值得优先考虑 Gateway API 而非传统的 Ingress 控制器。
Discover how at OpenReplay.com.
ConfigMap 和 Secret
将配置从容器镜像中剥离出来。ConfigMap 存储非敏感设置（API URL、特性开关）。Secret 存储敏感数据（令牌、密码）。两者都可以作为环境变量注入到 Pod 中，或挂载为文件。
一切是如何串联起来的
当你在 Kubernetes 上部署一个全栈应用时，流程大致如下：
- 你编写一个 Deployment YAML，描述应用容器和副本数量。
- Scheduler 将 Pod 调度到具有可用容量的工作节点上。
- Service 为这些 Pod 提供一个稳定的内部地址。
- Ingress 或 Gateway 将外部 HTTP 流量路由到该 Service。
- 如果某个 Pod 死掉，ReplicaSet 会替换它。如果流量激增，你可以扩展 Deployment。
结语
Kubernetes 架构基础归结为：控制平面做决策，工作节点执行任务，而 Pod、Deployment、Service 等抽象提供了一种一致的方式来描述和管理你的应用。具体到 Web 应用，理解 Deployment、Service 和路由机制就能让你掌握大部分要点。其余部分——存储、命名空间、资源限制——都是在你打好基础之后逐层叠加的内容。
常见问题
大概率不需要。Kubernetes 会带来实实在在的运维开销，包括集群维护、YAML 配置以及更陡峭的学习曲线。对于小型项目或早期阶段的应用，使用 Vercel、Render 这类托管平台，或在单台 VPS 上使用 Docker Compose 通常更快、更便宜。当你需要多服务编排、可预测的扩缩容，或跨环境的严格可用性保证时，再选择 Kubernetes。
Docker 是用于构建、打包和运行容器的工具链。它在单台主机上构建和运行单个容器。Kubernetes 是一个编排器，跨多台机器管理大量容器，处理调度、扩缩容、网络和恢复。它们是互补的工具。Docker 创建容器，Kubernetes 在集群中大规模运行它们。
如果你正在启动一个新项目，Gateway API 是更好的长期选择。它提供了更具表达力的模型、基础设施团队与应用团队之间更清晰的职责分离，并且是生态发展的方向。Ingress 仍被广泛支持，对现有部署来说没问题，但新集群应该优先评估 Gateway API，前提是你选择的控制器支持它。
敏感数据应使用 Secret 而不是 ConfigMap。请记住，base64 编码并不是加密，因此需要在 etcd 中启用静态加密，并通过 RBAC 限制访问权限。对于生产级别的密钥管理，可集成 HashiCorp Vault、AWS Secrets Manager 或 External Secrets Operator 等外部工具，将凭证安全地注入到 Pod 中。
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
