Kubernetes
Produção
DevOps
Containers
Infraestrutura

生产中的 Kubernetes:迁移之前没有人告诉您的事情

Kubernetes 解决了真正的规模问题,并创建了只有在迁移后才会发现的新问题。

生产中的 Kubernetes:迁移之前没有人告诉您的事情

大多数迁移到 [Kubernetes0] 的团队都确信他们正在解决基础设施问题。通常六个月后,他们会发现,他们已经将一组问题换成了一组更复杂的问题,并且他们认为已经消除的操作复杂性已经发生了变化。

Kubernetes 真正擅长的是什么

Kubernetes 的诞生是为了解决一个具体问题:大规模编排容器,并具有弹性和自动恢复能力。他在这方面做得很好。如果您的组织运营着数十种具有可变流量模式的服务,需要在不停机的情况下进行部署,并且拥有成熟的团队来运营该平台,那么 Kubernetes 可以提供真正的价值。

工作负载调度、资源管理、对渐进式部署策略的支持以及与[可观察性1]工具的集成确实很好。这些好处不是营销——它们存在、有效并且对生产产生影响。

问题不在于 Kubernetes 所承诺的。这就是他所要求的回报。

迁移后出现的复杂度

Kubernetes 中的网络并不是一个简单的设置。这是一个完整的抽象层——CNI 插件、服务网格、网络策略、内部 DNS、入口控制器——当出现问题时,您需要理解、维护和调试。有些东西会破裂。

存储是另一个被大多数人低估的摩擦点。持久卷、StorageClasses、访问模式、快照、备份 PVC:所有这些都需要仔细设计。 Kubernetes 上的有状态应用程序比传统虚拟机上运行的相同应用程序要复杂得多。

反过来,RBAC 是一种在迁移过程中没有人很好记录的东西,并且在几周内就变成了技术债务。为不同的命名空间、服务帐户和工作负载设置细粒度的权限需要遵守交付压力下的团队很少能够维持的纪律。

集群升级是另一章。 Kubernetes 具有积极的生命周期:版本很快就会过时,每次升级都需要对 API、清单、Helm 图表和运算符进行兼容性验证。如果忽略这一点几个月,您将在生产中运行不受支持的版本。

SRE 悖论

在没有充分规划的情况下采用 Kubernetes 的团队有一个众所周知的讽刺:您需要经验丰富的可靠性工程师来操作该工具,本应减少手动操作的需要。 Kubernetes 是为 Google 规模而构建的。他继承了这一遗产。

小团队经常发现他们花在操作平台上的时间多于开发产品的时间。每个事件都涉及来自多个 Pod 的日志、调度事件的跟踪、资源限制分析和网络调试,这些只有对那些深入了解内部抽象的人才有意义。

这不是设计缺陷。这是平台通用性的直接结果。 Kubernetes 以复杂的方式解决复杂的问题——而且这种复杂性并不会因为容器的运行而消失。

当托管 Kubernetes 改变计算时

EKS、GKE 和 AKS 并不能消除操作复杂性,但它们确实将其中一些复杂性分发给云提供商。控制平面——etcd、API 服务器、调度程序、控制器管理器——是提供商的责任。版本升级变得不那么痛苦。与提供商的身份、存储和网络服务的集成是预先配置的。

对于已经在特定云提供商内运营的团队来说,托管 Kubernetes 显着降低了进入成本。它不是零,但比运行自我管理的集群要少得多。

当您考虑锁定时,计算结果会再次发生变化。例如,GKE Autopilot 抽象得太多,以至于您失去了对调度和节点配置的控制。对于某些球队来说这是一笔有效的交易,而对于其他球队来说则是不可接受的。选择取决于您想要在哪里拥有主权以及在哪里接受授权。

当更简单的策略就是明智的决定时

Kubernetes 并不是适合所有工作负载的正确答案。如果您运营一个结构良好且流量可预测的 [monolith2],那么配置良好且具有自动化部署流程的 EC2 实例可能会更可靠、更便宜且更易于操作。

Fly.io、Railway、Render 甚至 AWS App Runner 等工具可提供 Kubernetes 的大部分运营优势(零停机、自动扩展、回滚),而无需专家维护的抽象层。

团队在迁移之前很少问的问题很简单:Kubernetes 将解决哪些当前基础设施无法解决的具体问题?如果答案很模糊——“可扩展性”、“现代化”、“更好的容器管理”——那么运营投资可能是不合理的。

当您拥有具有独立部署周期的多个服务、需要工作负载之间的隔离、高度可变的流量模式以及具有实际能力操作平台的团队时,Kubernetes 就有意义。在一个组织拥有数十名工程师和多年的容器成熟度之前,这四个标准很少一起出现。

在错误的时间做出的决定

迁移到 Kubernetes 几乎总是发生在准备最少的时候。团队正在成长,规模扩张的压力已经出现,有人在 KubeCon 上看到了一次演讲,并且在团队有足够的经验来了解他们正在承担的任务之前就做出了决定。

典型的结果是:六个月的努力进行迁移,然后是另外六个月的努力稳定环境。促使迁移的问题——脆弱的部署、缺乏隔离、难以扩展——仍然存在,现在需要进行额外的诊断。

这并不意味着迁移是错误的。这意味着她在执行之前需要更多的规划、现实的时间表和培训。 Kubernetes 是一个强大的平台。但强大和简单很少同时存在——那些不理解这种区别的人会在做出决定后才知道。

另请阅读

  • [自主计算:当系统在你注意到错误之前自行纠正时3
  • [用于生产的 Docker:构建轻量且安全的镜像4
  • 【能源:无人问津的计算路线瓶颈5
  • [边缘计算架构:分布式处理策略6
  • [HashiCorp Vault:应用程序中的安全秘密管理7
  • [量子传感器和网络:首先出现的应用8