Kubernetes 与虚假的运营成熟感

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文。

介绍

Kubernetes 几乎从不因真实需求而进入小型项目。它在系统规模扩大、出现扩展需求的讨论，或有人觉得“已经是时候”使用更可靠的东西时才会出现。问题是，Kubernetes 常被视为技术成熟度的标志，但实际上它只是把问题出现的节点向后移动。

在 Kubernetes 上运行应用本身并不会让系统更可靠。它只会创建一个环境，使得糟糕的决策能够存活更久，而好的决策则变成必须遵循的。两种情形的差别通常要等到第一次严重事故发生后才会显现。

集群并不能解决应用问题

最初被打破的期望之一是 Kubernetes “照顾”应用的想法。它负责 pod、容器、节点和调度。其余的仍然是团队的责任。如果应用不能很好地处理重启，不能在不丢失状态的情况下上下线，或者没有暴露明确的健康信号，集群是无法弥补的。它只是更高效地重新启动出现故障的组件。

在生产环境中，这会形成一种奇怪的模式：从 Kubernetes 的角度看，一切都很健康，但系统并未提供任何价值。Pod 正在运行，副本保持在线，自动伸缩正常工作，但用户仍然感到慢或不一致。集群是好的，应用不是。

这种“基础设施健康”和“产品健康”之间的区分，常常让来自更简单环境的人感到震惊，因为在那些环境中，基础设施故障和应用故障几乎是同一回事。

配置变成代码… 以及债务

Kubernetes 鼓励把所有东西都当作代码来处理，这既是正确的想法，又潜藏危险。正确之处在于它提供了可追溯性；危险之处在于它让静默的复杂性容易堆积。YAML 文件会不断增长、重复，从一个项目复制到另一个项目，结果很快就没有人能准确理解某些选项为何存在。

大多数生产环境中的集群都承载着无人敢动的决策。requests 与 limits 被设定为“因为一直是这么做的”，探针（probes）被调校以规避旧有问题，注解（annotations）继承自某个没人记得是谁写的 chart。所有东西都能正常运行，直到某一天它不再工作，这时要弄清系统的工作原理就需要进行考古。

Kubernetes 本身并不会产生这些债务，但它为这些债务提供了一个舒适的藏身之所。

扩容并不等同于承载负载

另一个常见的混淆点是把自动扩容与实际处理流量增长的能力等同起来。集群可以快速扩容，但应用可能跟不上。外部连接、冷缓存、慢依赖以及繁重的初始化并不会因为 pod 增多而消失。

在很多情况下，HPA 只是把问题分散开来。更多实例并行地做同样的错误，进一步压垮数据库、队列或外部 API。系统“扩容”了，但行为以更不可预测的方式退化。

这时就会清楚地看到，Kubernetes 扩容的是基础设施，而不是架构。如果设计本身不能支撑负载，集群只能让你更快地达到极限。

可观测性成为前提，而非奢侈

在较小的环境中，使用基础日志和一些直觉仍能生存。 在 Kubernetes 中，这种情况维持不了太久。 Pod 的短暂特性以及集群的动态性，使得在没有清晰明确定义的信号下，几乎不可能理解事故。

没有可靠的指标，任何调优都只能靠试错。没有 traces，很难知道时间花在哪里。没有结构化日志，排查问题就要拼凑已经不存在的信息碎片。Kubernetes 加快了变更的节奏，这让缺乏可观测性代价更高。

看到团队熟练使用 kubectl，却对应用的真实行为一无所知，这并不罕见。

运营 Kubernetes 是一项持续的工作

也有人期望 Kubernetes 是一种可以“配置后忘记”的东西。但实际上，它需要持续的维护。版本会变化，API 被弃用，细微的行为在升级之间会改变。即使应用没有变化，集群也会老化。

忽视这一点就是在积累风险。许多严重的问题并非源于新 bug，而是由于不同组件版本以不同速度演进而产生的静默不兼容。Kubernetes 不是静态产品，把它当作静态产品来对待往往会在以后付出高昂代价。

结论

Kubernetes 强大，但不宽容。它奖励设计良好的系统，并快速暴露依赖运气或走运的系统。使用它并不会自动让团队更成熟，但需要成熟度来防止将灵活性变成受控的混乱。

当被充分理解时，Kubernetes 成为增长的坚实基础。当被用作专业化的捷径时，它只会把相同的问题搬到另一个舞台——现在有了更多抽象、更多层次，且即兴发挥的余地更小。