本篇內(nèi)容主要講解“Kubernetes中的負(fù)載均衡怎么實(shí)現(xiàn)”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Kubernetes中的負(fù)載均衡怎么實(shí)現(xiàn)”吧!

在王益等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作定制開(kāi)發(fā),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),營(yíng)銷型網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站制作,王益網(wǎng)站建設(shè)費(fèi)用合理。

管理容器

要理解Kubernetes的負(fù)載均衡，首先需要了解Kubernetes是如何組建容器的。 容器通常用來(lái)執(zhí)行特定的服務(wù)或者一組服務(wù)，因此需要根據(jù)他們提供的服務(wù)來(lái)看待它們，而不是僅當(dāng)作服務(wù)的單個(gè)實(shí)例（即單個(gè)容器）。實(shí)際上，這就是Kubernetes所做的。

把它們放置在Pods中

在Kubernetes中，pod是一種基本功能單元。一個(gè)pod是一組容器以及它們共享的卷(volumes)。容器在功能和服務(wù)方面通常是密切相關(guān)聯(lián)的。 將具有相同功能集的pods抽象成集合，就稱為服務(wù)。這些服務(wù)接受基于Kubernetes搭建的應(yīng)用程序客戶端訪問(wèn)；這些獨(dú)立的pod中的服務(wù)，反過(guò)來(lái)可以管理對(duì)構(gòu)成它們的容器的訪問(wèn)，使得客戶端與容器本身隔離。

管理Pods

現(xiàn)在我們來(lái)看看一些具體細(xì)節(jié)。 Pods通常由Kubernetes創(chuàng)建和銷毀，而不是設(shè)計(jì)成持久化實(shí)體。每個(gè)pod都有自己的IP地址（基于本地地址）、UID和端口號(hào)；新創(chuàng)建的pod，無(wú)論它們是當(dāng)前pod還是之前的pod的副本，都會(huì)分配新的UID和IP地址。 每個(gè)pod內(nèi)部是可以進(jìn)行容器之間的通信的，但是不能與不同pod中的容器直接通信。

讓Kubernetes處理事務(wù)

Kubernetes使用自己的內(nèi)置工具來(lái)管理和單個(gè)pod之前的通信。這說(shuō)明一般情況下，依靠Kubernetes內(nèi)部監(jiān)控pods就足夠了，不必?fù)?dān)心pods的創(chuàng)建、刪除或者復(fù)制。不過(guò)，有時(shí)也需要Kubernetes管理的應(yīng)用程序中至少某些內(nèi)部元素對(duì)底層網(wǎng)絡(luò)可見(jiàn)。發(fā)生這種情況時(shí)，方案必須考慮到缺少永久IP地址該怎么處理。

Pods和節(jié)點(diǎn)(Nodes)

在許多方面上，Kubernetes都可看作是一個(gè)pod管理系統(tǒng)，就像容器管理系統(tǒng)一樣。大部分基礎(chǔ)設(shè)施都是在pod層面處理容器，而不是在容器層面。 從Kubernetes內(nèi)部管理來(lái)看，pod上面的組織級(jí)別相當(dāng)于節(jié)點(diǎn)，是一個(gè)虛擬機(jī)，包含了管理和通信的資源并且是部署pod的環(huán)境。節(jié)點(diǎn)本身也可以在內(nèi)部創(chuàng)建、銷毀和替換/重新部署。無(wú)論是節(jié)點(diǎn)層面還是pod層面，它們的創(chuàng)建、銷毀、重新部署、使用和擴(kuò)展等功能都由被稱為控制器(Controller)的內(nèi)部進(jìn)程處理。

充當(dāng)調(diào)度者的“服務(wù)”

