結(jié)合Kubernetes解讀微服務(wù)的12要素-創(chuàng)新互聯(lián)

成都創(chuàng)新互聯(lián)自2013年創(chuàng)立以來，先為榆林等服務(wù)建站，榆林等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為榆林企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

本文由公眾號EAWorld翻譯發(fā)表，轉(zhuǎn)載需注明出處。

作者：Michael D. Elder 

譯者：白小白 

原題：Kubernetes & 12-factor apps 

原文：http://t.cn/EoBns1o

關(guān)于12原則的更多內(nèi)容，可以進一步閱讀《全網(wǎng)首發(fā)：逐一解讀云原生應(yīng)用開發(fā)“12-Factors”》

如果你在使用容器來構(gòu)建應(yīng)用的話，一定聽過什么是“12要素原則”?！?2要素”為開發(fā)微服務(wù)提供了一組明確的指引。人們相信只要遵循這些原則，就可以更容易的運行、擴展和部署應(yīng)用與服務(wù)。

在講述“12要素原則”的時候，筆者習(xí)慣于將這些原則按普遍的場景進行分組。對我來說，12要素最終是關(guān)于如何編碼、部署和運營的原則。這些是軟件交付生命周期里最常見的場景，為多數(shù)開發(fā)者和DevOps整合團隊所熟知。

那么在使用Kubernetes的過程中，如何在構(gòu)建微服務(wù)的時候應(yīng)用12要素原則呢？事實上，12要素原則對Kubernetes的發(fā)展和演進過程產(chǎn)生了深遠的影響。接下來的內(nèi)容，我將逐一分析，Kubernetes的容器編排模型是如何對各組12要素原則進行直接的支持的。

一、與編碼有關(guān)的要素

關(guān)于源碼管理，需要考慮的因素是基準(zhǔn)代碼、構(gòu)建和部署生命周期以及最終如何維持生產(chǎn)環(huán)境和開發(fā)環(huán)境的一致性。

一個基本的軟件交付周期圖

Source control all the things

源碼控制一切

要素一：一份基準(zhǔn)代碼，多份部署

Kubernetes中大量的使用聲明式結(jié)構(gòu)。應(yīng)用的全部信息都經(jīng)由YAML或者JSON實現(xiàn)基于文本的表達。容器本身則被描述為Dockerfile這樣的源碼格式，在構(gòu)建的過程中，可以反復(fù)的將文本格式的Dockerfile轉(zhuǎn)為容器鏡像。因為從鏡像到容器部署環(huán)節(jié)都被封裝為文本形態(tài)，可以很容易的實現(xiàn)對所有事物的源碼控制，而最常用的工具是Git。

在Kubernetes中，很多東西可以用聲明的方式來進行描述?！禟ubernetes in the Enterprise》這本書中記錄了很多完整的示例，相關(guān)的代碼都在Github上。

如果應(yīng)用需要跨越開發(fā)、用戶驗收、生產(chǎn)等不同的環(huán)境來運行的話，最常用的方法是使用GitOps交付模型來實現(xiàn)多分支的管理，來區(qū)分環(huán)境之間的差異。

要素五：嚴(yán)格分離構(gòu)建、發(fā)布和運行

如標(biāo)題所述，為了遵循這一原則，構(gòu)建、發(fā)布和運行環(huán)境要實現(xiàn)嚴(yán)格的分離。最典型的實現(xiàn)方式是工件管理：一旦代碼提交，構(gòu)建隨之開始，而后生成容器鏡像并發(fā)布到鏡像庫。如果使用了Helm（Kubernetes的包管理器，類似Ubuntu的apt-get），Kubernetes應(yīng)用會同時被打包和發(fā)布到Helm庫。通過對二進制文件或者鏡像文件的重新構(gòu)建，所有這些發(fā)布物可以在不同的環(huán)境中進行復(fù)用和部署，并且可以保證不會這個過程中引入任何未知的變更。

要素十：開發(fā)環(huán)境與生產(chǎn)環(huán)境等價

