資訊專欄INFORMATION COLUMN
摘要：現(xiàn)在，我們來理解一下如何用來完成彈性擴(kuò)容以及可靠性。結(jié)論容器已經(jīng)不是一個(gè)新型的概念了，谷歌數(shù)十年來都將它大部分網(wǎng)絡(luò)規(guī)模的工作負(fù)載都放在容器中運(yùn)行。早在十年前就已經(jīng)解決了谷歌面對(duì)的難題，這些正在影響著容器編排工具前進(jìn)的道路。
在第一篇文章里，我們探索了在Kubernetes中pods和services的概念?，F(xiàn)在，我們來理解一下如何用RC來完成彈性擴(kuò)容以及可靠性。我們也會(huì)討論一下如何將持久化帶入布置在Kubernetes上的云本地應(yīng)用程序。
RC：彈性擴(kuò)容和管理微服務(wù)如果pods是一個(gè)單元，部署和services是抽象層，那么誰來追蹤pods的健康狀況呢？
于是RC就這樣出場(chǎng)了。
在pods被部署之后，他們需要擴(kuò)容，需要被追蹤。RC定義文件有pods數(shù)量的基線配置，這些pods在任何給定的點(diǎn)都是可得的。Kubernetes確保了需要的配置選項(xiàng)一直通過追蹤pods數(shù)量來維護(hù)。它會(huì)殺死一些pods，又或者是創(chuàng)建一些來滿足基線配置。
RC可以追蹤pods的健康狀況。如果一個(gè)pod變得難得到的，那么它就會(huì)被殺死，然后一些新的pod會(huì)被創(chuàng)建。因?yàn)橐粋€(gè)RC實(shí)質(zhì)上就是繼承了pod的定義，YAML或者JSON清單可能包含重啟策略，容器調(diào)查和健康檢查端點(diǎn)的屬性。
Kubernetes支持基于CPU利用率的pod自動(dòng)彈性擴(kuò)容，跟EC2自動(dòng)擴(kuò)容或者GCE自動(dòng)擴(kuò)容有些相似。在運(yùn)行的時(shí)候，RC可以被操作來自動(dòng)擴(kuò)容pods，基于特定的CPU利用率閾值。pods的數(shù)量的最大值和最小值也可以在同樣的命令下規(guī)定。
平網(wǎng)絡(luò)：秘密武器網(wǎng)絡(luò)也是容器化過程中面臨的復(fù)雜挑戰(zhàn)之一。將一個(gè)容器暴露到外部世界的唯一方法就是通過主機(jī)的端口轉(zhuǎn)發(fā)。但是擴(kuò)容容器的時(shí)候就會(huì)變得復(fù)雜。Kubernetes不是將網(wǎng)絡(luò)配置和集成留給管理員來做，而是自帶一個(gè)網(wǎng)絡(luò)模型，這個(gè)網(wǎng)絡(luò)模型十分易于使用。
每個(gè)節(jié)點(diǎn)，service，pod和容器都有一個(gè)IP地址。節(jié)點(diǎn)的IP地址由物理路由器分配；結(jié)合分配的端口，它會(huì)變成端點(diǎn)來訪問面向服務(wù)。雖然不是可路由的，但是Kubernetes服務(wù)也是可以獲取IP地址的。所有的通信都是在沒有NAT層的基礎(chǔ)上產(chǎn)生的，使得網(wǎng)絡(luò)平面化，透明化。
這個(gè)模型會(huì)帶來一些好處：
所有的容器不需要NAT也可以互相通信
所有的節(jié)點(diǎn)不需要NAT也可以跟所有的pods和集群中的容器通信
每個(gè)容器跟其他容器一樣看到的都是相同的IP地址
關(guān)于通過RS來擴(kuò)容pods最好的一點(diǎn)就是，端口映射是由Kubernetes處理的。所有屬于service的pods都是通過相同的端口暴露到每個(gè)節(jié)點(diǎn)上的。即使沒有pod在特定的節(jié)點(diǎn)上調(diào)度，request也會(huì)自動(dòng)轉(zhuǎn)發(fā)到合適的節(jié)點(diǎn)。
這個(gè)神奇的功能就是通過kube-proxy，iptables和etcd這些網(wǎng)絡(luò)代理的結(jié)合來實(shí)現(xiàn)的。當(dāng)前集群的狀態(tài)就是用etcd來維護(hù)的，這也就意味著在運(yùn)行的時(shí)候通過kube-proxy查詢。通過操作在每個(gè)節(jié)點(diǎn)上的iptables，kube-proxy將request退信到正確的目的地。
Kube-proxy同樣也處理services的基礎(chǔ)負(fù)載均衡。Service端點(diǎn)也是用Docker links通過環(huán)境變量來管理。這些變量分解到端口，端口通過service暴露到外面。Kubernetes1.1包括了一個(gè)來使用本地iptables的選項(xiàng)，這個(gè)選項(xiàng)會(huì)帶來80%的延遲。這個(gè)設(shè)計(jì)消除了CPU開銷，因此提升了效率，也提升了可拓展性。
持久性：將狀態(tài)帶到容器容器是短暫的。當(dāng)他們從一個(gè)主機(jī)轉(zhuǎn)移到另一個(gè)主機(jī)的時(shí)候，他們不包含狀態(tài)。對(duì)于產(chǎn)品負(fù)載，持久是一個(gè)必須條件。任意有用的應(yīng)用程序都有一個(gè)數(shù)據(jù)庫(kù)在背后支持它。
默認(rèn)設(shè)置下，pods也是短暫的。他們每次復(fù)活的時(shí)候都從空白狀態(tài)開始。設(shè)置在同一個(gè)pod中運(yùn)行的容器所共享的數(shù)據(jù)卷也是可以的。由emptyDir monilker確認(rèn)，這個(gè)與Docker數(shù)據(jù)卷有點(diǎn)相似，在這里主機(jī)文件系統(tǒng)在容器內(nèi)被暴露為一個(gè)目錄。emptyDir數(shù)據(jù)卷追蹤pods的生命周期。當(dāng)pod 被刪除的時(shí)候，數(shù)據(jù)卷也會(huì)被刪除掉。因?yàn)檫@些數(shù)據(jù)卷只符合主機(jī)的，所以他們?cè)谄渌?jié)點(diǎn)上不可用。
為了在pods上帶來持久性數(shù)據(jù)，不管他們?cè)谀膫€(gè)節(jié)點(diǎn)上被調(diào)度，Kubernetes都支持PV和PVC requests。PVC和PV共享關(guān)系，就如同pod和節(jié)點(diǎn)一樣。當(dāng)一個(gè)pod被創(chuàng)建的時(shí)候，它可以通過claim聯(lián)系到特定數(shù)據(jù)卷。PV可以基于各種各樣的插件，比如GCE持久性硬盤，亞馬遜彈性快存儲(chǔ)（EBS），網(wǎng)絡(luò)文件系統(tǒng)（NFS），小型計(jì)算機(jī)系統(tǒng)接口（ISCSI），GlusterFS和RBD。
設(shè)置持久化的工作流包括配置底層文件系統(tǒng)或者云數(shù)據(jù)卷，創(chuàng)建持久性數(shù)據(jù)卷，最后，創(chuàng)建claim來將pod跟數(shù)據(jù)卷關(guān)聯(lián)起來。這個(gè)解耦方法可以將pod和數(shù)據(jù)卷完全分離，或者pod不需要知道確切的文件系統(tǒng)或者支持它的持久性引擎。有些文件系統(tǒng)，比如GlusterFS，也可以被容器化，使得配置更加容易，便捷。
結(jié)論容器已經(jīng)不是一個(gè)新型的概念了，谷歌數(shù)十年來都將它大部分網(wǎng)絡(luò)規(guī)模的工作負(fù)載都放在容器中運(yùn)行。他們?cè)谶@個(gè)過程中吸取教訓(xùn)，并將這些教訓(xùn)融入Kubernetes的建設(shè)中，這些經(jīng)驗(yàn)教訓(xùn)也可以被移植到其他的編排平臺(tái)中，也可以移植到其它的編排工具中。Kubernetes早在十年前就已經(jīng)解決了谷歌SRE面對(duì)的難題，這些正在影響著容器編排工具前進(jìn)的道路。
最重要的是，Kubernetes在容器生態(tài)圈已經(jīng)是一個(gè)焦點(diǎn)，對(duì)于其它相關(guān)服務(wù)，它的存在就好像是一個(gè)有價(jià)值的開源平臺(tái)。理解Kubernetes目前的角色和作用對(duì)于編排工具市場(chǎng)是十分有必要的。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/32472.html
摘要：我們通過阿里云容器服務(wù)控制臺(tái)創(chuàng)建一個(gè)集群，這里以創(chuàng)建臺(tái)節(jié)點(diǎn)集群為例。全方位監(jiān)控集群接入層的監(jiān)控是必不可少的，您可以通過阿里云容器服務(wù)監(jiān)控以及阿里云云監(jiān)控對(duì)和進(jìn)行全方位監(jiān)控。 摘要： 在Kubernetes集群中，Ingress作為集群流量接入層，Ingress的高可靠性顯得尤為重要，今天我們主要探討如何部署一套高性能高可靠的Ingress接入層。 簡(jiǎn)介 在Kubernetes集群中，I...
摘要：平臺(tái)上的微服務(wù)架構(gòu)應(yīng)用再來看一下我眼中的基于當(dāng)前最流行的微服務(wù)架構(gòu)的設(shè)計(jì)是什么樣的，即我們平臺(tái)上要運(yùn)行的典型應(yīng)用是什么樣的。 showImg(https://segmentfault.com/img/remote/1460000010900878); 8月19日的數(shù)人云Container Meetup上，張龍老師做了《基于Kubernetes的PaaS平臺(tái)的設(shè)計(jì)和思考》的精彩分享，分別...
摘要：從年以來，谷歌基于容器研發(fā)三個(gè)容器管理系統(tǒng)，分別是和。這篇論文由這三個(gè)容器集群管理系統(tǒng)長(zhǎng)年開發(fā)維護(hù)的谷歌工程師和于近日發(fā)表，闡述了谷歌從到這個(gè)旅程中所獲得的知識(shí)和經(jīng)驗(yàn)教訓(xùn)。和完全是谷歌內(nèi)部系統(tǒng)相比，是開源的。 從2000年以來，谷歌基于容器研發(fā)三個(gè)容器管理系統(tǒng)，分別是Borg、Omega和Kubernetes。這篇論文由這三個(gè)容器集群管理系統(tǒng)長(zhǎng)年開發(fā)維護(hù)的谷歌工程師Brendan Bu...
摘要：下需要為每個(gè)單獨(dú)進(jìn)行采集配置采集日志目錄，采集規(guī)則，存儲(chǔ)目標(biāo)等，不易維護(hù)。日志服務(wù)的日志架構(gòu)實(shí)踐我們提出基于阿里云日志服務(wù)的日志處理架構(gòu)，用以補(bǔ)充社區(qū)的方案，來嘗試解決場(chǎng)景下日志處理的一些細(xì)節(jié)體驗(yàn)問題。 摘要： 在Kubernetes服務(wù)化、日志處理實(shí)時(shí)化以及日志集中式存儲(chǔ)趨勢(shì)下，Kubernetes日志處理上也遇到的新挑戰(zhàn)，包括：容器動(dòng)態(tài)采集、大流量性能瓶頸、日志路由管理等問題。本文...
閱讀 1471·2021-11-22 14:44
閱讀 2850·2021-11-16 11:44
閱讀 3218·2021-10-13 09:40
閱讀 1993·2021-10-08 10:04
閱讀 2372·2021-09-24 10:28
閱讀 2919·2021-09-06 15:02
閱讀 2966·2019-08-30 15:52
閱讀 2403·2019-08-30 13:20
