使用弹性负载均衡器在 AWS EKS 中公开 MinIO 服务:概述

Exposing MinIO Services in AWS EKS Using Elastic Load Balancers: Overview

MinIO 可以部署在各种场景中,以满足您组织的对象存储需求。MinIO 提供了一个软件定义的高性能对象存储系统,涵盖所有主要的 Kubernetes 平台,包括 TanzuAzureGCPOpenShiftSUSE Rancher

对于 MinIO,Elastic Kubernetes Services (EKS) 非常适合在 AWS 公有云中运行的工作负载。MinIO 原生集成 Amazon EKS 服务,使您能够使用 AWS 的基础设施运营自己的大型多租户对象存储即服务或多云数据湖仓。MinIO 是 AWS S3 存储即服务的完整替代方案,可以在 AWS 内部以及本地和/或其他云(公有云、私有云、边缘云)中运行。

在 EKS 上运行 MinIO 的挑战之一是,如何将 Kubernetes 服务公开给对象存储 API 和 UI 的使用者,以便用户和应用程序能够在 Kubernetes 集群外部访问,无论是通过虚拟私有云 (VPC) 在 AWS 内部访问,还是在互联网上公开访问。

在本指南中,我们将描述每种公开 MinIO 服务的方法(经典负载均衡器、NGINX、应用程序负载均衡器和网络负载均衡器)的优缺点。然后,我们将提供后续文章,其中包含有关公开 MinIO 服务过程的更多详细信息。

本指南的目标是描述如何在 EKS 中公开 MinIO 服务,以及确定何时选择一种类型的入口或负载均衡器而不是另一种。

Kubernetes 原生方式公开应用程序

将 Kubernetes 集群内部运行的应用程序和服务公开给内部和外部应用程序的标准方式是使用 服务入口

创建服务时,我们需要将其指定为一种类型,而该类型将决定如何将流量路由到应用程序。

ClusterIP(默认)

上图显示了此架构的一个示例。当流量仅限于 Kubernetes 集群内部时,这是理想的负载均衡类型。服务在 Kubernetes 中分配一个内部 IP 地址。在上图中,它是 1.1.1.1,服务 ClusterIP 收到的任何流量都将转发到网络 10.10.10.x 上的下层 Pod。

NodePort

使用 NodePort,集群节点上的相同端口(在 30,000 到 32767 的范围内)将保持打开状态。

节点接收到的任何指定端口上的流量都将转发到服务,这使得它成为公开服务的最简单方法。缺点是每个端口只能使用一个服务。

如果节点的 IP 地址更改或 NodePort 配置更改,则需要处理客户端中的更改。

LoadBalancer

此方法在公有云平台上创建一个负载均衡器,对于 AWS EKS,它是一个 经典负载均衡器。在裸机集群中,LoadBalancer 不可用,您可以使用 MetalLB 作为负载均衡的方法。

每个服务将创建一个不同的负载均衡器,并且没有执行路径或主机名路由等智能路由的选项。

入口

入口不是服务类型,而是另一种 Kubernetes 原生资源,它将来自 Kubernetes 集群外部的 HTTP 流量转发到内部服务。

入口允许智能路由,这意味着我们可以使用相同的入口负载均衡器通过路径或主机名,甚至两者结合的方式,为多个服务路由流量。

入口的另一个优点是,我们可以在入口负载均衡器中执行 TLS 终止。但是,入口需要在集群中安装一个**入口控制器**。 此处 列出了 Kubernetes 中可用的入口控制器。

入口及其关联的服务是命名空间范围的资源,这意味着需要在命名空间 a 中为命名空间 a 中的资源创建入口。这有一个自然的缺点,即单个入口资源无法跨命名空间为资源路由流量——对于注重安全的人来说,这可能被视为一个优点,因为它隔离了资源。存在于命名空间 a 中的入口只能将流量路由到命名空间 a 中的服务,它无法将流量路由到命名空间 b 中的服务,有关此内容的更多详细信息,请参阅 入口规则 Kubernetes 文档

MinIO 服务和内部 DNS

MinIO 是一个 Kubernetes 原生服务。这意味着在 Kubernetes 集群内部运行的应用程序可以通过 Kubernetes 为服务提供的内部 DNS 无缝地与 MinIO 通信。假设 Kubernetes 集群 DNS 后缀cluster.local,则 DNS 将为

minio.{ tenant namespace}.svc.cluster.local for the minio API endpoint 
{tenant-name}-console.{tenant namespace}.svc.cluster.local for the tenant console UI
console.{operator namespace}.svc.cluster.local for the Operator Console UI

公开 Kubernetes 外部的 MinIO 服务

要从 Kubernetes 集群外部访问 MinIO 服务,需要设置负载均衡器或入口以公开这些服务。在 AWS EKS 上可以通过多种方式实现这一点

  • Nginx 入口
  • 经典负载均衡器
  • 应用程序负载均衡器入口
  • 网络负载均衡器

所有这些都允许从 Kubernetes 集群外部访问 MinIO 服务。但是,每个选项在允许的功能数量及其限制方面都存在差异。因此,您需要根据系统及其架构的需求选择其中一个。

我们整理了一张方便的对比图表,以便您了解您的选择。所有这些都有效,您可以根据需要选择适合您环境的选项。有关 AWS 负载均衡器及其功能的更全面比较,请参阅 AWS 文档


