Kubernetes上的负载均衡详解
Rancher 1.6是Docker和Kubernetes的容器编排平台,为负载均衡提供了功能丰富的支持。在Rancher 1.6中,用户可以通过使用开箱即用的HAProxy负载均衡器,来提供基于HTTP / HTTPS / TCP主机名/路径的路由。
而在本文中,我们将探讨如何在原生使用Kubernetes进行编排的Rancher 2.0平台上实现这些流行的负载均衡技术。
Rancher 2.0 负载均衡功能
通过Rancher 2.0,用户可以开箱即用地使用由NGINX Ingress Controller支持的原生Kubernetes Ingress功能进行7层负载均衡。因为Kubernetes Ingress仅支持HTTP和HTTPS协议,所以目前如果您使用的是Ingress支持,那么负载均衡仅限于上述这两种协议。
对于TCP协议,Rancher 2.0支持在部署Kubernetes集群的云上配置第4层TCP负载均衡器。后文中我们还将介绍如何通过ConfigMaps为TCP均衡配置NGINX Ingress Controller。
HTTP/HTTPS 负载均衡功能
在Rancher 1.6中,您添加了端口/服务规则以配置HAProxy负载均衡器,以均衡目标服务。您还可以配置基于主机名/路径的路由规则。
例如,下面让我们来看看一个在Rancher 1.6上启动了两个容器的服务。启动的容器正在监听私有80端口。
Rancher 2.0 Ingress Controller部署
Ingress只是一种规则,控制器组件会将这一规则应用于实际负载均衡器中。实际负载均衡器可以在集群外部运行,也可以在集群中部署。
通过RKE(Rancher Kubernetes安装程序),Rancher 2.0让用户可以开箱即用地在配置的集群上部署NGINX Ingress Controller和负载均衡器,以处理Kubernetes Ingress规则。请注意,NGINX Ingress Controller默认安装在RKE配置的集群上。通过云提供商(如GKE)配置的集群具有自己的Ingress Controller来配置负载均衡器。本文的范围仅适用于使用RKE安装的NGINX Ingress Controller。
RKE将NGINX Ingress Controller部署为Kubernetes DaemonSet——因此NGINX实例会部署在集群中的每个节点上。NGINX就像一个Ingress Controller,在整个集群中监听Ingress创建,它还会将自身配置为满足Ingress规则的负载均衡器。DaemonSet配置有hostNetwork以暴露两个端口——端口80和端口443。有关如何部署NGINX Ingress Controller DaemonSet和部署配置选项的详细信息,请参阅此处:
https://rancher.com/docs/rke/v ... lers/
如果您是Rancher 1.6用户,那么将Rancher 2.0 Ingress Controller以DaemonSet的形式部署,会带来一些你需要知悉的重要的改变。
在Rancher 1.6中,您可以在堆栈中部署可扩展的负载均衡器服务。因此,如果您在Cattle环境中有四台主机,则可以部署一台规模为2的负载均衡器服务,并通过端口80在这两个主机IP地址上指向您的应用程序。然后,您还可以在剩余的两台主机上启动另一台负载均衡器,以通过端口80再次均衡不同的服务(因为负载均衡器使用不同的主机IP地址)。
Rancher 2.0允许您添加基于主机名或URL路径的Ingress规则。根据您的规则,NGINX Ingress Controller将流量路由到多个目标工作负载。下面让我们看看如何使用相同的Ingress规范将流量路由到命名空间中的多个服务。比如如下两个在命名空间中部署的工作负载:
Rancher 2.0 Ingress功能还支持HTTPS协议。您可以在配置Ingress规则时上载证书并使用它们,如下所示:
尽管Rancher 2.0支持HTTP- / HTTPS-基于主机名/路径的负载均衡,但要突出的一个重要区别是在为工作负载配置Ingress时需要使用唯一的主机名/路径。原因是Ingress功能仅允许将端口80/443用于路由,负载均衡器和Ingress Controller则可作为DaemonSet全局启动。
从最新的Rancher 2.x版本开始,Kubernetes Ingress不支持TCP协议,但我们将在下一节中讨论使用NGINX Ingress Controller的解决方法。
TCP负载均衡选项
- 四层负载均衡器
对于TCP协议,Rancher 2.0支持在部署Kubernetes集群的云提供程序中配置四层负载均衡器。为集群配置此负载均衡器设备后,Layer-4 Load Balancer在工作负载部署期间选择for port-mapping 选项时,Rancher会创建Load Balancer服务。此服务会让Kubernetes的相应云提供商配置负载均衡器设备。然后,此设备将外部流量路由到您的应用程序pod。请注意,上述功能需要该Kubernetes云提供商满足负载均衡器服务的要求,按此文档配置:
https://rancher.com/docs/ranch ... ders/
- 通过ConfigMaps支持NGINX Ingress Controller TCP
如上所述,Kubernetes Ingress本身不支持TCP协议。因此,即使TCP不是NGINX的限制,也无法通过Ingress创建来配置NGINX Ingress Controller以进行TCP负载均衡。
但是,您可以通过创建一个Kubernetes ConfigMap,来使用NGINX的TCP负载均衡功能,具体可参阅这里: https://github.com/kubernetes/ ... es.md 。您可以创建Kuberenetes ConfigMap对象,来将pod配置参数存储为键值对,与pod镜像分开,更多细节可以参考这里:
https://kubernetes.io/docs/tas ... gmap/
要配置NGINX以通过TCP暴露服务,您可以添加或更新命名空间tcp-services中的ConfigMap ingress-nginx。此命名空间还包含NGINX Ingress Controller pod。
将这些条目添加到Configmap,将自动更新NGINX pod,以配置这些工作负载来进行TCP负载均衡。您可以执行部署在ingress-nginx命名空间中的这些pod,并查看如何在/etc/nginx/nginx.conf文件中配置这些TCP端口。<NodeIP>:<TCP Port>在NGINX配置/etc/nginx/nginx.conf更新后,应该可以使用公开的工作负载。如果它们不可访问,则可能必须使用NodePort服务来暴露TCP端口。
Rancher 2.0负载均衡的限制
Cattle提供了功能丰富的负载均衡器支持(详细介绍在此: https://rancher.com/docs/ranch ... ncers )。其中一些功能在Rancher 2.0中暂时没有等效功能:
当前NGINX Ingress Controller不支持SNI。
TCP负载均衡需要集群中的云提供程序启用的负载均衡器设备。Kubernetes上没有对TCP的Ingress支持。
只能通过Ingress为端口80/443配置HTTP / HTTPS路由。此外,Ingress Controller作为Daemonset进行全局部署,而不是作为可扩展服务启动。此外,用户无法随机分配外部端口来进行负载均衡。因此,用户需要确保它们配置的主机名/路径组合是唯一的,以避免使用相同的两个端口发生路由冲突。
无法指定端口规则优先级和排序。
Rancher 1.6增加了对draining后端连接和drain超时的支持。Rancher 2.0暂不支持此功能。
目前在Rancher 2.0中,不支持指定自定义粘性策略和自定义负载均衡器配置以附加到默认配置。原生Kubernetes对此有一定的支持,不过也只限于定制NGINX配置:
https://kubernetes.github.io/i ... ADME/ 。
将负载均衡器配置从Docker Compose迁移到Kubernetes YAML?
Rancher 1.6通过启动自己的微服务提供负载均衡器支持,该微服务启动并配置了HAProxy。用户添加的负载均衡器配置在rancher-compose.yml文件中指定,而不是标准的docker-compose.yml。Kompose工具适用于标准的docker-compose参数,但在本文的情况下,是无法解析Rancher负载均衡器配置结构的。截至目前,我们暂时无法使用Kompose工具将负载均衡器配置从Docker Compose转换为Kubernetes YAML。
结 论
由于Rancher 2.0基于Kubernetes并使用NGINX Ingress Controller(与Cattle使用HAProxy相比),因此原先Rancher 1.6中Cattle支持的一些负载均衡器的功能目前暂时没有直接等效功能。但是,Rancher 2.0支持流行的HTTP / HTTPS基于主机名/路径的路由,这种路由最常用于实际部署。还通过Kubernetes Load Balancer服务使用云提供商提供四层(TCP)支持。2.0中的负载均衡功能也具有类似的直观UI体验。
Kubernetes生态系统在不断发展,我相信我们能找到更多适合所有负载均衡细微差别的解决方案!
本文转自DockOne-Kubernetes上的负载均衡详解
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
选择Serverless还是Kubernetes?这种争辩并没有意义
这篇文章作者分别阐述了Kubernetes与Serverless的优缺点,实际上两者可能并不是竞争关系,在某些架构中,两者可以同时存在以满足不同的需求。但是最终的目的都是为了使应用程序部署更方便快捷,更易管理,更具成本效益以及对开发人员友好。 Kubernetes和Serverless都是令人兴奋的强大的平台,它们可以通过多种方式为企业在敏捷性,扩展性以及计算性能上获取巨大的提升。但是,不要忘记Kubernetes能提供一些Serverless所没有的功能,反之亦然。成功部署其中任何一个方案的关键点在于哪种技术更适用于当前的场景。 Kubernetes的兴起 Kubernetes是为大规模的云计算设计的,一开始就是因为Google使用了超大规模的部署才开发了Kubernetes。之后Kubernetes被改造成可以小规模使用,并且适用于大多数大型云提供商,这归功于它过去几年迅猛的发展。根据Cloud Native Computing Foundation(CNCF)的用户调查,Kubernetes的增长远超过所有其他形式的编排软件。 自首次亮相以来,Kubernetes已成为主流。但是...
- 下一篇
Linkerd 2.0迎来更新,向着Kubernetes再进一步
Linkerd社区对自身服务网格平台进行一轮最新更新,旨在进一步提高开发人员与服务拥有者的效率,同时与持续发展的Kubernetes生态系统实现紧密集成。另外,此次更新还为Linkerd在日益拥挤的服务网格领域中争取到一些喘息空间。 Bouyant公司CEO兼Linkerd社区初始开发者之一William Morgan表示,2.0版本最重要的特征就在于基础代码库进行了完全重写,且更加注重对服务网格部署的简化。 此次重写将控制层由JVM编程语言变更为Go编程语言。Morgan表示,与此前的迭代相比,这轮大规模调整使得Linkerd 2.0“体积更小,而速度更快。” 除了性能优势之外,转向Go语言还令Linkerd与Kubernetes生态系统更为接近。Morgan指出,“我们的大多数用户都身在Kubernetes阵营,因此我们希望尽早解决这个问题。” Morgan解释称,除了与Kubernetes生态系统相结合之外,Go编程语言也“更容易上手”,并将推动这套平台迎来更为重大的创新。Linkerd与Kubernetes亦同属于云原生计算基金会(简称CNCF)生态系统中的组成部分。 服务边挂...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS7设置SWAP分区,小内存服务器的救世主