Airbnb 如何简化 1000 多位工程师的 Kubernetes 工作流程？

Melanie Cebula 谈到，Airbnb 采用了内部工具和策略以支持 1000 多位工程师同时为 Kubernetes 配置和部署 250 多个关键服务。一个关键的推动因素是，使用标准化的环境和命名空间（以及尽可能的自动验证）从更高级的原语中抽象和生成 Kubernetes 配置层。

Airbnb 的架构工程师 Melanie Cebula 在伦敦 QCon 大会上做了演讲，她谈到 Airbnb 采用了内部工具和策略以支持 1000 多位工程师（以每天平均大约 500 个部署的频率）并发配置和部署 250 多个关键服务给 Kubernetes。一个关键的推动因素是，使用标准化的环境和命名空间（以及尽可能的自动验证）从更高级的原语中抽象和生成 Kubernetes 配置层。

kube-gen 是 Airbnb 的内部工具，其可以获取服务的参数（在单个 YAML 文件中定义），并通过添加所有必要的样板配置来生成完整的 Kubernetes 服务配置。过去，Airbnb 使用文件继承机制来进行配置（就像 Chef cookbooks），这导致了级联基础设施故障影响。因此，目标之一是，通过使用 YAML 模板进行服务配置来减少潜在错误的影响范围。

kube-gen 的另一个主要目标是，抽象出 Kubernetes 配置和工具复杂性，以便使工程团队能够保留其服务部署的所有权，并具备必要的隔离级别（部分基于标准化环境名字，由自动生成的命名空间保证），但是没有过长的学习曲线。尽管 kube-gen 因为解决的是 Airbnb 的具体情况而还未公开，但 Cebula 指出有一些开源替代品，如 helm（包管理），kustomize（通过文件继承配置）和 Kapitan（通过模板配置）。

图：在自定义 YAML 中，服务配置文件被转换成 Kubernetes 所需的配置文件（每个环境在自定义 YAML 中定义一个配置文件集），然后应用于 Kubernetes 集群（来源：Airbnb 的 Melanie Cebula）

促进同质并易于发展的服务配置的进一步策略包括：在一个命令中创建一个新的服务框架存储库，在构建和部署配置文件时验证（不仅包括语法，还有所提供的值中的已知问题，如：无效的项目名字或所有者），并且对（生成的）服务配置进行版本控制。

一个新创建的服务 git 存储库包括应用程序和基础设施样板文件（包括 CI/CD），自动填充合理的默认值和良好实践（如默认的自动扩展或文档生成）。版本控制服务配置（在 YAML 文件中有个特定字段）允许标记有问题的版本（因而它们不会被重新部署），这些可以是 kube-gen 自身的问题或特定于服务的问题，也可以是在不同的渠道上分发的不同的版本（例如，稳定版或测试版）。

图：Airbnb 服务配置 YAML 文件示例，包括一个版本字段（来源：Airbnb 的 Melanie Cebula）

k 是 Airbnb 的另一个内部工具。k 主要是 kubectl 的自用包装器，它还过滤掉了 kubectl 的一些冗长输出。k 还支持一些额外功能，像包装之前提到的 kube-gen 工具，构建/推送 Docker 镜像。

该工具的目标是自动化通用工作流，从而通过抽象一些 Kubernetes 工具的复杂性来简化和标准化工程工作。但是，它还让开发人员和基础设施工程师们使用一种共同的语言，并使用相同工具增强协作，Cebula 如此说道。

一个典型的工作流程从 k generate 生成 Kubernetes 文件开始，然后，k build 来构建 Docker 镜像并推送到私有仓库，最后，k deploy 来创建 Kubernetes 命名空间并应用 Kubernetes 文件，等待最终部署状态。无论哪种环境（即本地计算机、CI、阶段或生产），服务的构建和部署都是采用同样的方式。它还可以运行 k diagnose，其依赖于一些 Airbnb 创建的插件：kubectl diagnose 和 kubectl pod events。目的是，在调试部署问题时，自动执行常见的手动操作步骤：收集未满容器上的信息，查找相关的 pod events 并针对这些容器获取日志。

最后，Cebula 提到了 Airbnb 的 Kubernetes 采用过程中一些仍然存在的挑战，特别是与数千现有服务的迁移相关的，这些服务要求更好的多集群支持和扩展（一些服务要用多达数百个副本），处理更多具有高内存需求的有状态服务，以及用自定义控制器将所有配置移至 GitOps 工作流模型。

阅读英文原文：

https://www.infoq.com/news/2019/03/airbnb-kubernetes-workflow