實用乾貨：Kubernetes中的負載均衡全解

不少企業在部署容器的時候都會選擇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資源中包含的可配置規則支持很是詳細和高度細化的負載均衡，能夠根據應用程序的功能要求極其運行條件進行定製。