您不必害怕 Kubernetes 的理由

Digital creative of a browser on the internet

在 1990 年代末和 2000 年代初，在大型 Web 资产公司工作很有趣。我的经历带我回到了 American Greetings Interactive，在情人节那天，我们拥有互联网上排名前 10 的网站之一（按网络流量衡量）。我们为 AmericanGreetings.com、BlueMountain.com 和其他网站提供电子贺卡，并为 MSN 和 AOL 等合作伙伴提供电子贺卡。该组织的老员工深情地回忆起与 Hallmark 等其他电子贺卡网站进行史诗般战斗的传奇故事。顺便说一句，我还为 Holly Hobbie、Care Bears 和 Strawberry Shortcake 运营大型 Web 资产。

我记得就像昨天一样，我们第一次遇到真正的问题。通常，我们有大约 200Mbps 的流量从我们的前门（路由器、防火墙和负载均衡器）进入。但是，突然间，莫名其妙地，多路由器流量图形器 (MRTG) 图表在几分钟内飙升至 2Gbps。我到处跑，疯狂地奔波。我了解我们的整个技术堆栈，从路由器、交换机、防火墙和负载均衡器，到 Linux/Apache Web 服务器，再到我们的 Python 堆栈（FastCGI 的元版本）和网络文件系统 (NFS) 服务器。我知道所有配置文件在哪里，我可以访问所有管理界面，我是一位经验丰富、身经百战的系统管理员，拥有多年解决复杂问题的经验。

但是，我弄不清楚发生了什么...

当您在数千台 Linux 服务器上疯狂地输入命令时，五分钟感觉就像永恒。我知道网站随时都会崩溃，因为当一个千节点集群被划分为更小的集群时，很容易将其压垮。

我迅速跑到我老板的办公桌旁，解释了情况。他几乎没有从电子邮件中抬起头，这让我很沮丧。他抬头看了一眼，笑了笑，说：“是的，营销部门可能投放了广告活动。这种情况有时会发生。”他告诉我设置一个应用程序中的特殊标志，将流量卸载到 Akamai。我跑回我的办公桌，在数千台 Web 服务器上设置了该标志，几分钟之内，网站恢复正常。灾难避免了。

我可以分享 50 多个与此类似的故事，但您好奇的心可能在问：“这要走向何方？”

重点是，我们遇到了业务问题。当技术问题阻止您开展业务时，技术问题就会变成业务问题。换句话说，如果您的网站无法访问，您就无法处理客户交易。

那么，这一切与 Kubernetes 有什么关系呢？一切。世界已经改变了。在 1990 年代末和 2000 年代初，只有大型 Web 资产公司才遇到大型、Web 规模的问题。现在，随着微服务和数字化转型，每个企业都面临着大型、Web 规模的问题——很可能是多个大型、Web 规模的问题。

您的企业需要能够管理一个复杂的 Web 规模资产，其中包含许多不同的、通常很复杂的服务，这些服务由许多不同的人构建。您的 Web 资产需要动态处理流量，并且需要安全。这些资产需要在所有层（从基础设施到应用层）都由 API 驱动。

进入 Kubernetes

Kubernetes 并不复杂；您的问题是业务问题。当您想要在生产环境中运行应用程序时，需要达到最低程度的复杂性才能满足性能（扩展、抖动等）和安全要求。诸如高可用性 (HA)、容量要求 (N+1、N+2、N+100) 以及最终一致的数据技术都成为必需品。这些是每个已经完成数字化转型的公司的生产要求，而不仅仅是 Google、Facebook 和 Twitter 等大型 Web 资产公司。

在旧世界，我在 American Greetings 工作时，每次我们上线一项新服务，看起来都像这样。所有这些都由 Web 运维团队处理，没有一项被卸载到使用工单系统等的其他团队。这是 DevOps 在 DevOps 出现之前

