云計算

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

作者：Michael D. Elder

譯者：白小白

原題：Kubernetes & 12-factor apps

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

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

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

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

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

一、與編碼有關的要素

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

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

Sourcecontrolallthethings

源碼控制一切

要素一：一份基準代碼，多份部署

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

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

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

要素五：嚴格分離構建、發(fā)布和運行

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

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

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

二、與部署有關的要素

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

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

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

Pod以及相關的Kubernetes對象

要素二：顯式聲明依賴關系

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

譯注：

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

更多內容參見http://t.cn/EorvPAh

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

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

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

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

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

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

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

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

watson-conversation.yaml hosted with ❤ by GitHub

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

要素四：把后端服務當作附加資源

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

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

要素七：通過端口綁定提供服務

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

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

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

處理對Pod的相關請求的負載均衡的Service聲明示例：

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

三、與運營有關的要素

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

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

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

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

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

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

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

HPA基于指標的觀測來添加Pod

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

Vertical Pod Autoscaler擴展了容器的可用內存

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

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

要素十一：把日志當作事件流

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

要素十二：把后臺管理任務當作一次性進程運行

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

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

四、結語

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

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

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

總結

以上是生活随笔為你收集整理的结合Kubernetes解读微服务的12要素的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。