使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡-阿里云开发者社区

使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡

2017-10-11 3473

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

应用型负载均衡 ALB，每月750个小时 15LCU

传统型负载均衡 CLB，每月750个小时 15LCU

网络型负载均衡 NLB，每月750个小时 15LCU

简介： 本文讲的是使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡【编者的话】本文描述了由 NGINX 和 NGINX Plus 实现的 Ingress Controller，完全支持了 Ingress 特性，使用 Ingress 将外部流量负载到集群内的服务，并提供了扩展来支持额外的负载均衡需求。

本文讲的是使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡【编者的话】本文描述了由 NGINX 和 NGINX Plus 实现的 Ingress Controller，完全支持了 Ingress 特性，使用 Ingress 将外部流量负载到集群内的服务，并提供了扩展来支持额外的负载均衡需求。

运行和管理跨机器集群的大规模的容器微服务应用是一个极具挑战的任务。 Kubernetes 提供了一个强大的容器编排解决方案，从而帮助我们迎接这个挑战。它包含了一些重要特性，比如容错，自动伸缩，滚动升级，存储，服务发现，以及负载均衡。

本文讲解了如何使用开源 NGINX 软件或者 NGINX Plus ，以及 Ingress 这个 Kubernetes 自带的负载均衡框架，对 HTTP 流量进行负载均衡。Ingress 能让我们配置规则，从而控制外部流向 Kubernetes 集群内的服务的流量。你可以选择任何能提供 Ingress controller 的负载均衡器，Ingress controller 指的是部署在集群内的软件，它使得 Kubernetes 和负载均衡器融为一体。这里我们将展示如何利用 Ingress 以及我们之前介绍过的 NGINX Plus Ingress controller 和 NGINX Ingress controller ，对一个微服务应用进行负载均衡。

本文只介绍使用 Ingress 对 Kubernetes 进行 HTTP 的负载均衡，要学习更多有关其它负载均衡的选项，请看另一片博文：使用 NGINX Plus 对 Kubernetes 服务进行负载均衡。

注意：文中讨论的程序的完整指令，可在我们的 GitHub 仓库上找到。本文不会遍历所有必要步骤，而是只提供那些步骤的链接。

NGINX 和 NGINX Plus 的 Ingress Controllers

在我们部署示例应用并为它配置负载均衡前，我们必须选择一个负载均衡器并部署相应的 Ingress controller。

一个 Ingress controller 是能将一个特定的负载均衡器和 Kubernetes 整合在一起的软件。我们已经为开源的 NGINX 和 NGINX Plus 开发了相应的 Ingress controller，它们可在我们的 GitHub 仓库取到。其它实现也有，你可以去 Kubernetes GitHub 仓库上的 Ingress Controllers 页面了解。

关于集群内部署 NGINX Plus Ingress controller 的完整命令，可以去我们的 GitHub 仓库查看。

微服务示例应用

我们的示例应用是一个典型的微服务 web 应用，它由多个独立部署的服务组成。这个名叫 cafe 的应用，可通过 tea 服务订购茶叶，或者通过 coffee 服务订购咖啡。你可以通过 HTTP 请求的 URI 来表明你的饮料偏好：以 /tea 结尾的 URI 将提供茶叶，以 /coffee 结尾的 URI 将提供咖啡。这个应用必须通过 SSL/TLS 进行安全连接。

下图从概念上描述了整个应用，图中 NGINX Plus 这个负载均衡器扮演了一个重要角色，它路由客户端请求到合适的服务，并保证了安全的客户端连接。

集群内如何部署这个应用，请参考我们的 GitHub 仓库上的命令。

通过 Ingress 配置 Kubernetes 的负载均衡

我们的 cafe 应用要求负载均衡器提供两个功能：

基于请求的 URI 来路由（也叫基于路径的路由）
SSL/TLS 终端

用 Ingress 来配置负载均衡，你得在 Ingress 资源 里配置规则。这些规则指定如何路由外部流量到集群内的服务。

在资源内你可以定义多个虚拟服务器，每个服务器对应不同的域名。一个虚拟服务器通常对应集群内的一个单一微服务应用。对每个服务器，你可以：

指定多个基于路径的规则。流量基于请求URI 发送到应用内的不同服务。
通过引用一个SSL/TLS证书和密钥来建立SSL/TLS终端。

你可以在 Ingress 文档页面上查看更多详细解释的例子。

下面是 cafe 应用的 Ingress 资源文件（ cafe-ingress.yaml ）：

1. apiVersion: extensions/v1beta1
2. kind: Ingress
3. metadata:
4.  name: cafe-ingress
5. spec:
6.  tls:
7.  - hosts:
8.    - cafe.example.com
9.    secretName: cafe-secret
10.  rules:
11.  - host: cafe.example.com
12.    http:
13.      paths:
14.      - path: /tea
15.        backend:
16.          serviceName: tea-svc
17.          servicePort: 80
18.      - path: /coffee
19.        backend:
20.          serviceName: coffee-svc
21.          servicePort: 80

