Kubernetes 实用概览

如果你构建过一个在单台服务器上运行良好、却在真实流量下崩溃的 Web 应用，那么你已经理解了 Kubernetes 要解决的问题。在多台机器上大规模管理容器——实现零停机部署和自动恢复——确实非常困难。Kubernetes（K8s）正是业界公认用来应对这一挑战的工具。

本文将为你提供一份清晰的 Kubernetes 概览：它是什么、它的架构如何运作，以及它的核心组件如何协同工作来运行现代 Web 应用。

---

什么是 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 控制器。

ConfigMap 和 Secret

将配置从容器镜像中剥离出来。ConfigMap 存储非敏感设置（API URL、特性开关）。Secret 存储敏感数据（令牌、密码）。两者都可以作为环境变量注入到 Pod 中，或挂载为文件。

---

一切是如何串联起来的

当你在 Kubernetes 上部署一个全栈应用时，流程大致如下：

1. 你编写一个 Deployment YAML，描述应用容器和副本数量。
2. Scheduler 将 Pod 调度到具有可用容量的工作节点上。
3. Service 为这些 Pod 提供一个稳定的内部地址。
4. Ingress 或 Gateway 将外部 HTTP 流量路由到该 Service。
5. 如果某个 Pod 死掉，ReplicaSet 会替换它。如果流量激增，你可以扩展 Deployment。

---

结语

Kubernetes 架构基础归结为：控制平面做决策，工作节点执行任务，而 Pod、Deployment、Service 等抽象提供了一种一致的方式来描述和管理你的应用。具体到 Web 应用，理解 Deployment、Service 和路由机制就能让你掌握大部分要点。其余部分——存储、命名空间、资源限制——都是在你打好基础之后逐层叠加的内容。

常见问题

小型 Web 应用需要使用 Kubernetes 吗？

大概率不需要。Kubernetes 会带来实实在在的运维开销，包括集群维护、YAML 配置以及更陡峭的学习曲线。对于小型项目或早期阶段的应用，使用 Vercel、Render 这类托管平台，或在单台 VPS 上使用 Docker Compose 通常更快、更便宜。当你需要多服务编排、可预测的扩缩容，或跨环境的严格可用性保证时，再选择 Kubernetes。

Docker 和 Kubernetes 有什么区别？

Docker 是用于构建、打包和运行容器的工具链。它在单台主机上构建和运行单个容器。Kubernetes 是一个编排器，跨多台机器管理大量容器，处理调度、扩缩容、网络和恢复。它们是互补的工具。Docker 创建容器，Kubernetes 在集群中大规模运行它们。

路由应使用 Ingress 还是 Gateway API？

如果你正在启动一个新项目，Gateway API 是更好的长期选择。它提供了更具表达力的模型、基础设施团队与应用团队之间更清晰的职责分离，并且是生态发展的方向。Ingress 仍被广泛支持，对现有部署来说没问题，但新集群应该优先评估 Gateway API，前提是你选择的控制器支持它。

如何在 Kubernetes 中存储 API 密钥等敏感数据？

敏感数据应使用 Secret 而不是 ConfigMap。请记住，base64 编码并不是加密，因此需要在 etcd 中启用静态加密，并通过 RBAC 限制访问权限。对于生产级别的密钥管理，可集成 HashiCorp Vault、AWS Secrets Manager 或 External Secrets Operator 等外部工具，将凭证安全地注入到 Pod 中。