【编者的话】本文描述了由 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 仓库 上找到。本文不会遍历所有必要步骤,而是只提供那些步骤的链接。
在我们部署示例应用并为它配置负载均衡前,我们必须选择一个负载均衡器并部署相应的 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 仓库 上的命令。
我们的 cafe 应用要求负载均衡器提供两个功能:
用 Ingress 来配置负载均衡,你得在 Ingress 资源 里配置规则。这些规则指定如何路由外部流量到集群内的服务。
在资源内你可以定义多个虚拟服务器,每个服务器对应不同的域名。一个虚拟服务器通常对应集群内的一个单一微服务应用。对每个服务器,你可以:
你可以在 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
一行一行过,我们看到:
集群内部署 Ingress 和 Secret 资源的完整命令,请参考 GitHub仓库 。
一旦部署完NGINX Plus Ingress controller,我们自己的应用,Ingress 资源,以及 Secret 资源,我们可以测试这个应用。
当我们以 /tea URI 发送一个 tea 请求,我们可以在浏览器上看到由 tea 服务生成的页面。
我们希望你没有太失望,因为 tea 和 coffee 服务没有真的给你对应的饮料,而仅仅是显示了容器运行的信息,以及你的请求的细节。它们包含了容器的主机名和IP地址,请求的URI,以及客户端的 IP 地址。每一次我们刷新页面,我们会从不同的容器里得到响应。
我们也可以连接到 NGINX Plus 的 实时活动监控 页面,看到 NGINX Plus 和我们应用的每个容器的实时监控维度。
Ingress 提供了基本的 HTTP 负载均衡功能。但是通常你的应用的负载需求更复杂,Ingress 无法支持。为了满足这些需求,我们为 ingress controller 添加了一系列扩展。通过这种方式你可以仍然充分利用Kubernetes的资源来配置负载均衡(反对直接配置负载均衡器),同时利用这些能力来使用高级负载均衡特性。
当前,我们为我们的Ingress controller 提供了以下扩展:
关于可用扩展的完整列表,请查看我们的 GitHub仓库 。
除此以外,我们提供了一个机制来 定制 NGINX 配置 ,它依赖 Kubernetes 资源,要通过 Config Maps 资源或者注解(Annotations)实现。例如,你可以定制指令 proxy_connect_timeout 或者 proxy_read_timeout 的值。
当你的负载均衡需求超出了Ingress 和我们的扩展的支持范围,我们推荐一种不同的方式来部署和配置NGINX Plus ,它不使用 Ingress controller。请参考博文 使用 NGINX Plus进行 Kubernetes 服务的负载均衡 找到更多细节。
NGINX Plus controller 除了拥有 NGINX controller 的优点外,还提供以下好处:
Kubernetes 提供了内建的 HTTP 负载均衡,使用 Ingress 将外部流量负载到集群内的服务。NGINX 和 NGINX Plus 整合了 Kubernetes 的负载均衡,完全支持了 Ingress 特性,并提供了扩展来支持额外的负载均衡需求。
要尝试 NGINX Plus 和 Ingress controller,请现在开始你的 免费 30 天之旅 ,或者 联系我们 获取现场演示。
原文链接: NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing (翻译:池剑锋)