经典负载均衡器

Nginx 入口

ALB

入口

网络负载均衡器

负载均衡器类型

第 4 层/第 7 层

第 7 层

第 7 层

第 4 层

协议

tcp、http、https

http、https

http、https

Tcp、tls

MinIO 运算符管理



需要控制器


通过以下方式部署

Kubernetes 清单

允许使用私有 CA 签署或自签名证书用于后端



Amazon Certificate Manager 发行的证书支持


对多个服务重用单个 LB



TLS 版本

1, 1.1, 1.2

1, 1.1, 1.2, 1.3

请参阅 终止 ssl

1, 1.1, 1.2

1, 1.1, 1.2, 1.3

以下部分将更详细地介绍每个选项,并包括重要注意事项。

运算符管理

MinIO 运算符 创建并确保 MinIO 租户的所需状态,而无需在集群中添加其他控制器或权限。这是公开服务的最简单方法,并且支持使用 租户 CRDexposeServicesserviceMetadata 字段,这两个字段将在稍后详细介绍。

通过 Kubernetes 清单部署

对于此功能,我们正在寻找通过 Kubernetes 清单创建负载均衡器或入口的能力。它简化了操作,并且最佳实践是在 Kubernetes 理解和管理的清单中创建基础设施和服务配置。

对于每种公开服务的方式,Kubernetes 中都有一个不同的处理程序

替代方案

处理程序

Kubernetes 资源类型

经典负载均衡器:exposeServices

MinIO 运算符

租户 CRD

Nginx 入口

需要 Nginx 控制器 

入口

应用程序负载均衡器入口

需要 AWS 负载均衡器控制器

入口

网络负载均衡器:
exposeServices + serviceMetadata

MinIO 运算符 + AWS 负载均衡器控制器

租户 CRD

支持 HTTPS 和 TLS 终止

MinIO 服务是 HTTP 服务,最佳实践是使用 HTTPS 对传输中的信息进行加密。因此,您应该使用 TLS 运行 MinIO,并且用于公开 MinIO 服务的负载均衡器应具有 TLS 证书,以确保传输数据的端到端加密。

所有负载均衡器都以某种方式支持这一点,但是围绕自签名证书、私有 CA 发行证书和 AWS ACM 发行证书的一些方法存在细微差别。我们将在后续文章中提供有关特定负载均衡和入口选项的详细信息。

负载均衡器和入口方法的比较

下面,我们准备了一个方便的功能和优势列表,用于以一种或另一种方式公开 MinIO 服务。

当您需要以下条件时,请使用**经典负载均衡器**

  • 需要尽可能减少对额外资源的依赖。
  • 将在 MinIO 服务中执行 TLS 终止,当您拥有要上传到 MinIO 的自定义域证书的私钥时,此方法在简化方面是最优的。
  • 仅在负载均衡器上执行 TLS 终止。
  • 不需要端到端加密,并且可以在 Kubernetes 集群内承受未加密的 HTTP 流量。
  • 请参阅在 EKS 上公开 MinIO 租户服务,以获取详细说明。

当您需要以下条件时,请使用**Nginx 入口**

当您需要以下条件时,请使用**应用程序负载均衡器入口**

  • 希望使用 AWS 证书管理器发行的证书,并希望在负载均衡器中进行 TLS 终止。请注意,由于证书是在 AWS 上管理的,因此无法下载私钥,例如,将其分配到 Nginx 入口。
  • 希望重用负载均衡器来路由到多个服务。AWS ALB 允许使用路径和主机名路由到多个服务,因此它有助于通过对多个服务(MinIO 控制台和 API)使用相同的负载均衡器来节省基础设施成本,而不会影响性能。
  • 希望更好地控制负载均衡器设置,例如子网、安全组、运行状况检查等。ALB 入口允许通过服务注释进行高度自定义。
  • 请参阅在 EKS 上公开 MinIO 租户服务,以获取详细说明。

为了获得严格的最高性能,请使用**网络负载均衡器**。

  • NLB 是一个第 4 层代理,这意味着它需要执行更少的处理,并且在将流量转发到后端服务之前会添加尽可能少的延迟。
  • 与 ALB 相比,NLB 应该能够在没有问题或预热的情况下处理突然的巨大流量峰值,ALB 可能需要一段时间才能赶上,或者您可能需要联系 AWS 以警告预计的流量峰值,以便他们为您预热负载均衡器。请注意,这是流量的巨大峰值,例如超级碗或黑色星期五等活动的流量。
  • 如果您的解决方案需要具有静态 IP,则 NLB 为每个 AZ 提供静态 IP,并且还兼容弹性 IP,这在 ALB 中是不可能的。
  • 自定义和高级网络拓扑
  • 请参阅在 EKS 上公开 MinIO 租户服务,以获取详细说明。

结论

MinIO 已经在公共云中的数百万个节点上运行,其中 AWS 托管了最多的部署。我们通过AWS 市场上的托管应用程序让您轻松部署,只需点击几下即可。

无论您是在 EKS 上还是在其他版本的 Kubernetes 上运行,托管与否,您都可能希望将 MinIO 公开给在运行 MinIO 的 Kubernetes 集群外部运行的服务和应用程序。我们整理了这份分两部分的指南,用于使用负载均衡器和入口公开 MinIO 服务。

有任何问题或意见?请通过我们的Slack 社区与我们联系。