Anthropic运维工程师的IT基础设施总结清单（下）

Karpenter 开源地址： github.com/kubernetes-…

本文由 Anthropic 工程师 Jack Lindamood 撰写，分享了他之前在一家初创公司中负责IT基础设施的经验，包括从中吸取的教训和一些最佳实践。
文章分为上下两篇，本文为下篇。

在上一篇文章中，介绍了 IT 基础设施团队在云、协作流程以及 SaaS 产品做出的决策以及从中吸取的经验教训。本篇将介绍基础设施技术栈的选择。

01/软件

通过 Diff 进行 Schema 迁移

推荐…吧

无论采用哪种方式，Schema 管理都是一项难题，主要因为它带来的风险。数据非常重要，一个错误的 Schema 迁移可能会导致数据被删除。在所有令人担忧的解决方案中，我对将整个 Schema 保存到 Git 中，然后使用工具生成 SQL 来同步数据库和 Schema 的做法非常满意。

Karpenter 用于节点管理

推荐

如果你正在使用 EKS（而且还没有完全转向 Fargate），那么你应该使用 Karpenter。毫不犹豫，百分之百推荐。我们曾使用过其他自动扩展工具，包括默认的 Kubernetes 集群扩展器（Cluster Autoscaler）和 SpotInst。在这些工具中，Karpenter 无疑是最可靠且最具成本效益的。

开发服务器使用 Ubuntu

推荐

起初，我尝试让开发服务器使用与 Kubernetes 节点相同的基础操作系统，希望能让开发环境更贴近生产环境。但回头来看，这种做法付出与收益不成正比。最终，我们选择了 Ubuntu 作为开发服务器的操作系统。这一选择非常明智，因为 Ubuntu 不仅支持广泛，还为我们提供了开发过程中所需的大部分软件包，满足需求的同时也提升了效率。

AppSmith

推荐

我们经常需要为内部工程师自动化一些流程，比如重启、发布、诊断等。虽然通过 API 来解决这些问题相对简单，但调试每位用户在其 CLI、操作系统或依赖环境上的具体安装问题却颇为麻烦。因此，能够通过一个简单的脚本为工程师提供一个简单的 UI 界面来交互是非常实用的。

我们自托管了 AppSmith，总体来说它运行得还不错。当然，它有一些需要改进的地方，但对于“免费”的价格来说已经足够了。起初，我也曾考虑过更深入地集成 Retool，但当时仅仅需要几个简单的集成，Retool 的高价格显然无法让人接受。

Helm

推荐

Helm v2 因各种原因而声名不佳，但 Helm v3 的表现已经算得上“还不错”。虽然在部署 CRD（自定义资源定义）时仍存在一些问题，并且还需要向开发工程师解释为什么他们的 Helm Chart 部署失败，但总体来说，Helm 作为一种打包和部署版本化 Kubernetes 对象的工具，表现令人满意。

此外，Helm 的 Go 模板语言虽然调试起来不太方便，但功能十分强大，能满足复杂的需求。

将 Helm Charts 存储在 ECR (OCI)

推荐

最初，我们将 Helm Charts 存储在 S3 中，并通过插件进行下载。这种方法的主要缺点是需要安装自定义的 Helm 插件，同时还要手动管理生命周期。后来，我们改用 OCI（Open Container Initiative）存储 Helm Charts，整个过程变得更加简化且高效。到目前为止，这种设置完全没有出现问题，体验非常稳定。

Bazel

不确定要不要推荐

客观来说，许多聪明的工程师都很喜欢 Bazel，所以它肯定不是一个糟糕的选择。

但是在部署 Go 服务时，Bazel 给我的感觉是有些过于复杂。对那些在上一家公司使用过 Bazel 并因此感到“怀念”的工程师来说，这可能是个不错的选择。否则，Bazel 会带来一个问题：我们的构建系统变得只有少数几位工程师能够深入掌握，而相比之下，GitHub Actions 的使用更加普遍，几乎每个人都可以轻松上手并解决问题。

没有早早使用 OpenTelemetry

十分后悔

一开始，我们直接通过 DataDog 的 API 将指标发送到 DataDog。这种方式让我们在后来想更换工具时变得非常困难。

四年前，OpenTelemetry 的成熟度确实还不足够高，但如今它已经进步了许多。虽然在指标收集方面仍显得有些不够成熟，但在分布式追踪领域表现得非常出色。我强烈建议任何公司从一开始就采用 OpenTelemetry，以避免未来的迁移难题。

选择 Renovatebot 而非 Dependabot

推荐

说实话，我真希望我们能更早意识到“保持依赖更新”的重要性。太久不更新依赖，会导致版本老旧，升级过程既漫长又充满问题。

Renovatebot 表现良好，并且可以灵活定制以满足需求。不过，它也有一个非常大的缺点：设置和调试的复杂度极高。尽管如此，综合来看，它仍然是所有选项中相对较好的一个。

Kubernetes

推荐

在运行长期服务时，你需要一个合适的平台。Kubernetes 是一个流行的选择，并且对我们来说效果很好。Kubernetes 社区在将 AWS 服务（例如负载均衡器、DNS 等）集成到 Kubernetes 生态系统中方面表现出色。

不过，任何灵活的系统都会有一个明显的缺点：使用方式太多。而一旦使用方式繁多，就不可避免地会有许多潜在的错误使用方式。谨慎设计和操作非常重要。

