使用 F5 分布式云服务的 Kubernetes 架构选项

F5 分布式云服务既可以与现有 Kubernetes (K8s) Cluster集成，也可以托管 K8s 工作负载本身。对此，我们提供了多种架构选择。本文将按照复杂程度和所具优势从低到高为您介绍四种主要架构。

• 架构 1：外部负载均衡器（安全 K8s 网关）
• 架构 2：CE（Customer Edge） 作为 pod（K8s 站点）
• 架构 3：托管Namespace (vK8s)
• 架构 4：托管 K8s (mK8s)

Kubernetes 架构选项

随着 K8s 的不断扩展，运行 K8s 以及与现有 K8s 平台集成的选择也越来越多。F5 分布式云服务既可以与现有 K8s Cluster集成，也可以运行托管的 K8s 平台本身。这些产品中也有多种架构，所以第一次听说这些可能性时，我感到很震惊。

一位用户在最近交谈时对我说：

“F5 分布式云既可以与 K8s 平台集成，在 K8s 平台内运行，托管虚拟 K8s (Namespace-aaS)，也可以在F5 分布式云环境中托管运行 K8s 平台。”
我回答道：“太棒了，这就可以有区分架构选项的思维模式。”

为让更多朋友了解并能运用这些架构，本文将给出概览和介绍，并就如何进行选择提供初级指导：

名词解释
APPSTACK + MESH FUNCTIONALITY	应用栈：用于在多云或边缘的分布式基础设施中部署、保护和操作一系列应用程序。 网格：用于连接、保护、控制和观察部署在单个云位置内的应用程序或分布在多个云和边缘站点的应用程序。 功能
vk8s mk8s	虚拟k8s Mange k8s
分布式云-managed K8s workloads	分布式云管理的 K8s 工作负载
Existing K8s Clusters	现有 K8s Cluster

 

什么是 F5 分布式云服务

F5 分布式云服务是一个全球平台，可提供网络和应用交付服务及计算管理（K8s 工作负载）。我们将每个全球 PoP 称为区域边缘 (RE)。RE 均高度网格化，构成了全球平台的骨干。它们不仅可以连接您的站点，将您的服务暴露到互联网上，而且还能够运行工作负载。通过在网络中运行一个或多个分布式云节点（也称为客户边缘 (CE)），该平台可扩展到您的数据中心。CE 是网络中的一个计算节点，它注册到我们的全球控制平面，然后作为用户租户下专有的 SaaS ，由客户进行管理。

注册一个或多个 CE 将在 F5 分布式云中创建一个客户站点。CE 可作为虚拟机运行，也可以在硬件上运行（包括硬件，供现场使用），甚至能够作为一组 K8s pod 运行。如果适用，CE 可作为 CE Cluster的一部分运行，从而确保站点的高可用性。

F5 分布式云网格（F5 Distributed Cloud Mesh） 功能提供了站点间连接、安全服务和可观测性。此外，F5 分布式云应用栈（F5 Distributed Cloud App Stack）功能（也使用网格功能）允许将任意数量的托管Cluster按逻辑分组到具有单个 K8s 管理接口的虚拟站点（一类具有相同业务负载职能的站点合集）中。因此，网格服务提供网络，应用栈服务提供 Kubernetes 计算管理。我们的前 2 个架构仅需 网格服务，而我们的后 2 个架构则需使用应用栈（以及 网格）。

Cluster之间的服务通信

经常有人问我如何支持Cluster之间的服务相互通信。分布式云服务有助于轻松地实现这一点。每个站点均可向其他站点发布服务，包括 K8s 站点。这意味着，任何 K8s 服务对于您选择向其发布此服务的其他站点都是可用的。以下任何架构都可以做到这一点，尽管更复杂的架构可能实现更细粒度的控制。我将在另一篇文章中深入探讨这个问题。

架构 1：外部负载均衡器（安全 K8s 网关）

在安全 Kubernetes 网关架构中，您可集成现有 K8s 平台，将分布式云节点作为 K8s Cluster的外部负载均衡器。在该场景中，您需要创建一个 ServiceAccount 和 kubeconfig 文件来配置分布式云。然后，分布式云节点对 K8s API 服务器执行服务发现，其优点是可集成“现有” K8s 平台。但也有一个缺点，即只适用于 Node Port 服务，不适用于 ClusterIP 服务。 

Consumer	使用者
app	应用
Cluster 1 Cluster 2	Cluster 1 Cluster 2

分布式云在此架构中未托管任何工作负载，但它会将您的服务暴露到本地网络、远程站点或互联网上。在图中，我想要展示一个从远程站点（和/或互联网）访问的 Web 应用，其中源池是在 K8s Cluster中发现的 NodePort 服务。

架构 2：在 K8s Cluster中运行一个站点

创建 K8s 站点很简单，只需部署一个manifest（点击此处）即可。该文件会在Cluster中部署多个资源，这些资源一同提供 CE 的服务，并创建客户站点。这被称为“在 K8s 内部运行 CE”或“将 CE 作为 pod 运行”。CE 节点通常指的是一个小计算节点，比如一台虚拟机或一个硬件；该架构实际上是在 K8s 中运行的一组 pod 及相关资源，用于创建 分布式云 客户站点。

Consumer	使用者
app	应用
Cluster 1 Cluster 2	Cluster 1 Cluster 2

在现有Cluster内运行分布式云时，您可按 DNS 名称暴露Cluster中的服务，因为站点将从Cluster中解析这些服务。然后，您的服务可以通过 F5 分布式云平台暴露在任何地方。这类似于上述架构 1，但使用此模型，您的站点只是 K8s 中的一组 pod。这种架构的优势是能够暴露其他类型的服务（例如 ClusterIP）。 

