Kubernetes（K8s）已成为主导的容器编排平台，但它也是行业中过度部署最多的工具之一。许多团队在用更简单的基础设施可以更好地服务的工作负载上运行Kubernetes。本文介绍了Kubernetes实际上做什么、什么时候真正有帮助，以及什么时候更简单的替代方案是更好的选择。
Kubernetes做什么
Kubernetes是一个用于自动化容器化应用程序的部署、扩展和管理的系统。它解决的核心问题：你有许多容器（Docker容器）运行你的应用程序，你需要：将它们放在正确的机器上（调度）；如果崩溃则重启它们（健康检查和自愈）；将流量路由到正确的实例（服务发现和负载均衡）；在流量激增时向上扩展，在安静时段向下扩展（自动扩展）；在不停机的情况下推出新版本（滚动部署）；管理密钥和配置（ConfigMaps和Secrets）。关键抽象：Pod：最小的可部署单元——一个或多个始终一起调度并共享网络命名空间的容器。Deployment：管理一组复制的Pod，处理滚动更新和回滚。Service：一个稳定的网络端点，将流量路由到适当的Pod，即使Pod来来去去。Ingress：将HTTP/HTTPS路由暴露到集群外部；由Ingress Controller（nginx、traefik或云特定的）管理。ConfigMap和Secret：注入到Pod中的配置数据和敏感数据（密码、API密钥）。PersistentVolume：持续超过Pod生命周期的存储。HorizontalPodAutoscaler（HPA）：根据CPU使用、内存或自定义指标自动扩展Pod副本数量。控制平面：集群由控制平面（API服务器、etcd数据库、控制器管理器、调度程序）管理，持续工作使集群的实际状态与你在YAML清单中声明的期望状态匹配。这种声明式模型——你声明你想要什么，Kubernetes弄清楚如何实现它——是其核心设计。
Kubernetes真正有帮助的时候
当你有许多微服务（10+）需要独立部署、扩展和更新时，Kubernetes增加了显著价值；当你需要同时在多个服务中进行零停机部署时；当你有需要自动扩展的可变流量模式时（例如，夜间批处理作业、工作时间内的流量高峰）；当你需要跨多个云提供商或本地+云运行时；当你有足够大的团队来证明运营开销合理时（粗略阈值：当你至少有2到3人可以管理它时，Kubernetes才有意义）。运营开销：Kubernetes有显著的运营复杂性——版本升级、节点维护、网络配置、RBAC（基于角色的访问控制）、存储配置、监控设置、日志设置。托管Kubernetes服务（Amazon EKS、Google GKE、Azure AKS）删除了部分但不是全部开销。可能不有帮助的时候：只有几个容器的单一应用程序；服务少于10个的初创公司；每个人都已经伸展过薄的团队；任何初级开发人员需要在凌晨3点部署热修复且Kubernetes路径增加不必要风险的情况。替代方案：对于大多数中小型应用程序——带Compose的单个Docker主机、托管容器服务（AWS ECS、Google Cloud Run、Fly.io）或传统PaaS（Heroku、Render、Railway）在运营上更简单，通常开发速度也更快。Cloud Run特别值得考虑：它可以缩减至零，几乎没有运营开销，并且能很好地处理大多数无状态工作负载。