一行一行过，我们看到：

第 4 行我们命名该资源为 cafe-ingress。
第6-9行我们建立SSL/TLS终端：
- 第 9 行我们通过名字 cafe-secret 来引用一个 Secret 资源。这个资源包含SSL/TLS证书和密钥，并且必须在Ingress 资源前部署。
- 第8 行我们把这个证书和密钥用到我们的 cafe.example.com 这个虚拟服务器上。
第 11 行我们定义了一个虚拟服务器，域名为 cafe.example.com。
第 13-21 行我们定义了两个基于路径的规则：
- 第 14-17 行定义的规则要求负载均衡器分发带 /tea URI 的请求到 tea 服务的容器内，这个服务以tea-svc 名字部署在集群内。
- 第 18-21 行定义的规则要求负载均衡器分发带 /coffee URI 的请求到 coffee 服务的容器内，这个服务以 coffee-svc 名字部署在集群内。
- 两条规则都要求负载均衡器分发请求到对应服务的80端口上。

集群内部署 Ingress 和 Secret 资源的完整命令，请参考 GitHub仓库。

测试这个应用

一旦部署完NGINX Plus Ingress controller，我们自己的应用，Ingress 资源，以及 Secret 资源，我们可以测试这个应用。

当我们以 /tea URI 发送一个 tea 请求，我们可以在浏览器上看到由 tea 服务生成的页面。

我们希望你没有太失望，因为 tea 和 coffee 服务没有真的给你对应的饮料，而仅仅是显示了容器运行的信息，以及你的请求的细节。它们包含了容器的主机名和IP地址，请求的URI，以及客户端的 IP 地址。每一次我们刷新页面，我们会从不同的容器里得到响应。

我们也可以连接到 NGINX Plus 的实时活动监控页面，看到 NGINX Plus 和我们应用的每个容器的实时监控维度。

Ingress Controller 的扩展

Ingress 提供了基本的 HTTP 负载均衡功能。但是通常你的应用的负载需求更复杂，Ingress 无法支持。为了满足这些需求，我们为 ingress controller 添加了一系列扩展。通过这种方式你可以仍然充分利用Kubernetes的资源来配置负载均衡（反对直接配置负载均衡器），同时利用这些能力来使用高级负载均衡特性。

当前，我们为我们的Ingress controller 提供了以下扩展：

WebSocket，它允许我们负载均衡 WebSocket 应用。
会话保持（只有 NGINX Plus 支持），它确保来自给定客户端的请求将总是被发送到相同的后端容器。

关于可用扩展的完整列表，请查看我们的 GitHub仓库。

除此以外，我们提供了一个机制来定制 NGINX 配置，它依赖 Kubernetes 资源，要通过 Config Maps 资源或者注解（Annotations）实现。例如，你可以定制指令 proxy_connect_timeout 或者 proxy_read_timeout 的值。

当你的负载均衡需求超出了Ingress 和我们的扩展的支持范围，我们推荐一种不同的方式来部署和配置NGINX Plus ，它不使用 Ingress controller。请参考博文使用 NGINX Plus进行 Kubernetes 服务的负载均衡找到更多细节。

NGINX Plus Controller 的优点

NGINX Plus controller 除了拥有 NGINX controller 的优点外，还提供以下好处：

高动态环境中的稳定性 - 每当通过 Ingress 暴露的服务，它的一系列 pod 有一些变化时，Ingress controller 需要更新 NGINX 或者 NGINX Plus 的配置来反应这些变化。使用开源 NGINX，你必须手工修改这些配置文件并重新加载这些配置。使用 NGINX Plus，你可以使用立即重新配置（on-the-fly reconfiguration）API 来更新这些配置，而不用重新加载这些配置文件。这可以防止潜在的内存使用率的提升，以及当非常频繁得重载配置的时候，整个系统超载的发生。
实时的统计数据 - NGINX Plus 提供了高级的实时统计数据，你可以通过 API 或者内嵌的页面访问。它可以使你深入了解 NGINX Plus 和你的应用是如何工作的。
会话保持 - 当你开启会话保持功能，NGINX Plus 将使用粘性cookie（sticky cookie）方法确保所有来自同一客户端的请求总是被发送到同一个后端容器。
技术支持 - NGINX 公司的专业服务团队可以提供关于 NGINX 和 NGINX Plus 的 Ingress controller 的帮助。

总结

Kubernetes 提供了内建的 HTTP 负载均衡，使用 Ingress 将外部流量负载到集群内的服务。NGINX 和 NGINX Plus 整合了 Kubernetes 的负载均衡，完全支持了 Ingress 特性，并提供了扩展来支持额外的负载均衡需求。

要尝试 NGINX Plus 和 Ingress controller，请现在开始你的免费 30 天之旅，或者联系我们获取现场演示。

原文链接：NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing（翻译：池剑锋）

原文发布时间为：2017-02-10

本文作者：池剑锋

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：使用 NGINX 和 NGINX Plus 的 Ingress Controller 进行 Kubernetes 的负载均衡