部署到 K8s Cluster中的站点仅支持网格功能，而不支持应用栈功能（也就是说，您无法在这些 pod 上运行Cluster)。在此架构中，分布式云充当具有内置应用安全性的 K8s ingress controller（ingress 控制器）。它还支持网格功能，例如在该站点上发布其他站点的服务，在其他站点上发布该站点发现的服务。

架构 3：vK8s（Namespace-as-a-Service）

如果您使用的服务包括应用栈功能，那么您可以考虑使用架构 3 和架构 4。在这些场景中，分布式云节点会实际运行您的 k8s  工作负载。我们不再将分布式云与您的现有 K8s 平台相集成。分布式云服务就是“K8S平台”。

一种简单的运行 K8s 工作负载的方法是使用Virtual k8s (vK8s) 架构。这可称为“托管Namespace”，因为在分布式云中创建 vK8s 项目便能够在虚拟Cluster中获得单个Namespace。 

您的Namespace可以完全托管（部署到 RE 上），也可以在虚拟机 (CE) 上运行，或两者兼有。您的 kubeconfig 文件将允许通过托管 API 服务器访问Namespace。通过常规 kubectl CLI（或通过 Web 控制台），您可以创建/删除/管理 K8s 资源（Deployments、Services、Secrets、ServiceAccounts 等）并查看应用资源指标。

因此，如果您希望将工作负载部署到没有基础设施的远程区域，并希望在 F5 的 RE 中运行管理，或者如果您在多个站点中属于不同的K8SCluster，并希望通过单个集中式虚拟Cluster来管理多个 K8s Cluster，那么这将是不二之选。

CE Customer Edge	CE 客户边缘
RE Regional Edge (F5 PoP)	RE 区域边缘 (F5 PoP)
Internal Consumer	内部使用者
Public Consumer	公共使用者
With vK8s, your managed namespace can run in both F5 PoPs and/or your network sites	有了 vK8s，您的托管Namespace可在 F5 PoP 和/或网络站点中运行
app	应用

vK8s 的一些限制

在 vK8s 架构中，您没有自己的Cluster，而有一个托管Namespace。因此存在一些限制（例如，无法以 root 身份运行容器、无法绑定到特权端口或主机网络）。您无法创建 CRD、ClusterRole、PodSecurityPolicy 或Namespace，因此不支持 K8s 运维方式。简而言之，您没有托管Cluster，但有虚拟Cluster中的托管Namespace。

架构 4：mK8s（托管 K8s）

在托管 k8s（mk8s，也称为物理 K8s 或 pk8s）部署中，我们有一个企业级 k8s 发行版运行在您的站点上。这意味着您可以使用分布式云来部署/管理/升级 K8s 基础架构，但需要管理 Kubernetes 资源。其优势包括第三方 K8s 管理解决方案的常见好处，以及一些关键优势：

• 支持多云，提供面向 Azure、亚马逊云科技和 GCP 环境的自动化能力
• 作为 SaaS 使用
• 原生企业级流量控制
• 可使用单个 K8s 管理接口对任意数量的托管Cluster进行逻辑管理

您可针对本地Cluster启用 kubectl 访问并禁用托管 API 服务器，这样您的 kubeconfig 文件便可指向全局 URL 或本地端点。

mK8s 的另一个优势在于，您在站点上运行的是完整的 K8s Cluster，而不仅仅是虚拟Cluster中的一个Namespace。vK8s 上存在的限制（见上文）不适用于 mK8s，因此您可以根据需要运行特权 pod，使用利用 ClusterRole 和 CRD 的运维方式，并执行其他需要Cluster范围访问的任务。

CE Customer Edge	CE 客户边缘
RE Regional Edge (F5 PoP)	RE 区域边缘 (F5 PoP)
Internal Consumer	内部使用者
Public Consumer	公共使用者
With vK8s, With mK8s, 分布式云 deploys and manages a cluster at your site. A large and arbitrary number of managed clusters can be logically grouped into a virtual site with a single Kubernetes management interface.	有了 vK8s 和 mK8s，分布式云 可在您的站点部署和管理Cluster。可使用单个 Kubernetes 管理接口将任意数量的托管Cluster按逻辑分组到一个虚拟站点中。
app	应用

使用 mK8s 进行流量管理控制

由于您的工作负载在由分布式云管理的Cluster中运行，因此与早期架构中的非托管Cluster相比，我们可以对 K8s 流量应用更复杂的原生策略：

• 服务隔离可在Cluster内实施，因此默认情况下，特定Namespace中的 pod 无法与该Namespace外部的服务通信。
• 我们提供更多的 service 到 service 控制，因此您可以更精细地控制哪些服务可以与其他服务进行通信。
• 对Cluster外部访问的出向控制可通过Namespace、labels、IP 范围或其他方法原生实施。例如：Svc A 可以访问 myapi.example.com，但不可以访问其他互联网服务。
• 通常应用于网络防火墙、WAF 等位置的所有相关策略（WAF 策略、Bot 防御、三层/四层策略等）均可在平台内原生应用。

我花了很长时间才理解这个架构，又用了更长时间方充分认识到它的优势。但是，一旦您在考虑连接到全球骨干网，并能够在平台内执行网络和应用程序交付的托管 K8s 平台上本地的运行您的工作负载，安全性和流量管理优势就变得非常引人注目。

总结：

随着 K8s 的不断扩展，您的Cluster管理解决方案需要确保 K8s 服务的安全，无论这些服务是由分布式云管理还是存在于不同的Cluster中。借助F5 分布式云服务的全球平台部署，而非由您管理的单一Cluster部署，上述几种不同架构可适应如今多样的（不断变化的） K8s 运行方式。