笔记。 翻译。：Dailymotion 是世界上最大的视频托管服务之一，因此也是著名的 Kubernetes 用户。 在本材料中，系统架构师 David Donchez 分享了创建公司基于 K8s 的生产平台的结果，该平台从 GKE 中的云安装开始，最终成为混合解决方案，从而实现了更好的响应时间并节省了基础设施成本。
决定重建核心 API 三年前，我们希望开发一种更有效的方式来托管应用程序并使其更容易 。 为此，我们决定使用容器编排平台，自然选择了 Kubernetes。
为什么值得基于 Kubernetes 构建自己的平台？
使用 Google Cloud 立即获得生产级 API
2016年夏季
三年前，Dailymotion 被 ，我们的工程团队专注于一个全球目标：创造一款全新的 Dailymotion 产品。
根据我们对容器、编排解决方案的分析以及过去的经验，我们确信 Kubernetes 是正确的选择。 一些开发人员已经了解了基本概念并知道如何使用它，这对于基础设施转型来说是一个巨大的优势。
从基础设施的角度来看，需要一个强大而灵活的系统来托管新型云原生应用程序。 我们在旅程开始时选择留在云端，这样我们就可以放心地构建最强大的本地平台。 我们决定使用 Google Kubernetes Engine 部署应用程序，尽管我们知道迟早我们会迁移到自己的数据中心并应用混合策略。
您为什么选择 GKE？
我们做出这个选择主要是出于技术原因。 此外，还需要快速提供满足公司业务需求的基础设施。 我们对托管应用程序有一些要求，例如地理分布、可扩展性和容错能力。
Dailymotion 中的 GKE 集群
由于 Dailymotion 是一个全球可用的视频平台，我们确实希望通过减少等待时间来提高服务质量 （潜伏）。 前 仅在巴黎可用，这不是最理想的。 我希望不仅能够在欧洲托管应用程序，而且还能够在亚洲和美国托管应用程序。
这种对延迟的敏感性意味着必须在平台的网络架构上进行认真的工作。 虽然大多数云服务迫使您在每个区域创建自己的网络，然后通过 VPN 或某种托管服务连接它们，但 Google Cloud 允许您创建覆盖所有 Google 区域的完全可路由的单一网络。 这对于系统的运行和效率来说是一个很大的优势。
此外，Google Cloud 的网络服务和负载均衡器也表现出色。 它们只是允许您使用每个区域的任意公共 IP 地址，而出色的 BGP 协议会处理其余的事情（即将用户重定向到最近的集群）。 显然，一旦出现故障，流量会自动转到另一个区域，无需任何人为干预。
监控 Google 负载平衡
我们的平台还大量使用 GPU。 Google Cloud 允许您直接在 Kubernetes 集群中非常有效地使用它们。
当时，基础设施团队主要关注部署在物理服务器上的遗留堆栈。 这就是为什么使用托管服务（包括 Kubernetes master）可以满足我们的要求，并允许我们培训团队使用本地集群。
结果，我们在工作开始后仅 6 个月就开始在 Google Cloud 基础设施上接收生产流量。
然而，尽管有很多优点，但与云提供商合作需要一定的成本，这些成本可能会根据负载而增加。 这就是为什么我们仔细分析了我们使用的每项托管服务，希望将来能够在本地实施它们。 事实上，地方集群的实施早在2016年底就开始了，混合战略也同时启动。
推出本地容器编排平台 Dailymotion
2016年秋季
在整个堆栈已准备好用于生产并使用 API 的情况下 ，是时候专注于区域集群了。
当时，用户每月观看的视频超过 3 亿次。 当然，我们多年来一直拥有自己广泛的内容交付网络。 我们希望利用这种情况，在现有数据中心部署 Kubernetes 集群。
Dailymotion 的基础设施由分布在六个数据中心的 2,5 多台服务器组成。 所有这些都是使用 Saltstack 配置的。 我们开始准备创建主节点和工作节点以及 etcd 集群的所有必要方法。
网络部分
我们的网络已完全路由。 每个服务器使用 Exabgp 在网络上通告其 IP。 我们比较了几个网络插件，唯一满足所有需求的一个（由于使用了 L3 方法）是 。 它完全适合现有的网络基础设施模型。
由于我们想要使用所有可用的基础设施元素，因此我们要做的第一件事就是找出我们自己开发的网络实用程序（在所有服务器上使用）：使用它来通过 Kubernetes 节点在网络上通告 IP 地址范围。 我们允许 Calico 为 Pod 分配 IP 地址，但没有也仍然不会将其用于网络设备上的 BGP 会话。 事实上，路由是由 Exabgp 处理的，它通告 Calico 使用的子网。 这使我们能够从内部网络（特别是负载均衡器）访问任何 Pod。
我们如何管理入口流量
为了将传入请求重定向到所需的服务，决定使用 Ingress Controller，因为它与 Kubernetes 入口资源集成。
三年前，nginx-ingress-controller 是最成熟的控制器：Nginx 已经存在很长时间了，以其稳定性和性能而闻名。
在我们的系统中，我们决定将控制器放置在专用的 10 Gb 刀片服务器上。 每个控制器都连接到相应集群的 kube-apiserver 端点。 这些服务器还使用 Exabgp 来通告公共或私有 IP 地址。 我们的网络拓扑允许我们使用这些控制器中的 BGP 将所有流量直接路由到 Pod，而无需使用 NodePort 等服务。 这种方法有助于避免节点之间的水平流量并提高效率。
从 Internet 到 Pod 的流量移动
现在我们了解了混合平台，我们可以更深入地研究流量迁移过程本身。
将流量从 Google Cloud 迁移到 Dailymotion 基础设施
2018年秋季
经过近两年的构建、测试和调整，我们终于拥有了一个完整的 Kubernetes 堆栈，可以接受一些流量。
目前的路由策略比较简单，但是足以满足需要。 除了公共 IP（在 Google Cloud 和 Dailymotion 上）之外，AWS Route 53 还用于设置策略并将用户重定向到我们选择的集群。
使用 Route 53 的路由策略示例
使用 Google Cloud，这很容易，因为我们在所有集群之间共享一个 IP，并且用户会被重定向到最近的 GKE 集群。 对于我们的集群来说，技术是不同的，因为它们的 IP 不同。
在迁移过程中，我们试图将区域请求重定向到适当的集群，并评估这种方法的好处。
由于我们的 GKE 集群配置为使用自定义指标自动扩展，因此它们会根据传入流量进行扩展/缩减。
在正常模式下，所有区域流量都定向到本地集群，GKE 作为出现问题时的储备（由 Route 53 执行健康检查）。
...
未来，我们希望完全自动化路由策略，以实现自主混合策略，不断提高用户的可访问性。 从好的方面来看，云成本显着降低，API 响应时间甚至缩短。 我们信任由此产生的云平台，并准备在必要时将更多流量重定向到该平台。
译者PS
您可能还对 Dailymotion 最近发布的另一篇有关 Kubernetes 的文章感兴趣。 它致力于在许多 Kubernetes 集群上使用 Helm 部署应用程序 大概一个月前。
另请阅读我们的博客：
- «“。
- «“;
- «“;
- «“;
- «“;
- «“;
- «“;
- «“;
- «“;
- «“;
- «“。
来源： habr.com