摘要:部署只是一種規則,控制器組件會將這一規則應用于實際負載均衡器中。原因是功能僅允許將端口用于路由,負載均衡器和則可作為全局啟動。負載均衡的限制提供了功能豐富的負載均衡器支持詳細介紹在此。截至目前,我們暫時無法使用工具將負載均衡器配置從轉換為。
如果您的應用程序是面向大量用戶、會吸引大量流量,那么一個不變的目標一定是在高效滿足用戶需求的同時、不讓用戶感知到任何類似于“服務器繁忙!”的情況。這一訴求的典型解決方案是橫向擴展部署,以便有多個應用程序容器可以為用戶請求提供服務。但是,這種技術需要可靠的路由功能,需要可以有效地在多個服務器之間分配流量。本文分享的內容就是要解決負載均衡解決方案的問題。
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端口。
為了均衡兩個容器之間的外部流量,我們可以為應用程序創建一個負載均衡器,如下所示。在這里,我們會配置負載均衡器,將進入端口80的所有流量轉發到目標服務的容器端口,然后Rancher 1.6在負載均衡器服務上放置了一個方便的鏈接到公共端點。
Rancher 2.0提供了一種使用非常相似的、由NGINX Ingress Controller支持的、使用Kubernetes Ingress的負載均衡器功能。下文中我們一起來看看我們該如何做。
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/...
如果您是Rancher 1.6用戶,那么將Rancher 2.0 Ingress Controller以DaemonSet的形式部署,會帶來一些你需要知悉的重要的改變。
在Rancher 1.6中,您可以在堆棧中部署可擴展的負載均衡器服務。因此,如果您在Cattle環境中有四臺主機,則可以部署一臺規模為2的負載均衡器服務,并通過端口80在這兩個主機IP地址上指向您的應用程序。然后,您還可以在剩余的兩臺主機上啟動另一臺負載均衡器,以通過端口80再次均衡不同的服務(因為負載均衡器使用不同的主機IP地址)。
Rancher 2.0 Ingress Controller是一個DaemonSet——因此它全局部署在所有可調度節點上,以便為整個Kubernetes集群提供服務。因此,在對Ingress規則進行編程時,你需要使用唯一的主機名和路徑指向工作負載,因為負載均衡器節點IP地址和端口80/443是所有工作負載的公共訪問點。
現在讓我們看看如何使用Ingress將上述1.6示例部署到Rancher 2.0上。在Rancher UI上,我們可以導航到Kubernetes Cluster和Project,并選擇【部署工作負載/Deploy Workloads】功能,在命名空間下部署所需鏡像的工作負載。讓我們將工作負載的規模設置為兩個副本,如下所示:
以下是工作負載選項卡上部署和列出工作負載的方式:
要達到這兩個pod之間的均衡,您必須創建Kubernetes Ingress規則。要創建此規則,請導航到您的集群和項目,然后選擇“ 負載均衡”選項卡。
與Rancher 1.6中的服務/端口規則類似,您可以在此處指定針對工作負載的容器端口的規則。
基于主機和路徑的路由
Rancher 2.0允許您添加基于主機名或URL路徑的Ingress規則。根據您的規則,NGINX Ingress Controller將流量路由到多個目標工作負載。下面讓我們看看如何使用相同的Ingress規范將流量路由到命名空間中的多個服務。比如如下兩個在命名空間中部署的工作負載:
我們可以使用相同的主機名但不同的路徑添加Ingress來均衡這兩個工作負載的流量。
Rancher 2.0還為Ingress記錄中的工作負載提供了方便的鏈接。如果配置外部DNS以對DNS記錄進行編程,則可以將此主機名映射到Kubernetes Ingress地址。
Ingress地址是您的集群中Ingress Controller為您的工作負載分配的IP地址。您可以通過瀏覽此IP地址來達到工作負載。使用kubectl查看控制器分配入口地址。
您可以使用Curl來測試基于主機名/路徑的路由規則是否正常工作,如下所示:
以下是使用基于主機名/路徑的規則的Rancher 1.6配置規范,與2.0 Kubernetes Ingress YAML規范進行比較:
HTTPS /證書選項
Rancher 2.0 Ingress功能還支持HTTPS協議。您可以在配置Ingress規則時上載證書并使用它們,如下所示:
添加Ingress規則時選擇證書:
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/ranc...
一旦負載均衡器配置成功,Rancher將在Rancher UI中為您的工作負載的公共端點提供一個鏈接。
通過ConfigMaps支持NGINX Ingress Controller TCP
如上所述,Kubernetes Ingress本身不支持TCP協議。因此,即使TCP不是NGINX的限制,也無法通過Ingress創建來配置NGINX Ingress Controller以進行TCP負載均衡。
但是,您可以通過創建一個Kubernetes ConfigMap,來使用NGINX的TCP負載均衡功能,具體可參閱這里:https://github.com/kubernetes...。您可以創建Kuberenetes ConfigMap對象,來將pod配置參數存儲為鍵值對,與pod鏡像分開,更多細節可以參考這里:
https://kubernetes.io/docs/ta...
要配置NGINX以通過TCP暴露服務,您可以添加或更新命名空間tcp-services中的ConfigMap ingress-nginx。此命名空間還包含NGINX Ingress Controller pod。
ConfigMap條目中的密鑰應該是您要公開訪問的TCP端口,其值應為格式
將這些條目添加到Configmap,將自動更新NGINX pod,以配置這些工作負載來進行TCP負載均衡。您可以執行部署在ingress-nginx命名空間中的這些pod,并查看如何在/etc/nginx/nginx.conf文件中配置這些TCP端口。
Rancher 2.0負載均衡的限制
Cattle提供了功能豐富的負載均衡器支持(詳細介紹在此:https://rancher.com/docs/ranc...)。其中一些功能在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/...。
將負載均衡器配置從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生態系統在不斷發展,我相信我們能找到更多適合所有負載均衡細微差別的解決方案!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/32727.html
摘要:守護進程,充當和不同云提供商工具存儲卷負載均衡器等之間的抽象層。除此之外,在上還有一個健康檢查端點,以及一些其他狀態端點。它就像是節點上運行著的的網絡代理和負載均衡器一樣,通過在使用實現東西負載均衡。 今晚20:30,Kubernetes Master Class在線培訓第四期《企業如何構建CI/CD流水線》即將開播,點擊鏈接:http://live.vhall.com/7294658...
摘要:參數說明本文主要描述用于創建類型的時,與相關的說明。為時表示連接保持的時間,單位為秒,取值范圍,,表示禁用連接保持,默認為。會話保持方式枚舉值為關閉,自動生成,用戶自定義,默認為。健康檢查方式為時有效,指檢查路徑。ULB 參數說明本文主要描述用于創建LoadBalancer 類型的Service時,與ULB相關的Annotations說明。備注:目前除了外網 ULB 綁定的 EIP 的帶寬值...
摘要:后端代理之前的文章部署最后的測試部分,創建了一組及服務來驗證業務,繼續以這個例子來說明集群中已經有如下一組都帶有標簽,對外暴露端口,訪問路徑會返回主機名。請求代理轉發是一個虛擬的地址,并不是某張網卡的真實地址。 為什么需要service Kubernetes可以方便的為容器應用提供了一個持續運行且方便擴展的環境,但是,應用最終是要被用戶或其他應用訪問、調用的。要訪問應用pod,就會有以...
摘要:在的的首次會議慶祝了其新功能版本的發布。可以以這三種方式暴露出來內部外部和負載均衡。比如,可能會通過一個彈性負載均衡器接收流量,或者通過谷歌的負載均衡器接收。這個功能令第三方負載均衡器整合到。負起了接管發現任務和微服務負載均衡器的重任。 隨著容器逐漸受到企業的注意,焦點慢慢被轉移到了容器編排工具上。復雜的工作負載在生產過程中需要成熟地被調度,編排,彈性擴容和管理工具。有了Docker,...
閱讀 2571·2021-08-20 09:38
閱讀 1354·2019-08-30 15:43
閱讀 592·2019-08-29 17:13
閱讀 1601·2019-08-29 14:01
閱讀 1314·2019-08-29 13:29
閱讀 2321·2019-08-23 18:29
閱讀 2046·2019-08-23 17:51
閱讀 1914·2019-08-23 17:16