购买自己的IP

推荐

如果你与外部合作伙伴合作，通常需要提供一份你的 IP 白名单。然而，随着系统的扩展，你可能会开发更多需要独立 IP 的系统。购买自己的 IP 块是一种非常有效的解决方案。通过提供一个更大的 CIDR 块给外部合作伙伴，你可以避免频繁更新和管理白名单的麻烦。

选择 Flux 作为 K8s GitOps 工具

不后悔

在早期为 Kubernetes 选择 GitOps 工具时，我们在 ArgoCD 和 Flux 之间选择，最终选择了 Flux（当时是 v1）。事实证明，这个选择非常明智。目前我们已经升级到 Flux 2。唯一的缺点是我们需要自行开发工具来帮助团队成员更好地理解部署的状态。

听说很多人对 ArgoCD 的评价也很高，所以如果你选择了 ArgoCD，我相信这也是一个可靠的决定。

使用 SealedSecrets 管理 Kubernetes 密钥

非常不推荐

最初，我的想法是采用类似 GitOps 的方式来管理密钥。使用 sealed-secrets 后，我们遇到了两个主要问题：

对于缺乏基础设施知识的开发者来说，创建或更新密钥变得更加复杂。

我们失去了 AWS 在密钥轮换等方面的现有自动化功能。

使用ExternalSecrets管理Kubernetes密钥

推荐

ExternalSecrets 在同步 AWS 与 Kubernetes 密钥方面表现得非常好。这个过程简单易懂，开发者容易上手，并且让我们能够利用 Terraform 来轻松创建和更新 AWS 中的密钥，同时也为用户提供了一个界面来创建和更新密钥。

使用 ExternalDNS 管理 DNS

推荐

ExternalDNS 是一个很棒的产品。它将我们的 Kubernetes 与 Route53 DNS 记录同步，并且在过去四年里几乎没有出现过问题。

使用 cert-manager 管理 SSL 证书

推荐

配置非常直观，使用起来也没有任何问题。强烈推荐用它来为 Kubernetes 创建 Let’s Encrypt 证书。唯一的缺点是，有时我们会遇到一些使用过时技术栈（说到这里，SaaS 的问题，懂的都懂）并且不信任 Let’s Encrypt 的客户，这种情况下需要为他们购买付费证书。

Bottlerocket for EKS

非常后悔

我们曾经在 EKS 集群上使用 Bottlerocket，但遇到了一些问题。最主要的是，我们经常会碰到网络 CSI 问题，且调试 Bottlerocket 镜像比标准的 EKS AMI 更加困难。最终，我们转回使用 EKS 优化的 AMI，问题得到了有效解决。使用标准的 AMI 后，当遇到奇怪的网络问题时，我们也能更轻松地通过后门进行调试。

选择Terraform而非CloudFormation

推荐

对于任何公司来说，使用基础设施即代码（Infrastructure as Code）是必须的。在 AWS 环境中，主要的选择是 CloudFormation 和 Terraform。我使用过两者，并且不后悔选择了 Terraform。Terraform 在扩展到其他 SaaS 提供商（如 PagerDuty）时非常方便，语法也比 CloudFormation 更容易理解，而且对我们来说，它并没有成为障碍或瓶颈。

没有使用更像代码的 IaC 解决方案（如 Pulumi、CDK 等）

不后悔

Terraform 和 CloudFormation 使用数据文件（HCL 和 YAML/JSON）来描述基础设施，而像 Pulumi 或 CDK 这样的解决方案允许你编写代码来实现相同的功能。虽然代码很强大，但我发现 Terraform 的 HCL 语言有一定的限制，这种限制实际上减少了复杂性。并不是说不能写复杂的 Terraform 配置，而是这些复杂性更容易被发现。

像 Pulumi 这样的解决方案最早是在 Terraform 功能较少时发明的。而随着 Terraform 不断更新，已经集成了许多功能，这使得我们可以减少复杂度。我们目前的做法是，在想要抽象的部分使用自动生成的 Terraform 配置框架。

没有使用服务网格（如 Istio、Linkerd 等）

不后悔

服务网格非常酷，许多聪明的人都推崇它们，我也认为它们是不错的想法。但不幸的是，我认为很多公司低估了这类技术的复杂性。我的一般基础设施建议是：“简洁为上”。

在 EKS Ingress 中使用Nginx负载均衡

不后悔

Nginx 虽然是老牌产品，但它稳定且经过了大量的实际测试。

为公司脚本使用 Homebrew

推荐

你的公司很可能需要一种方式来分发脚本和二进制文件给工程师使用。Homebrew 在 Linux 和 Mac 用户中作为分发脚本和二进制文件的工具效果很好。

选择 Go 作为服务语言

推荐

Go 对于新工程师来说很容易上手，总体来说是一个不错的选择。对于主要依赖网络 I/O 的非 GPU 服务，Go 应该是你默认的语言选择。

本篇作为文章下半部分，介绍了关于基础设施技术栈的选择。关注「CloudPilot AI」，期待更多技术分享！

推荐阅读

4年经验总结！一位Anthropic工程师的基础设施避雷与推荐清单（上）

云从业者必读！2025年5个云成本管理趋势

手把手带你使用Karpenter减少K8s集群资源浪费