Kubernetes 外部流量引入: ClusterIp、NodePort、LoadBalancer 和 Ingress
背景
今天，我被问到了一个从测试初期遇到的最常见问题之一开始： 如何将外部流量路由到我的 Kubernetes 服务？ 当我们的客户开始探索 Kubernetes 时，这个问题出现了很多次，当我试图回答这个问题时，我意识到问题的一部分在于可能答案的数量 以及理解它们所需的概念。
与这个问题相关的是一个功能请求：大多数用户想要一个负载平衡工具。由于测试阶段的重点是确认产品的稳定性和验证功能集优先级，因此我们能够快速确认 LoadBalancer 这是我们第一个商业版本的关键功能。
为了更好地回答外部流量问题，也为了更 LoadBalancer 容易采用，我们编写了一个教程并添加了一些图纸，得到了很好的反馈。这有助于人们理解 Kubernetes 上外部流量路由的概念。
概念：ClusterIP、 NodePort、 Ingress 和 LoadBalancer
当您开始将 Kubernetes 用于实际应用程序时，首先要问的问题之一是如何将外部流量引入集群。官方文档 对该主题提供了全面（但相当枯燥）的解释，但在这里我们将以更实用、需要了解的方式进行解释。
有多种方法可以将外部流量路由到集群中：
-
使用
Kubernetes kubectl proxy和ClusterIP：默认Kubernetes ServiceType是ClusterIp，它Service在集群内部 IP 上公开 。要从外部源访问ClusterIp，您可以在外部源和集群之间打开 Kubernetes 代理。这通常仅用于开发。 -
将服务公开为
NodePort：将 a 声明 Service 为NodePort将其公开在每个节点的 IP 上的静态端口（称为 NodePort）。然后，您可以Service 通过请求从集群外部 访问<NodeIp>:<NodePort>.这也可以用于生产，尽管有一些限制。 -
将服务公开为
LoadBalancer： 使用云提供商的负载均衡器解决方案将服务声明Service 为 将其公开到外部。LoadBalancer云提供商将为 提供负载平衡器Service，并将其映射到自动分配的NodePort。这是生产环境中使用最广泛的方法。
使用 Kubernetes kubectl proxy 和 ClusterIP
默认的 Kubernetes ServiceType 是 ClusterIp，它 Service 在集群内部 IP 上公开。要从外部计算机访问 ClusterIp ，您可以在外部计算机和集群之间打开 Kubernetes 代理。
您可以使用它 kubectl 来创建这样的代理。当代理启动时，您将直接连接到集群，并且可以使用内部 IP (ClusterIp) Service。
此方法不适合生产环境，但对于开发、调试和其他快速而肮脏的操作很有用。
此方法不适合生产环境，但对于开发、调试和其他快速执行的后门操作的很有用。
将服务公开为 NodePort
将服务声明为 NodePort 会公开 Service 每个节点的 IP NodePort （该端口的固定端口 Service，默认范围为 30000-32767）。然后，您可以 Service 通过请求从集群外部 访问 <NodeIp>:<NodePort>.您部署的每个服务都 NodePort 将在每个节点上的其自己的端口中公开。
在生产中使用NodePort起来相当麻烦 。Services当您使用非标准端口时，您通常需要设置一个外部负载均衡器来侦听标准端口并将流量重定向到 :.
将服务公开为 LoadBalancer
声明类型的服务会 LoadBalancer 使用云提供商的负载均衡器将其公开。云提供商将为 提供负载平衡器 Service，并将其映射到自动分配的 NodePort。来自外部负载均衡器的流量如何路由到 Service Pod 取决于集群提供商。
这 LoadBalancer 是生产环境的最佳选择，但有两个注意事项： 1.Service 您部署的 每一个 都LoadBalancer 将获得它自己的IP。 2.通常 LoadBalancer 根据公开服务的数量进行计费，这可能会很昂贵。
将服务套一层代理： Ingress
根据 官方文档， Ingress 是一个API对象，用于管理对集群中服务的外部访问（通常是HTTP, TCP也可以需要设置为4层）。那么 ingress 和LoadBalancer、NodePort 之间有什么区别？
Ingress 不是 的类型 Service，而是一个对象Provider，充当 反向代理 和集群的单个入口点，将请求路由到不同的服务。最基本的 Ingress 是 NGINX 入口控制器，NGINX 承担反向代理的角色，同时也充当 SSL。
ClusterIP Ingress 通过Kubernetes 代理； NodePort或 暴露于集群外部； LoadBalancer并根据配置的规则路由传入流量；
Ingress 在 LoadBalancer 后面，使用 LoadBalancer 的主要优点： LoadBalancer 是成本：可以在单个 LoadBalancer.
我应该使用哪一个？
好吧，这是一个价值一百万美元的问题，而且根据你问的对象不同，这个问题可能会引起不同的回复！
您可以 100% 全力以赴 ， 为每项服务LoadBalancer配备专人 。LoadBalancer从概念上讲，它很简单：每个服务都是独立的，不需要额外的配置。缺点是价格（您需要为 LoadBalancer 每一项服务付费），而且管理大量不同 IP 也很困难。
您也可以仅使用一个 LoadBalancer 和 Ingress 后面的一个。您的所有服务都将位于同一 IP 下，每个服务都位于不同的路径中。这是一种更便宜的方法，因为您只需支付一个费用 LoadBalancer，但如果您的服务没有逻辑关系，它很快就会变得混乱。
如果您想要我的个人意见，我会尝试结合使用两者……
我个人推荐的一种方法是：
LoadBalancer 为每个相关的服务集/不同租户建立一个 ，然后 Ingress使用 LoadBalancer.
例如，假设您有两个不同的基于微服务的 API，每个 API 都包含大约 10 个服务。我会 为每个 API 将一个LoadBalancer放在一个前面 ，作为单个公共入口点，并将流量路由到 API 的不同服务。IngressLoadBalancerIngress
其他
「如果这篇文章对你有用,请随意打赏」
如果这篇文章对你有用,请随意打赏
使用微信扫描二维码完成支付