遵循這一等價原則，可以避免下面這種惱人的對話，“在我那好好的，怎么在你那就不行了呢”。容器（或者莫不如說是Kubernetes）讓應(yīng)用的交付和運行依賴實現(xiàn)了標(biāo)準(zhǔn)化，這意味著可以將任何事物以相同的方式部署到任何地方。因此，如果在生產(chǎn)環(huán)境使用了高可用的MySQL配置，就可以在開發(fā)集群中部署相同的架構(gòu)。通過在前期的開發(fā)環(huán)境中建立生產(chǎn)環(huán)境的等價架構(gòu)，通?？梢员苊庖恍┎豢深A(yù)見的差異，而這些差異可能對于應(yīng)用的正常運行（甚至是失敗）產(chǎn)生至關(guān)重要的影響。

二、與部署有關(guān)的要素

構(gòu)建的價值僅在成功部署時才能得以體現(xiàn)。在12要素中，有很大比例的原則描述了相關(guān)的最佳實踐，包括微服務(wù)該如何部署，如何處理依賴，以及如何解析其他微服務(wù)的細節(jié)。

微服務(wù)的可靠性取決于其最不可靠的依賴。

如何理解這句話呢，答案就在下面的這張Kubernetes架構(gòu)圖中：

Pod以及相關(guān)的Kubernetes對象

要素二：顯式聲明依賴關(guān)系

對于上面那句話的理解，首先需要考慮依賴關(guān)系的構(gòu)建，12要素中關(guān)于依賴關(guān)系的闡述參照了構(gòu)建管理的原則。然而我仍舊傾向于將依賴要素放在與部署有關(guān)的分組中，因為對于其他API或者數(shù)據(jù)存儲的依賴將對微服務(wù)的可靠性產(chǎn)生廣泛的影響。Kubernetes引入了readiness和liveness的探針機制，可以執(zhí)行運行期的依賴檢查。readiness探針可以驗證在某個時間點或者時間段，是否存在健康的后端service用以響應(yīng)請求。而liveness探針可以確認service本身的健康性。在給定的時間窗口內(nèi)，如果兩個指標(biāo)之一觸發(fā)了失敗的臨界值，Pod將被重啟。

譯注：

此處作者對于liveness和readiness的理解是有誤解的。liveness指標(biāo)實際上標(biāo)志了容器可以正常工作的底線，只有在超過這一底線時，容器才會被重啟。而readiness指標(biāo)則標(biāo)志了容器可以正常工作的上線，不滿足readiness的要求，容器并不會被重啟，而僅會標(biāo)志為“非正?！睜顟B(tài)。舉例來說，Tomcat的應(yīng)用啟動成功后就是liveness，但只有在spring容器初始化、數(shù)據(jù)庫連接等相關(guān)過程完成后，才是readiness。

更多內(nèi)容參見http://t.cn/EorvPAh

建議花時間閱讀《Release It!》這本書，領(lǐng)略書中的智慧，以及使用書中描述的架構(gòu)模式（熔斷器，F(xiàn)ail Fast，Timeouts等）來改進應(yīng)用程序的可靠性。

在環(huán)境中存儲配置

按照這一要素的要求，開發(fā)者需要將配置源碼存儲在進程的環(huán)境變量表中，如ENV VARs。通過配置與代碼的分離，微服務(wù)將徹底的獨立于環(huán)境，可以不進行任何源碼級的變更就移植到另一環(huán)境。Kubernetes提供了ConfigMaps和Secrets對象用于配置源碼的管理（事實上Secrets在未經(jīng)額外的加密的情況下不應(yīng)納入源碼管理）。容器可以在運行時獲取配置的細節(jié)。將配置信息存儲為環(huán)境變量有利于系統(tǒng)的擴展以及處理日漸增長的服務(wù)需求。

要素六：以無狀態(tài)的進程運行應(yīng)用

在Kubernetes中，容器鏡像作為Pod中的進程運行。來自12要素的觀察發(fā)現(xiàn)，Linux內(nèi)核已經(jīng)通過圍繞進程模型的資源共享實現(xiàn)了大量的優(yōu)化。Kubernetes或者說容器只是提供了一個界面來實現(xiàn)更好的隔離，讓處于同一主機的容器進程可以并行不悖。進程模型的應(yīng)用使得系統(tǒng)擴展和故障恢復(fù)的管理變得更加容易。一般來說，進程應(yīng)該是無狀態(tài)的，這樣才能以副本的方式實現(xiàn)工作負載的橫向擴展。但在Kubernetes中，也有諸如數(shù)據(jù)庫/緩存這類有狀態(tài)的工作負載。