服務(wù)（service）是Kubernetes在管理層面處理容器和pods的方式。不過(guò)正如我們上面提到的，它還將功能相關(guān)或相同的pods抽象成服務(wù)，并且在外部客戶端和應(yīng)用程序中其他元素與pod交互時(shí)，Kubernetes處在服務(wù)層面。 服務(wù)有相對(duì)穩(wěn)定的IP地址（由Kubernetes內(nèi)部使用）。當(dāng)一個(gè)程序需要使用由服務(wù)中的功能時(shí)，它會(huì)向服務(wù)、而非向單個(gè)pod提出請(qǐng)求。接著該服務(wù)會(huì)作為調(diào)度員，分配一個(gè)pod來(lái)處理請(qǐng)求。

調(diào)度和負(fù)載分配

看到這里你可能會(huì)想，負(fù)載均衡會(huì)不會(huì)是在調(diào)度層面進(jìn)行的？事實(shí)確實(shí)如此。Kubernetes的服務(wù)有點(diǎn)像一個(gè)巨大的設(shè)備池，根據(jù)需要將功能相同的機(jī)器送入指定區(qū)域。作為調(diào)度過(guò)程的一部分，它需要充分考慮管理可用性，避免遇到資源瓶頸。

讓kube-proxy來(lái)執(zhí)行負(fù)載均衡

Kubernetes中最基本的負(fù)載均衡類型實(shí)際上是負(fù)載分配(load distribution)，這在調(diào)度層面是容易實(shí)現(xiàn)的。Kubernetes使用了兩種負(fù)載分配的方法，都通過(guò)kube-proxy這一功能執(zhí)行，該功能負(fù)責(zé)管理服務(wù)所使用的虛擬IPs。 Kube-proxy的默認(rèn)模式是iptables，它支持相當(dāng)復(fù)雜的基于規(guī)則的IP管理。iptables模式下，負(fù)載分配的本地方法是隨機(jī)選擇——由一個(gè)傳入的請(qǐng)求去隨機(jī)選擇一個(gè)服務(wù)中的pod。早先版本（以及原來(lái)的默認(rèn)模式）的kube-proxy模式是userspace，它使用循環(huán)的負(fù)載分配，在IP列表上來(lái)分配下一個(gè)可以使用的pod，然后更換（或置換）該列表。

真正的負(fù)載均衡：Ingress

我們之前提到了兩種負(fù)載均衡的方法，然而，這些并不是真正的負(fù)載均衡。為了實(shí)現(xiàn)真正的負(fù)載均衡，當(dāng)前最流行、最靈活、應(yīng)用于很多領(lǐng)域的方法是Ingress，它通過(guò)在專門(mén)的Kubernetes pod中的控制器進(jìn)行操作?？刂破靼ㄒ粋€(gè)Ingress資源——一組管理流量的規(guī)則和一個(gè)應(yīng)用這些規(guī)則的守護(hù)進(jìn)程。 控制器有自己內(nèi)置的負(fù)載均衡特性，具備一些相當(dāng)復(fù)雜的功能。你還可以讓Ingress資源包含更復(fù)雜的負(fù)載均衡規(guī)則，來(lái)滿足對(duì)具體系統(tǒng)或供應(yīng)商的負(fù)載均衡功能和需求。

使用負(fù)載均衡器作為替代品

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

總的來(lái)說(shuō)，還是推薦Ingress

當(dāng)前Ingress是首選的負(fù)載均衡方法。因?yàn)樗亲鳛橐粋€(gè)基于pod的控制器在Kubernetes內(nèi)部執(zhí)行，因此對(duì)Kubernetes功能的訪問(wèn)相對(duì)不受限制（不同于外部負(fù)載均衡器，它們中的一些可能無(wú)法在pod層面訪問(wèn)）。Ingress資源中包含的可配置規(guī)則支持非常詳細(xì)和高度細(xì)化的負(fù)載均衡，可以根據(jù)應(yīng)用程序的功能要求極其運(yùn)行條件進(jìn)行定制。

到此，相信大家對(duì)“Kubernetes中的負(fù)載均衡怎么實(shí)現(xiàn)”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！