我们使用的主要容器技术是 Kubernetes、containerd 和 Cilium。我们在多个云提供商中运行了数十个不同规模的 Kubernetes 集群——我们最大的集群包含 4,000 多个节点——我们依靠内部开发的工具来管理和协调多个集群上的部署。
— Laurent Bernaille，Datadog
我们在 AWS 和 Azure 中使用 Kubernetes，在 Ruby on Rails、Java、Go 和 Python 中运行 dockerized 应用程序。Kubernetes 将指标报告给 Datadog，记录到 Papertrail，应用程序错误转到 Sentry。我们使用 Sops 进行机密配置，使用 Terraform 定义跨云部署 Kubernetes 的基础设施。
— 克里斯·罗格斯，布雷兹
我们使用 Heroku，它采用称为 dynos 的轻量级容器，用于我们的 Web 服务器、后台作业和我们的 ML 微服务子集。其他 ML 微服务使用 Kubeflow。我们使用 Docker 将我们的开发和测试环境与生产环境保持一致。对于日志记录、报告和系统运行状况警报，我们使用 SolarWinds Papertrail 和 Sumo Logic。对于客户端和应用程序错误报告，我们使用 Sentry。最后，对于性能监控，我们使用 Scout 和 Calibre。
— 布莱恩·希克森，BetterUp
您的组织是什么时候开始使用容器的，他们如何改变了您的开发工作流程？
们于 2018 年初开始将 Datadog 迁移到 Kubernetes，大约六个月后，Datadog 的第一个版本在生产环境中完全运行在 Kubernetes 中。这包括无状态 Web 应用程序和有状态数据服务，如 Cassandra 和 Kafka。我们正在从使用 Chef 管理的 VM 中运行的应用程序迁移，因此转换需要对我们的开发过程进行许多更改。例如，我们必须对每个应用程序进行容器化，并提供一个解决方案来部署到 Kubernetes 集群，这最初依赖于 Spinnaker 和 Helm 图表。迁移具有挑战性：截止日期是雄心勃勃的，我们从一个没有容器也没有工具来部署它们的环境开始。但这也是有益的，因为它使我们能够拥有统一的打包和部署解决方案，
— Laurent Bernaille，Datadog
大约两年前，我们开始使用容器，作为我们努力成为多云的一部分。这是经过近一年的初步探索。容器起初增加了一些复杂性，特别是在配置方面，但随着我们构建工具，某些方面也变得更容易。例如，过去的配置来自 Chef，这需要更严格的更改权限。通过将 Chef 数据包配置移至 Sops，我们为开发人员实现了更简单的自助更改。
— 克里斯·罗格斯，布雷兹
在 2015 年之前，我们使用基于 VM 的开发环境，然后由于本地依赖项的挑战而切换到容器，这些依赖项在本地编译并易于跨越升级。切换到容器解决了这个问题——我们能够无缝迁移，而不会对我们的开发工作流程产生负面影响。它还使我们的开发环境更加现代化和生产化，并且资源密集度更低。
— 布莱恩·希克森，BetterUp
您的组织是否将任何遗留应用程序迁移到容器？有哪些挑战，你学到了什么？
我们的大多数应用程序都是用 Go、Python 和 Java 编写的，因此在容器中运行它们并不困难。当然，魔鬼在细节中，我们面临着几个挑战，包括管理容器中 JVM 的内存占用。大多数应用程序假设它们是唯一在 VM 上运行的应用程序，这带来了自己的挑战——尤其是在 IO 操作（磁盘和网络访问）方面，因为 Kubernetes 在共享 CPU 时间和内存方面非常有效。使用 IO 执行此操作更为复杂，其中 Kubernetes 对如何限制和隔离资源消耗的控制较少。我们注意到，将应用程序迁移到 Kubernetes 后，我们需要两倍数量的主机。一旦我们分析了应用程序并分析了开销，
— Laurent Bernaille，Datadog
我们已将几乎所有遗留应用程序迁移到容器。对应用程序进行 Docker 化相对简单，并且在大多数情况下使打包依赖项和部署更容易。以前，DevOps 管理 EC2 实例应用程序被复制到并通过 Chef 运行。通过将应用程序移动到容器中，应用程序工程师可以更直接地控制应用程序在哪些环境中运行、哪些工具和库可用，以及如何分配资源。
挑战主要在于将部署管道的职责从 DevOps 转移到应用程序工程团队，以及在 Kubernetes 中调试应用程序的知识，而不是在 EC2 实例上。然而，所有这些都具有显着的长期好处，消除了来回更改的需要，并使代码与其运行的环境更紧密地耦合。
— 克里斯·罗格斯，布雷兹
我们使用容器来试验 ML 微服务。我们提取了主要应用程序的一小部分，并使用更适合的技术堆栈快速推出新服务。这允许快速迭代和实验。例如，我们能够将在 R 中使用贝叶斯方法训练的模型无缝替换为在 Python 中使用神经网络的模型。
我们在从单体应用中分离服务时面临的一个挑战是服务不再可以直接访问实时应用程序数据。我们必须确定微服务将保留对哪些数据的访问权限，并了解到服务越接近实时，它就越需要访问上下文数据。
— 布莱恩·希克森，BetterUp
您如何部署和监控容器化应用程序？您的关键健康指标是什么？
我们依靠 Datadog 进行监控。每个应用程序负责配置其监控，但一些关键指标无处不在：容器 CPU 和内存使用情况、容器状态和重启次数，以及底层节点的健康状况。 我们最初使用 Spinnaker 来部署容器化应用程序，这在早期提供了强大的基础，但随着集群数量的增加和工作流程变得更加复杂，我们的规模越来越大。我们目前正在为多集群部署开发一个内部解决方案，该解决方案利用 Helm 和云原生应用程序包，由 Temporal 提供支持。
— Laurent Bernaille，Datadog
我们主要关注内存和 CPU、标准 Kubernetes 监控以及特定于应用程序的指标，如内部队列大小和错误率。应用程序通过 Helm 部署，使用内部工具在配置更改时通过 Jenkins 向 Helm CLI 提供部署配置（GitHub 存储库中的 YAML）。
— 克里斯·罗格斯，布雷兹
当构建通过我们的主分支时，我们使用 Heroku 来持续部署我们的应用程序。我们使用 Heroku 和日志服务——Pingdom 和 New Relic，结合 PagerDuty 发出警报——这使我们能够调查生产系统中的问题，并在检测到问题时提醒我们的团队。我们还使用合成和真实用户监控来检测灾难性错误和性能问题。作为一个团队，我们使用 KPI 来跟踪我们基础架构的趋势。一项关键的健康指标是服务器正常运行时间，2020 年为 99.999%。
— 布莱恩·希克森，BetterUp
您的组织如何进行容器测试？您如何利用自动化？
我们不对容器进行系统测试。相反，我们在 CI 中测试应用程序并在暂存和使用金丝雀中验证新的容器版本。当我们怀疑容器化会影响容器时，我们还会对容器进行临时测试 - 特别是无法通过代码库更改来解释的性能回归。
— Laurent Bernaille，Datadog
我们的许多应用程序都是通过 Docker Compose 在本地开发和测试的。我们还在运行容器化应用程序部署的开发和暂存环境中每天多次运行端到端测试。CI——我们使用 Buildkite——也在 Docker 内部运行测试，它会根据应用程序代码的更改自动运行。
— 克里斯·罗格斯，布雷兹
我们的测试容器配置为与我们的生产环境相匹配。我们不直接测试容器本身，但我们的持续测试过程可确保应用程序行为在各个分支之间保持一致。
— 布莱恩·希克森，BetterUp
您的组织如何跟上容器生态系统的变化？您如何决定何时采用新技术或工具？
由于我们大规模使用 Kubernetes 并面临生态系统刚刚开始解决的挑战，因此我们倾向于在很早的时候测试并采用新技术，当测试成功时。例如，我们在获得容器运行时接口后立即对 containerd 进行了标准化，并且出于可扩展性原因，当它在测试版中可用时，我们在 IPVS 模式下使用了 kube-proxy。最近，我们为 pod 网络、服务负载平衡和网络策略标准化了 Cilium。
— Laurent Bernaille，Datadog
我们的工程师关注整个行业的变化。他们经常鼓吹改变以尝试新方法，包括在我们的内部黑客日进行概念验证演示，以探索和衡量其他人的兴趣。他们关注 AWS 公告、Kubernetes 公告和任意数量的技术新闻来源，以了解新选项。他们在遇到问题时寻求解决方案，并想象“更好”可能是什么样子。例如，我们对通过使用 Spot 实例自动配置实例来节省成本进行了大量研究。
— 克里斯·罗格斯，布雷兹
我们依靠工程师来发现改进容器使用方式的机会，并权衡成本与潜在价值或需求。例如，最近我们的前端和全栈工程师遇到了 Docker for Mac 的文件系统性能问题。我们的一位工程师研究了使用 Docker 改进 IO 的技术，并试验了 Mutagen、NFS 和其他用于在本机系统和 Docker 之间共享文件的技术。最终我们在整个团队中采用了 Mutagen，这显着改善了开发者体验。前端容器的构建时间不再是个人开发人员生产力的拖累。
— 布莱恩·希克森，BetterUp
您的组织发现使用容器最令人惊讶的是什么？
我们遇到了很多令人惊讶的挑战，从控制平面可扩展性问题到低级运行时或网络问题。不过，总的来说，Datadog 在采用容器方面取得的巨大成功是，它允许我们使用通用抽象跨多个云提供商进行扩展和部署。
— Laurent Bernaille，Datadog
为 localdev 构建的容器需要额外的调试工具，这在生产中是不受欢迎的。生产中的调试比本地调试要困难得多，尤其是在托管容器的服务器上使用细粒度访问控制列表时。在容器中准确地在本地复制面向服务的架构可能会使笔记本电脑的 CPU 和内存不堪重负，这会导致仍然缺乏保真度的捷径，例如无法运行“真正的”Kubernetes 集群或相同的配置。CI 构建容器的方式与它们在本地构建的方式不同，并且可以轻松包含本地不存在的内容，这些内容可能难以调试或识别。
— 克里斯·罗格斯，布雷兹
容器使我们能够在一个云提供商上训练新的 ML 模型，并在我们准备将它们与我们的主要应用程序集成时轻松迁移到另一个。我们还惊讶于我们遇到的与容器本身相关的问题如此之少。任何问题通常都处于比容器级别更高的抽象级别；例如，我们在部署应用程序的方式中发现了错误，但它们并非特定于我们对容器的使用。
— 布莱恩·希克森，BetterUp