作者 | Michael Bogan译者 | Luga Lee策划 | Luga Lee
基于不同的 Kubernetes 集群的弹性伸缩方案，在日常的维护中具有重要意义 ~
想象一下，假设亚马逊每年只有一天不可用。按照这个数值估算，他们的业务将会约有 99.7% 的可用性，从表面上看这是相当合理的。然而，在过去的 2020 年，亚马逊的收入接近 4000 亿美元。基于 99.7% 而不是 100% 的可用性将花费亚马逊超过 10 亿美元。哪怕停机时间只是那么一点点，也会让公司的业务损失惨重。
通常，我们通过冗余机制来最大限度地减少停机时间，用不可靠的部件构建可靠的系统，以及需要有备用部件来替换故障部件。然而，更换有故障的部件仍然需要时间。现在，让我们把它带到软件领域。假设有一个企业级系统，其中有成千上万（或更多）的服务器和应用程序。它们遍布全球。我们需要将应用程序和服务部署到服务器、管理基础架构、升级、修补和支持开发。发生事故时，我们需要能够安全地回滚更改或故障切换到备用系统，同时，需要保护所有这些系统并对其访问资源进行管理。
在过去几年里，Kubernetes 已经崭露头角，因为它为建立这样大规模的系统提供了坚实的、可扩展的基础。对于大型系统的连续交付（CD），包括构建在 Kubernetes 上的系统，首选的平台是 Spinnaker 。但是，如果我们单独使用 Spinnaker ，那么以这种规模管理 Kubernetes 部署是站不住脚的。我们需要一个健壮的工具来处理变更管理、管道配置和安全性。最终，我们需要的是 Armory 的企业级 Spinnaker 分发。
在本文中，我们将考虑管理 Kubernetes 在规模上的挑战和处理操作环境和升级 Kubernetes 引入的故障。然后，我们将了解 Spinnaker 作为 Kubernetes 的 CD 平台的作用。最后，我们将介绍使用 Armory Spinnaker 管理如此大规模 Kubernetes 系统的简单性和安全性。
大规模管理Kubernetes
通常在一定的集群级别运行规模，Kubernetes 的确是一款很棒的平台，但是它也有自身的局限性。Kubernetes 1.21 支持每个集群多达 5000 个节点和每个节点 110 个 Pod ，总共多达 150000 个 Pod 和 300000 个容器。这规模似乎看起来很庞大，然而，大多数规模相当的企业甚至超过了这些限制的好几个数量级。
这些集群限制短期内不太可能改变。对于较大的系统，解决方案是运行多个 Kubernetes 集群。但是，如果没有良好工具的支持，多集群管理的可持续性如何呢？此外，我们还要面临管理用户和服务的访问控制、协调多个环境以及处理可能破坏系统的Kubernetes 升级的挑战。在我们正在考虑的规模级别上，对于无法接受停机的企业来说，任务是艰巨的。让我们详细地梳理下这些挑战中的每一个关键项：
多集群管理
首先，让我们看一下多集群领域。如果我们有少量集群（比方说少于10个），那么可以尝试直接管理它们。人类将遵循 runbook 来执行诸如提供集群、部署基本软件、升级和修正等任务。
这种手动操作很快就会中断。Kubernetes 提倡将服务资源视为宏观的概念。在规模上，我们还需要将此概念应用到集群中。这是什么意思？这意味着集群是一次性的。运行某些工作负载（包括关键工作负载）的集群可以扩展（有更多类似的集群运行相同的工作负载）、可以删除和/或排空，并将其工作负载转移到另一个集群。
这种规模控制级别需要大量专用集群管理软件。最有用的模式之一是管理集群。管理集群是一个 Kubernetes 集群，其任务是管理其他 Kubernetes 集群。这种方法的一个很好的起点是 Kubernetes 集群 API ，它是一个 Kubernetes 子项目，正好处理这个问题。
用户、服务帐户和权限
其次，在大规模管理大量资源时管理和控制访问的问题。Kubernetes 支持用户（人）和服务帐户（机器）等概念以及基于角色的访问控制模型（RBAC）。凭证和机密需要安全管理和轮换。用户和服务帐户需要配置和删除，应用程序需要启动和停用。即使对于单个集群，这种类型的管理也不是微不足道的。当考虑到数十个、数百个甚至数千个短暂的集群时，管理问题似乎是压倒性的。
这里有几个关系重大的问题，我们将简要介绍一下。
1、用户体验
用户体验包括请求每个集群上的正确访问级别。如果没有适当的支持，用户很难知道每个集群需要什么访问级别。通常，用户会试图通过 UI 访问某些资源，并遇到一个模糊的“拒绝访问”错误。
2、操作员经验
操作员体验包括管理复杂的资源和用户图。通常，它们是以资源组和用户组的层次结构组织的。操作员需要能够管理每个用户/组的正确权限以及组内的用户成员资格。每当新用户加入组织、离开组织或更改角色时，都需要调整这些权限。所有这些都需要开发人员、运营商和 IT 之间的集成。
3、潜在范围
漏洞的潜在范围通常与权限管理的粒度有关。如果每个开发人员都拥有完全的管理权限，那么一台受损的笔记本电脑可能会导致全面的危机。另一方面，定制每个用户的权限会导致大量的工作。错误将使人们无法获得执行工作所需的资源。
4、安全
安全问题密切相关。如果资源未得到正确保护，则敏感信息可能会泄漏。攻击者可以控制关键系统。
一旦我们添加了一个简单的现实，即应用程序和自动化系统也需要它们自己的权限来混合，问题就复杂了。
归根结底，这种规模的管理是不可能通过单击某些 Web 控制台中的按钮来实现的。整个过程必须是动态的，在整个企业中具有自动发现和一致的指导原则。
操作环境
现在，让我们更详细地了解全球大规模系统的一个方面。每个工作负载并不存在于单个环境中。在开发、部署和维护的生命周期中，工作负载将在不同的环境中使用。例如，一个常见的模型是拥有多个部署环境，如开发、预发布和生产环境。在处理多个 Kubernetes 群集时，管理每个环境变得更加困难。
当然，生产环境是最关键的。但是，预发布环境通常必须遵守非常高的可用性标准，模仿生产环境，因为它充当生产部署的守门人。
前面，我们提到了冗余和故障切换。系统架构和拓扑可能决定是否将 Kubernetes 集群部署为多区域甚至多云，以保护自己免受不同故障模式的影响。毕竟，冗余是昂贵的，管理故障转移也不是一件小事。
如果我们的集群运行在云提供商和私有数据中心的混合上，这又增加了复杂性的另一个维度。
最后，我们的开发人员将更倾向于本地开发体验，在将更改部署到共享开发环境之前，他们可以在当前环境中进行测试、更改。
升级Kubernetes
通常，我们的 Kubernetes 集群已启动并正常运行，对于每个人而言，显得尤为轻松。然而，即使是现在，我们的工作还没有完成。Kubernetes 每年发布三次新版本（之前，他们每年发布四次新版本）。我们应该经常升级。如果我们使用像 GKE、EKS 或 AKS 这样的托管 Kubernetes 产品，这一点尤其正确。我们的云提供商将会协助升级 Kubernetes 集群，无论我们是否喜欢。
Kubernetes 有一个非常有序的弃置和移除过程。每个资源都有一个组、版本、种类（GVK）。首先，特定版本将被弃用。这意味着该版本仍然受支持，但每个人都知道它将在稍后被完全删除。如果升级到 Kubernetes 的新版本，并尝试创建或更新删除的对象，则此操作将失败。我们的集群现在包含断开的资源。
为了防止这种情况发生，我们必须保持警惕，不断地将所有 Kubernetes 资源更新到受支持的版本。一个好的做法是尽早更新甚至不推荐使用的资源。若我们不希望将更新延迟到最后一分钟，即升级到不再支持这些资源的 Kubernetes 版本之前。
我们将会怎么做？首先，我们将阅读 Kubernetes 发行说明，了解哪些资源将被弃用或删除。然后，扫描所有集群以查找受影响的资源。确定这些资源后，与利益相关者合作，将其资源更新为受支持的版本。
在规模上，我们将需要工具来评估兼容性。我写了两个工具，我可能很快就会开放源代码：一个工具接受已弃用/删除的资源版本列表，并扫描使用这些版本的资源的集群列表。另一个工具获取集群和目标集群的列表，并将所有原始资源导入到目标集群。
例如，如果要从 Kubernetes 1.18 升级到 Kubernetes 1.19 ，则将创建一个 1.19 空集群，并使用所有 1.18 集群的列表运行该工具。该工具将尝试创建（在干运行模式下）1.19 集群中 1.18 集群的所有资源。任何不兼容都将导致报告错误。
一旦我们准备好升级，并且所有工作负载都使用支持的版本，就可以执行实际的升级了。升级过程分为两部分：升级控制平面和升级数据平面（工作节点）。数据平面版本是指安装在每个节点上的 Kubernetes 组件的版本（Kubelet、容器运行时、Kube 代理）。不同的节点可能有不同的版本，但它们不能早于控制平面的两个次要版本，也不能比控制平面版本更新。
这意味着在升级集群时，首先必须将控制平面升级到一个版本，该版本最多比最早的节点版本早两个次要版本。例如，如果节点位于 Kubernetes 1.18 上，则可以将控制平面升级到 1.19 或 1.20 。然后，我们可以跟踪并将节点升级到同一版本。
最佳实践是保持控制平面上的所有内容一致，并且所有节点都应位于 Kubernetes 的同一次要版本上。唯一的例外是在升级过程中，旧版本上暂时会有一些组件，新版本上也会有一些组件。
所有这些都需要相当多的协调，特别是如果我们在云提供商和 on-prem 的组合上运行 Kubernetes 群集。可能并非所有云提供商都支持相同版本的 Kubernetes。我们需要找到一个共同点或偏离最佳实践，并在不同的提供商上运行不同版本的 Kubernetes 。
规模化管理 Kubernetes 是一项非同寻常的任务，这一点是否已经变得清晰？要做到这一点，需要大量的支持软件，其中大部分不仅仅是现成的。我们需要构建自己的工具，对其进行改进，并支持高级部署场景。
除了管理 Kubernetes 集群的任务外，还有部署和扩展的巨大任务，此刻便是 Spinnaker 的用武之地。
Spinnaker 作为 Kubernetes 的 CD 平台
虽然 Kubernetes 有几种功能强大且流行的连续交付解决方案，但 Spinnaker 有一些独特的功能，特别是对于需要处理大量 Kubernetes 集群的企业。
首先，Spinnaker 经过了大规模的战斗测试验证。它最初由 Netflix 开发，然后由 Google 扩展。其次，Spinnaker 支持多个提供者，而不仅仅是 Kubernetes 。不特定于 Kubernetes 可能看起来是一个缺点，但是，拥有数千个 Kubernetes 集群的公司都只有这些集群。在 Kubernetes 出现之前（仅仅六年前），以这种规模运营的公司就已经存在很久了。他们通常在非 Kubernetes 环境中部署大量系统。Spinnaker 支持其 Kubernetes 环境以及非 Kubernetes 环境。
此外，Spinnaker 在技术上非常强大，支持多种部署模型，这是管理大量服务和应用程序所必需的。
最后，Spinnaker 虽然是一个开源项目，但也得到 Armory 等公司的大力商业支持。
基于 Armory Spinnaker 简单安全性
虽然 Spinnaker 在大规模部署方面取得了进展，但对于企业来说，这只是一个开始。在运行如此规模的系统的企业中，不仅仅是一个 DevOps 专家运行所有的 Spinnaker 。整个 DevOps 团队（复数）都同时接触 Spinnaker 管道。Spinnaker 本身无法提供这些企业所需的策略管理和管道更改管理。为了满足这一需求， Armory 开发了其企业级 Spinnaker 分销，并以非常重要的方式扩展了Spinnaker ，使其成为更好的 Kubernetes 生态项目成员，特别是在大规模普及层面。
首先，Armory 使用 Spinnaker 自己的插件构建在 Vanilla Spinnaker 之上。这对可持续一体化至关重要。大约十年前，我在一家基于 Chromium 构建社交浏览器的公司工作。该项目是非常创新和成功的，虽然其涉及 Chromium 的深度定制。每当 Chromium 发布新版本时，我们都必须在其上重新上所有应用定制。每当安全修复漏洞被披露时，在完成集成之前，我们都很容易受到攻击，这需要几天（在某些情况下，需要几周）的时间去修复。在这方面， Armory 走上了一条康庄大道，使用标准机制为开源 Spinnaker 提供插件框架。简单地说，Armory 建立在开源 Spinnaker 之上。
其次，Armory 也致力于Kubernetes ，致力于其成为一个更好的 Kubernetes 生态项目成员。这是从 Kubernetes 的 Armory 代理开始的。代理允许分布式部署到数千个集群和分散的帐户管理。此外，Armory 提供了一个策略引擎，允许设置组织策略，提高安全性和法规遵从性。
如果可能的话，Armory 也会加入一些其他的好 Idea ，比如广泛整合和密钥管理。但是，可以毫不隐讳地讲，大规模管理 Kubernetes 最重要的功能是 Armory “作为代码管道”的最佳核心之一。基于 Spinnaker 管道的 GitOps 是一个关键特性。在源代码控制中保持 Spinnaker 管道作为代码，并使用标准审查和更改管理，这将产生巨大的影响。
结论
Kubernetes 为现代基于容器的分布式应用程序解决了诸多问题。然而，在实际的业务场景中，将企业级系统迁移至 Kubernetes 时，最终可能会管理大量 Kubernetes 集群。要做到这一点，我们通常需要一个可靠的解决方案来将工作负载部署到所有这些集群，以及管理集群本身。或许，Spinnaker 和 Armory 可以很好地支撑我们。若进行大量 Kubernetes 集群管理或计划将大型现有系统迁移到 Kubernetes 平台时，我们可能会发现 Spinnaker 和 Armory 可能是我们的最佳的持续部署解决方案。