應(yīng)該使用持久的數(shù)據(jù)存儲來按需保存應(yīng)用的狀態(tài)，應(yīng)用進程的所有實例都可以通過配置文件來發(fā)現(xiàn)這些存儲。在基于Kubernetes的應(yīng)用中，Pod的多個副本同時運行，請求可能被路由到任何一個副本，因此，微服務(wù)不可能期待粘滯會話（即讓用戶在一次會話周期內(nèi)的所有請求始終轉(zhuǎn)發(fā)到同一個特定的對象）。

得益于進程模型的機制，所有的service都可以很容易的通過創(chuàng)建更多的進程實例來實現(xiàn)擴展，Kubernetes提供了很多控制器來完成這項工作，如ReplicaSets, Deployments, StatefulSet, ReplicationController等等。

參見如下代碼片段的第2行至第7行，關(guān)于副本的部分。

watson-conversation.yaml hosted with ? by GitHub

Kubernetes的部署文件列示了所需的副本數(shù)量的聲明（如第7行所示）

要素四：把后端服務(wù)當(dāng)作附加資源

我們通常把網(wǎng)絡(luò)環(huán)境這類依賴定義為“后端服務(wù)”。正確的做法是把這些 上游服務(wù)的生命周期獨立于微服務(wù)本身的生命周期來考慮。無論是后端服務(wù)的附加或者剝離，都不應(yīng)該影響微服務(wù)本身正常響應(yīng)的能力。

舉例來說，如果應(yīng)用需要與數(shù)據(jù)庫進行交互，就需要設(shè)定一些連接細節(jié)，來隔離應(yīng)用與數(shù)據(jù)庫的交互行為，可以使用動態(tài)的服務(wù)發(fā)現(xiàn)，或者是使用Kubernetes Secret的Config配置來實現(xiàn)。接下來，需要考慮的是網(wǎng)絡(luò)請求是否實現(xiàn)了容錯機制，以保證即使后端服務(wù)發(fā)生了運行時失敗，也不會觸發(fā)微服務(wù)的級聯(lián)失?。ā禦elease It!》書中有更詳盡的闡述）。相關(guān)的后端服務(wù)應(yīng)該運行在獨立的容器中，或者集群以外的什么地方。微服務(wù)不應(yīng)該關(guān)注交互的細節(jié)，所有與數(shù)據(jù)庫的交互行為都通過API來完成。

要素七：通過端口綁定提供服務(wù)

在生產(chǎn)環(huán)境中，多個微服務(wù)提供了不同的功能，服務(wù)間的通信需要經(jīng)由良好定義的協(xié)議來達成。可以使用Kubernetes Service對象來聲明和解析集群內(nèi)外相關(guān)服務(wù)的網(wǎng)絡(luò)端點。

在容器出現(xiàn)以前，任何時候，如果需要部署一個新的服務(wù)或者更新現(xiàn)有服務(wù)的版本的話，就需要花大量的時間解決主機上的端口沖突問題。容器的隔離機制以及Linux內(nèi)核的網(wǎng)絡(luò)命名空間機制，使得在單一主機的相同端口上運行多個進程或者同一個微服務(wù)的多個版本成為可能。從而，Kubernetes的Service對象就可以向所有主機暴露微服務(wù)池，并且對入站請求實現(xiàn)基本的負載均衡。

在Kubernetes中，Service對象是聲明式的，并且會自動完成路由到Pod的相關(guān)請求的負載均衡工作。

處理對Pod的相關(guān)請求的負載均衡的Service聲明示例：

watson-conversation-service.yaml hosted with ? by GitHub

三、與運營有關(guān)的要素

要素八（并發(fā)），要素九（可處置性），要素十一（日志）和要素十二（任務(wù)管理）與如何簡化微服務(wù)的運營相關(guān)。

Kubernetes聚焦于多個Pod的簡單部署單元如何按需創(chuàng)建和銷毀，單獨的Pod本身毫無價值。

要素八：通過進程模型進行擴展

