資訊專欄INFORMATION COLUMN
摘要：負載均衡器只能與和等特定的云服務提供商一起使用，且均衡器的功能根據提供者而定。因為它是作為一個基于的控制器在內部執行，因此對功能的訪問相對不受限制不同于外部負載均衡器，它們中的一些可能無法在層面訪問。
很多企業在部署容器的時候都會選擇Kubernetes作為其容器編排系統。這是對Kubernetes的可靠性，靈活性和特性廣泛的肯定。在這篇文章中，我們將對Kubernetes如何處理一個非常常見且必要的工作——負載均衡，進行深入的解讀。在許多非容器環境（即服務器之間的均衡）中，負載均衡是一個相對簡單的任務，但當涉及到容器時，就需要一些其他的、特殊的處理。
要理解Kubernetes的負載均衡，首先需要了解Kubernetes是如何組建容器的。
容器通常用來執行特定的服務或者一組服務，因此需要根據他們提供的服務來看待它們，而不是僅當作服務的單個實例（即單個容器）。實際上，這就是Kubernetes所做的。
在Kubernetes中，pod是一種基本功能單元。一個pod是一組容器以及它們共享的卷(volumes)。容器在功能和服務方面通常是密切相關聯的。
將具有相同功能集的pods抽象成集合，就稱為服務。這些服務接受基于Kubernetes搭建的應用程序客戶端訪問；這些獨立的pod中的服務，反過來可以管理對構成它們的容器的訪問，使得客戶端與容器本身隔離。
現在我們來看看一些具體細節。
Pods通常由Kubernetes創建和銷毀，而不是設計成持久化實體。每個pod都有自己的IP地址（基于本地地址）、UID和端口號；新創建的pod，無論它們是當前pod還是之前的pod的副本，都會分配新的UID和IP地址。
每個pod內部是可以進行容器之間的通信的，但是不能與不同pod中的容器直接通信。
Kubernetes使用自己的內置工具來管理和單個pod之前的通信。這說明一般情況下，依靠Kubernetes內部監控pods就足夠了，不必擔心pods的創建、刪除或者復制。不過，有時也需要Kubernetes管理的應用程序中至少某些內部元素對底層網絡可見。發生這種情況時，方案必須考慮到缺少永久IP地址該怎么處理。
Pods和節點(Nodes)在許多方面上，Kubernetes都可看作是一個pod管理系統，就像容器管理系統一樣。大部分基礎設施都是在pod層面處理容器，而不是在容器層面。
從Kubernetes內部管理來看，pod上面的組織級別相當于節點，是一個虛擬機，包含了管理和通信的資源并且是部署pod的環境。節點本身也可以在內部創建、銷毀和替換/重新部署。無論是節點層面還是pod層面，它們的創建、銷毀、重新部署、使用和擴展等功能都由被稱為控制器(Controller)的內部進程處理。
服務（service）是Kubernetes在管理層面處理容器和pods的方式。不過正如我們上面提到的，它還將功能相關或相同的pods抽象成服務，并且在外部客戶端和應用程序中其他元素與pod交互時，Kubernetes處在服務層面。
服務有相對穩定的IP地址（由Kubernetes內部使用）。當一個程序需要使用由服務中的功能時，它會向服務、而非向單個pod提出請求。接著該服務會作為調度員，分配一個pod來處理請求。
看到這里你可能會想，負載均衡會不會是在調度層面進行的？事實確實如此。Kubernetes的服務有點像一個巨大的設備池，根據需要將功能相同的機器送入指定區域。作為調度過程的一部分，它需要充分考慮管理可用性，避免遇到資源瓶頸。
讓kube-proxy來執行負載均衡Kubernetes中最基本的負載均衡類型實際上是負載分配(load distribution)，這在調度層面是容易實現的。Kubernetes使用了兩種負載分配的方法，都通過kube-proxy這一功能執行，該功能負責管理服務所使用的虛擬IPs。
Kube-proxy的默認模式是iptables，它支持相當復雜的基于規則的IP管理。iptables模式下，負載分配的本地方法是隨機選擇——由一個傳入的請求去隨機選擇一個服務中的pod。早先版本（以及原來的默認模式）的kube-proxy模式是userspace，它使用循環的負載分配，在IP列表上來分配下一個可以使用的pod，然后更換（或置換）該列表。
我們之前提到了兩種負載均衡的方法，然而，這些并不是真正的負載均衡。為了實現真正的負載均衡，當前最流行、最靈活、應用于很多領域的方法是Ingress，它通過在專門的Kubernetes pod中的控制器進行操作。控制器包括一個Ingress資源——一組管理流量的規則和一個應用這些規則的守護進程。
控制器有自己內置的負載均衡特性，具備一些相當復雜的功能。你還可以讓Ingress資源包含更復雜的負載均衡規則，來滿足對具體系統或供應商的負載均衡功能和需求。
除了Ingress，你還可以使用負載均衡器類型的服務來替代它。該服務使用基于云服務的外部負載均衡器。負載均衡器只能與AWS、Azure、OpenStack、CloudStack和Google Compute Engine等特定的云服務提供商一起使用，且均衡器的功能根據提供者而定。除此之外其他的負載均衡方法可以從服務提供商以及第三方獲得。
總的來說，還是推薦Ingress當前Ingress是首選的負載均衡方法。因為它是作為一個基于pod的控制器在Kubernetes內部執行，因此對Kubernetes功能的訪問相對不受限制（不同于外部負載均衡器，它們中的一些可能無法在pod層面訪問）。Ingress資源中包含的可配置規則支持非常詳細和高度細化的負載均衡，可以根據應用程序的功能要求極其運行條件進行定制。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/33028.html
摘要：守護進程，充當和不同云提供商工具存儲卷負載均衡器等之間的抽象層。除此之外，在上還有一個健康檢查端點，以及一些其他狀態端點。它就像是節點上運行著的的網絡代理和負載均衡器一樣，通過在使用實現東西負載均衡。 今晚20:30，Kubernetes Master Class在線培訓第四期《企業如何構建CI/CD流水線》即將開播，點擊鏈接：http://live.vhall.com/7294658...
摘要：部署只是一種規則，控制器組件會將這一規則應用于實際負載均衡器中。原因是功能僅允許將端口用于路由，負載均衡器和則可作為全局啟動。負載均衡的限制提供了功能豐富的負載均衡器支持詳細介紹在此。截至目前，我們暫時無法使用工具將負載均衡器配置從轉換為。 如果您的應用程序是面向大量用戶、會吸引大量流量，那么一個不變的目標一定是在高效滿足用戶需求的同時、不讓用戶感知到任何類似于服務器繁忙！的情況。這一...
摘要：年正在柏林盛大舉行，來自等多個開源云原生社區的領先技術專家正匯聚一堂，以進一步推動云原生計算的教育和發展。例如，你還需要諸如負載均衡器和的服務來運行應用程序。負載均衡器可以進行高級定制，以滿足用戶的各類需求。 想要在生產環境中成功部署容器，你需要的不僅僅是容器編排。 2017年CloudNativeCon+KubeCon Europe正在柏林盛大舉行，來自Fluented、Kubern...
摘要：年正在柏林盛大舉行，來自等多個開源云原生社區的領先技術專家正匯聚一堂，以進一步推動云原生計算的教育和發展。例如，你還需要諸如負載均衡器和的服務來運行應用程序。負載均衡器可以進行高級定制，以滿足用戶的各類需求。 想要在生產環境中成功部署容器，你需要的不僅僅是容器編排。 2017年CloudNativeCon+KubeCon Europe正在柏林盛大舉行，來自Fluented、Kubern...
閱讀 1739·2021-09-26 09:46
閱讀 3017·2021-09-22 15:55
閱讀 2608·2019-08-30 14:17
閱讀 3027·2019-08-26 11:59
閱讀 1809·2019-08-26 11:35
閱讀 3155·2019-08-26 10:45
閱讀 3152·2019-08-23 18:28
閱讀 1105·2019-08-23 18:21
