生效时间
本博客是“什么是良好的控制平面来操作大量 Kubernetes 集群”的后续。 上一篇文章描述了 Volterra 独特的 Fleet Operations 方法，用于管理一系列基础设施站点和applications。 这个特定的博客描述了运营团队在大量集群或站点上进行配置更改时面临的配置漂移这一关键挑战。 我把这个挑战称为“效果时间”。
什么是生效时间？
简单来说就是一个行动意图需要多长时间才能生效。 示例包括：
- 我的安全策略配置需要多长时间才能在所有网站上生效？
- 我的应用的最新版本需要多长时间才能传播到所有站点？
- 升级我所有全球分布的站点上的操作系统或基础设施软件需要多长时间？
为什么它很重要？
这个问题可以通过一些真实的客户案例来回答：
- Meltdown 和 Spectre — Meltdown/Spectre 新闻爆出后，每个 CISO 最关心的问题就是如何快速修补所有基础设施上的操作系统。 运营团队每小时都会接受一次考量，以确保他们的意图（即升级操作系统版本）能够生效。
- 你一定听说过自动售货机群对一所大学造成拒绝服务攻击的事件吧？ 如果您没有关注该攻击，以下是 TL;DR - 黑客利用零日漏洞并安装了与其他自动售货机连接的恶意软件并创建了一批自动售货机器人。 然后它发送了大量流量并对大学造成了拒绝服务攻击。 在检测到攻击后，大学必须逐一在每台自动售货机上配置网络策略规则，以防止访问命令和控制服务器。 对他们来说，让他们的意图（即阻止访问特定网站）立即在所有自动售货机上生效以止血极其重要。
生效时间对于基础设施软件、应用软件、网络策略和安全策略等多个类别都很重要。
挑战是什么？
当运营团队必须管理时，挑战的严峻性最为显著
- 大型场地
- 全球分布的站点
- 异构环境，即私有、公共、电信云和边缘设备中的站点
- 站点连接不一致
汽车原始设备制造商的运营团队就是一个很好的例子，他们负责更新软件并管理其汽车（以下称为客户站点）的连接性。 典型的部署将包括一个私有数据中心，运营团队可以通过该中心在全球范围内控制他们的汽车（或根据组织结构在区域范围内控制）。
为了理解这一挑战，让我们看看运营团队可以采用的解决方案。 大多数解决方案都提供托管在客户私有数据中心的管理软件，以集中管理大规模分布式站点。 当汽车原始设备制造商配置需要应用于所有汽车的策略时，中央管理软件基本上会将配置脚本逐一下载到每辆汽车上。 配置脚本可以是 ansible playbook 或 helm chart，在每个站点上执行一系列配置命令。 如下图所示，可以直观地看到这一点。
问题在于，生效时间与站点数量成正比。 集中管理软件供应商会争辩说，只要所有操作都能够远程以自动化方式执行，这就是可以实现的最佳效果。
Volterra 对此表示不同意，我们可以在这篇博客中证明这一点。 我们构建了一个分布式控制平面，采用分层的、横向扩展的架构方法，旨在确保最短的生效时间。
沃尔特拉架构可最大程度缩短生效时间
实现最短生效时间的基本要素是：
- 基于层次树的架构
- 专用分布式控制平面
接下来显示的是高级架构概述。
Volterra 的分层架构方法是创建一个节点树用于配置分配。 每个节点都进行存储和转发 - 即，将配置存储在本地，然后转发给其子节点。 最好用一个例子来描述这一点。 当用户在 Volterra 控制台上配置网络策略等对象时，控制和管理平面会将配置分发给直属子区域边缘 (RE)。 每个 RE 都在本地存储配置并转发给其子项。 RE 的子项是与该 RE 相连的客户站点。
基于层次树的架构可确保最短的生效时间。 生效时间受树中的级别数和每个节点的子节点数的限制。 树中的最大级别数为三级 (控制器 → RE → 客户站点)。 每个节点的子节点数量与连接到 RE 的站点数量成正比。 在 RE 上生成一个服务实例来处理一组站点的配置。 如果连接到 RE 的站点数量增加，Volterra 的横向扩展控制平面会按需生成新的服务实例。
测试设置
效果时间测量是在连接到位于纽约（NY8-NYC）和巴黎（PA4-PAR）的两个区域边缘的大规模客户站点上进行的。 客户遍布全球，包括圣克拉拉（加利福尼亚州）、休斯顿（德克萨斯州）、马德里（西班牙）、布拉格（捷克共和国）、伦敦（英国）等。 此外，客户站点跨异构环境，例如 AWS、虚拟机 (ESXi)、边缘网关（包括 Intel NUC 和 Fitlet2）。
Volterra 的客户门户和全球控制平面在 Azure（华盛顿 IAD）中运行。 客户站点分布在多个命名空间和租户中，以代表真实的操作环境。
通过终止 RE 上的服务实例并使用 RE 与客户站点之间质量较差的连接链路来模拟故障情况。 图 3 显示了单个命名空间中整个舰队某个部分的即时快照视图。
测试方法
每当在 Volterra 控制台上配置对象并在每个客户站点上应用配置时，带有时间戳的审计日志都会被捕获到 Volterra 系统中。 传播时间是通过门户上的配置与客户站点上配置的应用之间的时间差来衡量的。 接下来将描述详细的逐步过程。
- 在客户门户上配置对象。
- 将开始时间测量为客户门户（在此称为 Volterra 全局控制器）上的对象创建时间。 例如见图 4。
- 将结束时间测量为客户站点上的对象创建时间。 例如见图 5。
请注意，显示的屏幕截图是采样的，并不代表相同的测量迭代。
配置开始时间
配置结束时间
测试结果
传播时间的测试结果如图6和图7所示。 图 6 中的图表表明，大多数测量样本的传播时间在 0-400 毫秒之间。 这意味着所有客户站点都会在 0-400 毫秒内更新新配置。 如前所述，通过在 RE 上重新启动服务并在客户站点引入连接故障/延迟来模拟故障情况。 在这些故障条件下，配置传播时间更长，在这些特定测试中，根据故障类型，范围从 600 毫秒到 9 秒。 例如，RE 与客户站点之间的连接故障将增加配置到达客户站点的时间。 然而，Volterra 分布式控制平面的好处在于它遵循最终一致配置的范例，即它不断重试以确保所有客户站点上的配置符合客户定义的意图。
图 7 中的图表表明，85% 的时间内，所有客户站点都会在 322 毫秒内更新新配置。 在出现故障情况的情况下，很少有客户站点会经历约 3-9 秒的传播时间。
免责声明： 这些测量与拓扑、规模、部署环境和模拟的故障情况密切相关。 我们没有测量所有可能发生的故障情况或其他环境。 因此，我们无法对未经测试的其他情况或环境下的传播延迟作出声明。 例如，如果 Kubernetes 集群出现故障，系统将不得不等待故障检测、重新启动并重试配置，从而导致更高的传播延迟。