配置 DNS（通常是内部服务层和面向外部的公共服务）
配置负载均衡器（通常是内部服务和面向公众的服务）
配置对文件的共享访问（大型 NFS 服务器、集群文件系统等）
配置集群软件（数据库、服务层等）
配置 Web 服务器集群（可能是 10 台或 50 台服务器）

大部分工作都通过配置管理实现自动化，但配置仍然很复杂，因为这些系统和服务中的每一个都有不同的配置文件，并且格式完全不同。我们调查了像 Augeas 这样的工具来简化这一点，但确定尝试使用翻译器来规范化一堆不同的配置文件是一种反模式。

今天，使用 Kubernetes，上线一项新服务基本上看起来像

配置 Kubernetes YAML/JSON。
将其提交到 Kubernetes API (kubectl create -f service.yaml)。

Kubernetes 大大简化了服务的上线和管理。服务所有者（无论是系统管理员、开发人员还是架构师）都可以创建 Kubernetes 格式的 YAML/JSON 文件。借助 Kubernetes，每个系统和每个用户都说同一种语言。所有用户都可以将这些文件提交到同一个 Git 仓库中，从而实现 GitOps。

此外，可以弃用和删除服务。从历史上看，删除 DNS 条目、负载均衡器条目、Web 服务器配置等非常可怕，因为您几乎肯定会破坏某些东西。借助 Kubernetes，一切都已命名空间化，因此可以使用单个命令删除整个服务。您可以更加确信删除您的服务不会破坏基础设施环境，尽管您仍然需要确保其他应用程序不使用它（微服务和函数即服务 [FaaS] 的缺点）。

构建、管理和使用 Kubernetes

太多人专注于构建和管理 Kubernetes，而不是使用它（请参阅 Kubernetes 是一辆 自卸卡车）。

在单节点上构建一个简单的 Kubernetes 环境并不比安装 LAMP 堆栈复杂多少，但我们却无休止地争论构建与购买的问题。困难的不是 Kubernetes；而是在大规模、高可用性地运行应用程序。构建复杂、高可用的 Kubernetes 集群很困难，因为构建任何这种规模的集群都很困难。这需要规划和大量软件。构建一辆简单的自卸卡车并不那么复杂，但构建一辆可以运载 10 吨泥土并在 200 英里/小时的速度下操控性良好的自卸卡车就很复杂了。

管理 Kubernetes 可能很复杂，因为管理大型 Web 规模集群可能很复杂。有时管理这种基础设施是有意义的；有时则没有意义。由于 Kubernetes 是一个社区驱动的开源项目，因此它使行业能够以多种不同的方式对其进行管理。供应商可以销售托管版本，而用户可以决定自己管理它（如果他们需要的话）。（但您应该质疑您是否真的需要这样做。）

使用 Kubernetes 是有史以来运行大型 Web 资产的最简单方法。Kubernetes 正在普及运行一组大型、复杂 Web 服务的能力——就像 Linux 对 Web 1.0 所做的那样。

由于时间和金钱是零和博弈，我建议专注于使用 Kubernetes。将您非常有限的时间和金钱花在掌握 Kubernetes 原语或处理存活和就绪探针的最佳方法上（另一个例子表明大型复杂服务很难）。不要专注于构建和管理 Kubernetes。许多供应商可以帮助您解决这个问题。

结论

我记得排除无数个像我在本文开头描述的那样的问题——当时的 Linux 内核中的 NFS、我们自己开发的 CFEngine、仅在某些 Web 服务器上出现的重定向问题等等。开发人员根本无法帮助我排除这些问题中的任何一个。事实上，除非开发人员拥有高级系统管理员的技能，否则他们根本无法进入系统并作为第二双眼睛提供帮助。没有带有图形或“可观察性”的控制台——可观察性存在于我和其他系统管理员的大脑中。今天，有了 Kubernetes、Prometheus、Grafana 等，这一切都改变了。

重点是