很多企業在部署容器的時候都會選擇Kubernetes作為其容器編排系統。這是對Kubernetes的可靠性，靈活性和特性廣泛的肯定。在這篇文章中，我們將對Kubernetes如何處理一個非常常見且必要的工作——負載均衡，進行深入的解讀。在許多非容器環境(即服務器之間的均衡)中，負載均衡是一個相對簡單的任務，但當涉及到容器時，就需要一些其他的、特殊的處理。

管理容器

要理解Kubernetes的負載均衡，首先需要了解Kubernetes是如何組建容器的。

容器通常用來執行特定的服務或者一組服務，因此需要根據他們提供的服務來看待它們，而不是僅當作服務的單個實例(即單個容器)。實際上，這就是Kubernetes所做的。

把它們放置在Pods中

在Kubernetes中，pod是一種基本功能單元。一個pod是一組容器以及它們共享的卷(volumes)。容器在功能和服務方面通常是密切相關聯的。

將具有相同功能集的pods抽象成集合，就稱為服務。這些服務接受基于Kubernetes搭建的應用程序客戶端訪問;這些獨立的pod中的服務，反過來可以管理對構成它們的容器的訪問，使得客戶端與容器本身隔離。

管理Pods

現在我們來看看一些具體細節。

Pods通常由Kubernetes創建和銷毀，而不是設計成持久化實體。每個pod都有自己的IP地址(基于本地地址)、UID和端口號;新創建的pod，無論它們是當前pod還是之前的pod的副本，都會分配新的UID和IP地址。

每個pod內部是可以進行容器之間的通信的，但是不能與不同pod中的容器直接通信。

讓Kubernetes處理事務

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

我們之前提到了兩種負載均衡的方法，然而，這些并不是真正的負載均衡。為了實現真正的負載均衡，當前***、最靈活、應用于很多領域的方法是Ingress，它通過在專門的Kubernetes pod中的控制器進行操作。控制器包括一個Ingress資源——一組管理流量的規則和一個應用這些規則的守護進程。

控制器有自己內置的負載均衡特性，具備一些相當復雜的功能。你還可以讓Ingress資源包含更復雜的負載均衡規則，來滿足對具體系統或供應商的負載均衡功能和需求。

使用負載均衡器作為替代品

除了Ingress，你還可以使用負載均衡器類型的服務來替代它。該服務使用基于云服務的外部負載均衡器。負載均衡器只能與AWS、Azure、OpenStack、CloudStack和Google Compute Engine等特定的云服務提供商一起使用，且均衡器的功能根據提供者而定。除此之外其他的負載均衡方法可以從服務提供商以及第三方獲得。

總的來說，還是推薦Ingress

當前Ingress是***的負載均衡方法。因為它是作為一個基于pod的控制器在Kubernetes內部執行，因此對Kubernetes功能的訪問相對不受限制(不同于外部負載均衡器，它們中的一些可能無法在pod層面訪問)。Ingress資源中包含的可配置規則支持非常詳細和高度細化的負載均衡，可以根據應用程序的功能要求極其運行條件進行定制。