纠删码计算器
参考硬件
使用弹性负载均衡器在 AWS EKS 中公开 MinIO 服务：概述
MinIO 可以部署在各种场景中，以满足您组织的对象存储需求。MinIO 在所有主要的 Kubernetes 平台上提供软件定义的高性能对象存储系统，包括Tanzu、Azure、GCP、OpenShift和SUSE Rancher。
对于 MinIO，Elastic Kubernetes Services (EKS) 非常适合在 AWS 公共云中运行的工作负载。MinIO 与 Amazon EKS 服务原生集成，使您能够使用 AWS 的基础设施将您自己的大规模多租户对象存储作为服务或多云数据湖库运行。MinIO 是 AWS S3 存储即服务的完全替代品，在 AWS 内部以及内部部署和/或其他云（公共、私有、边缘）运行。
在 EKS 上运行 MinIO 的挑战之一是将其 Kubernetes 服务暴露给对象存储 API 的消费者，并将 UI 暴露给 Kubernetes 集群外部的用户和应用程序，无论是使用虚拟私有云 (VPC) 在 AWS 内部还是在互联网外部一般来说。
在本指南中，我们将描述公开 MinIO 服务的每种方法（Classic Load Balancer、NGINX、Application Load Balancer 和 Network Load Balancer）的优缺点。然后，我们将提供一个后续帖子，其中包含有关公开 MinIO 服务的过程的更多详细信息。
本指南的目标是描述如何在 EKS 中公开 MinIO 服务，并确定何时选择一种入口或负载均衡器而不是另一种。
Kubernetes 原生的应用暴露方式
将在 Kubernetes 集群内运行的应用程序和服务暴露给内部和外部应用程序的实际方法是使用services和ingress。
创建服务时，我们需要将其指定为类型，类型将决定流量如何路由到应用程序。
ClusterIP（默认）
上图显示了此架构的示例。当流量仅在 Kubernetes 集群内部时，这是理想的负载平衡类型。该服务在 Kubernetes 中分配了一个内部 IP 地址。在上图中，它是 1.1.1.1，Service ClusterIP 接收到的任何流量都被转发到网络 10.10.10.x 上的下方 pod。
节点端口
使用 NodePort，在集群节点上打开相同的端口（在 30,000 到 32767 的范围内）。
节点在指定端口上接收到的任何流量都将转发到服务，这是公开服务的最简单方法。缺点是每个端口只能提供一项服务。
如果你的节点的 IP 地址发生变化，或者 NodePort 配置发生变化，那么你将需要在客户端处理这些变化。
负载均衡器
此方法在公共云平台中创建一个负载均衡器，对于 AWS EKS 来说它是一个Classic Load Balancer。在裸机集群中 LoadBalancer 不可用，您可以使用MetalLB作为负载平衡的一种方式。
将为每个服务创建一个不同的负载平衡器，并且没有选项可以像路径或主机名路由一样进行智能路由。
入口
Ingress 不是一种服务类型，它是另一种 Kubernetes 原生资源，将 HTTP 流量从 Kubernetes 集群外部转发到内部服务。
Ingress 允许智能路由，这意味着我们可以使用相同的 Ingress 负载均衡器使用路径或主机名甚至组合为多个服务路由流量。
ingress 的另一个优点是我们可以在 ingress 负载均衡器中进行 TLS 终止。但是，ingress 需要在集群中安装 一个ingress 控制器。这是 Kubernetes 中可用的入口控制器列表。
Ingress 和与之关联的服务是受命名空间限制的资源，这意味着需要在命名空间a中为命名空间a中的资源创建一个 Ingress 。一个自然的缺点是单个入口资源无法跨命名空间路由资源流量——对于安全意识来说，这可能被视为一个优势，因为它隔离了资源。命名空间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 服务需要设置负载均衡器或 Ingress 来公开服务。有很多方法可以在 AWS EKS 上完成此操作：
N ginx 入口
经典负载均衡器
应用程序负载均衡器入口
网络负载均衡器
它们都允许从 Kubernetes 集群外部访问 MinIO 服务。但是，每个选项在允许的功能数量及其限制方面有所不同。出于这个原因，您会根据您的系统及其体系结构所规定的需求来选择一个而不是另一个。
我们制作了一个方便的比较图表，以便您了解您的选择。所有这些都将起作用，由您决定哪个具有您的环境所需的选项。有关 AWS 负载均衡器及其功能的更全面比较，请参阅 AWS 文档
以下部分将更详细地介绍每个选项并包括重要的注意事项。
运营商管理
MinIO Operator创建并确保 MinIO 租户的所需状态，而无需在集群中添加额外的控制器或授权。这是公开服务的最简单方法，并通过使用Tenant CRD的exposeServices和serviceMetadata字段来支持，稍后将详细介绍。
可通过 Kubernetes Manifest 部署
对于此功能，我们正在寻找通过 Kubernetes 清单创建负载均衡器或入口的能力。它简化了操作，是在 Kubernetes 理解和管理的清单中创建基础设施和服务配置的最佳实践。
对于每种公开服务的方式，Kubernetes 中都有不同的处理程序：
支持 HTTPS 和 TLS 终止
MinIO 服务是 HTTP 服务，作为最佳实践，应该使用 HTTPS 来加密传输中的信息。出于这个原因，您应该使用 TLS 运行 MinIO，并且用于公开 MinIO 服务的负载平衡器应该具有 TLS 证书，以保证传输中数据的端到端加密。
这是所有负载均衡器都以某种方式支持的东西，但是在自签名证书、私有 CA 颁发的证书和 AWS ACM 颁发的某些方法的证书之间存在细微差别。我们将在后续帖子中提供有关特定负载平衡和入口选项的详细信息。
负载均衡器和 Ingress 方法的比较
下面，我们准备了一个方便的列表，列出了以一种或另一种方式公开 MinIO 服务的特性和优势。
在以下情况下使用Classic Load Balancer：
需要尽可能低的对额外资源的依赖。
将在 MinIO 服务中进行 TLS 终止，当您拥有要上传到 MinIO 的自定义域证书的私钥时，为了简单起见，它是最佳选择。
仅在负载均衡器上执行 TLS 终止。
不需要端到端加密，可以承受 Kubernetes 集群内未加密的 HTTP 流量。
有关详细说明，请参阅在 EKS 上公开 MinIO 租户服务。
在以下情况下使用Nginx Ingress：
想要在 Nginx ingress 中设置 TLS 终止，并且您有自定义域证书的私钥可以存储在秘密中以供 Nginx 使用。
想要设置复杂的路由。
想要隐藏、添加或替换自定义标题。
需要一些其他 Nginx 功能。
在以下情况下使用Application Load Balancer Ingress：
想要使用 AWS Certificate Manager 颁发的证书，并且想要在负载均衡器中进行 TLS 终止。请注意，由于证书是在 AWS 上管理的，因此无法下载私钥，例如，无法在 Nginx ingress 中分配它们。
想要重用负载均衡器来路由到多个服务。AWS ALB 允许使用路径和主机名路由到多个服务，因此它有助于通过对多个服务（MinIO 控制台和 API）使用相同的负载均衡器来节省基础设施成本，而不会影响性能。
想要更好地控制负载均衡器设置，例如子网、安全组、运行状况检查等。ALB Ingress 允许通过服务注释进行高度定制。
有关详细说明，请参阅在 EKS 上公开 MinIO 租户服务。
使用网络负载均衡器以获得严格的最高性能。
NLB 是一个第 4 层代理，这意味着它必须做更少的处理，并在将流量转发到后端服务之前添加尽可能少的延迟。
NLB 应该能够在没有问题或预热的情况下处理突然出现的巨大流量峰值，相比之下，ALB 可能需要一段时间才能赶上，或者您可能需要联系 AWS 以警告预测的预期流量峰值，以便他们预热负载均衡器为你。请注意，这是流量的高峰值，想想像超级碗或黑色星期五这样的事件流量。
如果您的解决方案需要静态 IP，NLB 会为每个 AZ 提供一个静态 IP，并且还与弹性 IP 兼容，这对于 ALB 是不可能的。
自定义和高级网络拓扑
有关详细说明，请参阅在 EKS 上公开 MinIO 租户服务。
结论
MinIO 已经在公共云的数百万个节点上运行，其中 AWS 托管了最多的部署。我们通过AWS 市场中的托管应用程序为您提供便利，只需单击几下即可部署。
无论您是在 EKS 上运行还是在其他类型的 Kubernetes 上运行，托管与否，您都可能希望将 MinIO 暴露给在运行 MinIO 的 Kubernetes 集群之外运行的服务和应用程序。我们将这个由两部分组成的指南放在一起，以使用负载均衡器和入口公开 MinIO 服务。
问题或意见？在我们的Slack 社区联系我们。