要素六所提到的進程模型在并發(fā)機制的實現(xiàn)上大放異彩。前文說過，Kubernetes可以通過不同種類的生命周期控制器來實現(xiàn)無狀態(tài)應(yīng)用的運行時擴展。所需要的副本數(shù)量以聲明式模型定義并可以在運行時變更。同樣，Kubernetes也定義了很多用于管理并發(fā)的生命周期控制器，如ReplicationControllers, ReplicaSets, Deployments, StatefulSets, Jobs和DaemonSets。

下面的動畫展示了副本添加的過程：

ReplicaSet可以用來添加更多的Pod。新創(chuàng)建的Pod會自動響應(yīng)來自Service對象的入站請求。

基于對CPU、內(nèi)存等相關(guān)計算資源以及其他外部指標(biāo)的閾值監(jiān)測，Kubernetes引入了自動擴展的機制。Horizontal Pod Autoscaler (HPA) 可以實現(xiàn)在一個Deployment或者ReplicaSet中自動的擴展Pod的數(shù)量。

HPA基于指標(biāo)的觀測來添加Pod

談及自動擴展，關(guān)于Pod縱向擴展以及集群擴展的話題值得關(guān)注?？v向的Pod擴展適用于有狀態(tài)的應(yīng)用。Kubernetes把CPU和內(nèi)存作為觸發(fā)器，來向Pod中添加更多的計算資源。也可以使用自定義的指標(biāo)代替HPA來觸發(fā)自動擴展。

Vertical Pod Autoscaler擴展了容器的可用內(nèi)存

要素九：快速啟動和優(yōu)雅終止

12要素原則中的可處置性，考慮的是如何使用Linux內(nèi)核的信號機制來與運行的進程交互。遵循可處置性的原則，微服務(wù)可以快速啟動并且可以隨時消亡而不影響用戶體驗。對于無狀態(tài)的微服務(wù)來說，實現(xiàn)與部署相關(guān)的原則有助于達成可處置性。事實上，藉由前文提到的livenessProbes和readinessProbes探針機制，Kubernetes會銷毀在給定的時間窗口內(nèi)處于不健康的Pod。

要素十一：把日志當(dāng)作事件流

對于容器來說，所有的日志通常會記入到stdout或者stderr文件描述符。此處很重要的設(shè)計原則是，容器不應(yīng)該管理用于日志輸出的內(nèi)部文件，而應(yīng)交由容器編排系統(tǒng)來收集日志并進行分析和歸檔。在Kubernetes中，日志收集一般作為公共服務(wù)存在。以我本人的工作經(jīng)歷來說，可以使用Elasticsearch-Logstash-Kibana組合來平滑的實現(xiàn)這一點。

要素十二：把后臺管理任務(wù)當(dāng)作一次性進程運行

像是數(shù)據(jù)庫遷移/備份/恢復(fù)/日常維護這類管理任務(wù)，應(yīng)該與微服務(wù)的基本運行時邏輯隔離并解耦。在Kubernetes中，Job控制器可以創(chuàng)建一次性運行的Pod，或者是按照日程規(guī)劃執(zhí)行不同活動的Pod。Job控制器可以用來實現(xiàn)業(yè)務(wù)邏輯，因為Kubernetes會將API令牌加載到Pod中，所以也可以使用Job控制器來與Kubernetes編排系統(tǒng)進行交互。

通過對此類管理任務(wù)的隔離，可以在未來簡化微服務(wù)的行為，進而減少可能出現(xiàn)的潛在失敗。

四、結(jié)語

如果讀者對這個話題很感興趣，建議點贊轉(zhuǎn)發(fā)與朋友分享本文的觀點。如果你有幸參加KubeCon Europe，歡迎來與我和Brad Topol面基，并且就此話題深入探討，我們會分享Kubernetes相關(guān)能力的更多演示。

除了架構(gòu)微服務(wù)的12原則以外，我和另一位作者，Shikha Srivastava，也識別了生產(chǎn)環(huán)境中遺漏的7條原則，Shikha很快會就此成文。敬請期待。

關(guān)于EAWorld：微服務(wù)，DevOps，數(shù)據(jù)治理，移動架構(gòu)原創(chuàng)技術(shù)分享

新聞標(biāo)題：結(jié)合Kubernetes解讀微服務(wù)的12要素-創(chuàng)新互聯(lián)
當(dāng)前網(wǎng)址：http://www.bm7419.com/article40/cdjieo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化、定制網(wǎng)站、品牌網(wǎng)站建設(shè)、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)