隨著容器采用率和使用率的不斷提高，Kubernetes(K8s)已成為容器編排的領(lǐng)先平臺(tái)。 這是一個(gè)開源項(xiàng)目，擁有來自315多家公司的數(shù)萬名貢獻(xiàn)者，旨在保持可擴(kuò)展性和不可知論性，并且它是每個(gè)主要云提供商的基礎(chǔ)。

[[341879]]

當(dāng)您的容器正在生產(chǎn)中運(yùn)行時(shí)，您希望生產(chǎn)環(huán)境盡可能穩(wěn)定和有彈性，以避免災(zāi)難發(fā)生(請(qǐng)考慮每一次在線黑色星期五購物體驗(yàn))。 當(dāng)一個(gè)容器崩潰時(shí)，無論是在一天中的什么時(shí)候(或在夜晚的凌晨)，另一個(gè)容器都需要啟動(dòng)起來代替它。 Kubernetes提供了一個(gè)框架，可從擴(kuò)展到故障轉(zhuǎn)移再到負(fù)載平衡等等，彈性地運(yùn)行分布式系統(tǒng)。 并且有許多工具與Kubernetes集成在一起，可以滿足您的需求。

最佳做法會(huì)隨著時(shí)間而發(fā)展，因此不斷進(jìn)行研究和實(shí)驗(yàn)以尋求更好的Kubernetes開發(fā)方式總是好事。 由于它仍然是一項(xiàng)年輕技術(shù)，因此我們一直在尋求增進(jìn)對(duì)它的理解和使用。

在本文中，我們將研究Kubernetes部署中的十種常見做法，這些做法在更高層次上具有更好的解決方案。 由于用戶的自定義實(shí)現(xiàn)可能會(huì)有所不同，因此我不會(huì)深入探討最佳實(shí)踐。

• 將配置文件放在Docker映像的內(nèi)部/旁邊
• 不使用Helm或其他種類的模板
• 以特定順序部署。 (應(yīng)用程序應(yīng)該不會(huì)崩潰，因?yàn)橐蕾囮P(guān)系尚未就緒。)
• 在沒有設(shè)置內(nèi)存和/或CPU限制的情況下部署Pod
• 在生產(chǎn)中將最新標(biāo)簽拉到容器中
• 通過殺死Pod來部署新的更新/修復(fù)，以便它們?cè)谥匦聠?dòng)過程中提取新的Docker映像
• 在同一集群中混合生產(chǎn)和非生產(chǎn)工作負(fù)載。
• 對(duì)于關(guān)鍵任務(wù)部署，不使用藍(lán)綠部署或金絲雀部署。 (Kubernetes的默認(rèn)滾動(dòng)更新并不總是足夠的。)
• 沒有適當(dāng)?shù)闹笜?biāo)來了解部署是否成功。 (您的健康檢查需要應(yīng)用程序支持。)
• 云供應(yīng)商鎖定：將自己鎖定在IaaS提供商的Kubernetes或無服務(wù)器計(jì)算服務(wù)中

十個(gè)Kubernetes反模式

1. 將配置文件放在Docker映像的內(nèi)部/旁邊

該Kubernetes反模式與Docker反模式相關(guān)(請(qǐng)參閱本文的反模式5和8)。 容器為開發(fā)人員提供了一種方法，該方法基本上可以在生產(chǎn)環(huán)境中的整個(gè)軟件生命周期(從dev / QA到staging到生產(chǎn))中使用單個(gè)映像。

但是，通常的做法是為生命周期中的每個(gè)階段提供自己的映像，每個(gè)階段都使用針對(duì)其環(huán)境(QA，Staging或生產(chǎn))的不同工件構(gòu)建。 但是現(xiàn)在您不再部署已測(cè)試的產(chǎn)品。

> Don't hardcode your configuration at build time (from https://codefresh.io/containers/docker-anti-

此處的最佳實(shí)踐是外部化ConfigMap中的通用配置，而敏感信息(如API密鑰和機(jī)密)可以存儲(chǔ)在Secrets資源中(該資源具有Base64編碼，但與ConfigMaps相同)。 ConfigMap可以作為卷安裝，也可以作為環(huán)境變量傳遞，但是Secrets應(yīng)該作為卷安裝。 我之所以提到ConfigMap和Secrets，是因?yàn)樗鼈兪荎ubernetes的本機(jī)資源，不需要集成，但是它們可能會(huì)受到限制。 還有其他可用的解決方案，例如HashiCorp的ZooKeeper和Consul用于配置映射，或HashiCorp的Vault，Keywhiz，Confidant等用于秘密，它們可能更適合您的需求。

當(dāng)您將配置與應(yīng)用程序分離后，就無需在需要更新配置時(shí)重新編譯應(yīng)用程序，并且可以在應(yīng)用程序運(yùn)行時(shí)對(duì)其進(jìn)行更新。 您的應(yīng)用程序在運(yùn)行時(shí)而不是在構(gòu)建過程中獲取配置。 更重要的是，您在軟件生命周期的所有階段都使用相同的源代碼。

> Load configuration during runtime (from https://codefresh.io/containers/docker-anti-patterns/)

2. 不使用Helm或其他種類的模板

您可以通過直接更新YAML來管理Kubernetes部署。 推出新版本的代碼時(shí)，您可能必須更新以下一項(xiàng)或多項(xiàng)內(nèi)容：

• Docker映像名稱
• Docker映像標(biāo)簽
• Replica 副本數(shù)
• Lable 服務(wù)標(biāo)簽
• Pod
• Configmap 等

如果您要管理多個(gè)集群并在開發(fā)，登臺(tái)和生產(chǎn)環(huán)境中應(yīng)用相同的更新，這可能會(huì)變得很乏味。 您基本上是在所有部署中進(jìn)行少量修改的情況下修改相同文件。 它進(jìn)行了大量的復(fù)制和粘貼，或搜索和替換，同時(shí)還了解部署YAML的目標(biāo)環(huán)境。 在此過程中，有很多出錯(cuò)的機(jī)會(huì)：

• 拼寫錯(cuò)誤(版本號(hào)錯(cuò)誤，圖片名稱拼寫錯(cuò)誤等)
• 使用錯(cuò)誤的更新修改YAML(例如，連接到錯(cuò)誤的數(shù)據(jù)庫)
• 缺少要更新的資源，等等。

您可能需要在YAML中進(jìn)行很多更改，如果您不密切注意，則很容易將一個(gè)YAML誤認(rèn)為另一個(gè)部署的YAML。

模板有助于簡(jiǎn)化Kubernetes應(yīng)用程序的安裝和管理。 由于Kubernetes沒有提供本地的模板機(jī)制，因此我們必須在其他地方尋求這種管理。

Helm是第一個(gè)可用的包管理器(2015年)。 它被稱為" Kubernetes的自制軟件"，并發(fā)展為包括模板功能。 Helm通過圖表打包其資源，其中圖表是描述一組相關(guān)的Kubernetes資源的文件的集合。 圖表存儲(chǔ)庫中有1,400多個(gè)公開可用的圖表(您也可以使用 helm search hub [keyword] [flags])，這些是可重復(fù)使用的配方，用于在Kubernetes上進(jìn)行安裝，升級(jí)和卸載。 使用Helm Chart，您可以修改values.yaml文件以設(shè)置Kubernetes部署所需的修改，并且每種環(huán)境都可以使用不同的Helm圖表。 因此，如果您具有質(zhì)量檢查，過渡和生產(chǎn)環(huán)境，則只需管理三個(gè)Helm Chart，而無需在每個(gè)環(huán)境中的每個(gè)部署中修改每個(gè)YAML。

我們使用Helm的另一個(gè)優(yōu)勢(shì)是，如果出現(xiàn)問題，可以通過Helm回滾很容易地回滾到以前的版本：

helm rollback <RELEASE> [REVISION] [flags] 

如果要回滾到之前的先前版本，可以使用：

helm rollback <RELEASE> 0 

因此，我們將看到類似以下內(nèi)容的內(nèi)容：

$ helm upgrade — install — wait — timeout 20 demo demo/ 
$ helm upgrade — install — wait — timeout 20 — set 
readinessPath=/fail demo demo/$ helm rollback — wait — timeout 20 demo 1Rollback was a success. 

Helm Chart 歷史很好地跟蹤了它：

$ helm history demo 
REVISION STATUS DESCRIPTION 
1 SUPERSEDED Install complete 
2 SUPERSEDED Upgrade “demo” failed: timed out waiting for the condition 
3 DEPLOYED Rollback to 1 

除了Helm之外，還可以使用Google的Kustomize，它是一種流行的替代方法。

3. 按特定順序部署事物

應(yīng)用程序應(yīng)該不會(huì)崩潰，因?yàn)橐蕾図?xiàng)尚未就緒。 在傳統(tǒng)開發(fā)中，啟動(dòng)應(yīng)用程序時(shí)，啟動(dòng)和停止任務(wù)有特定的順序。 重要的是不要將這種思想帶入容器編排中。 使用Kubernetes，Docker等，這些組件可以同時(shí)啟動(dòng)，因此無法定義啟動(dòng)順序。 即使在應(yīng)用程序啟動(dòng)并運(yùn)行時(shí)，其依賴關(guān)系也可能失敗或遷移，從而導(dǎo)致進(jìn)一步的問題。 Kubernetes現(xiàn)實(shí)也充斥著無數(shù)潛在的通信故障，這些故障無法達(dá)到依賴關(guān)系，在此期間，pod可能崩潰或服務(wù)可能不可用。 網(wǎng)絡(luò)延遲，例如信號(hào)微弱或網(wǎng)絡(luò)連接中斷，是導(dǎo)致通信失敗的常見原因。

為簡(jiǎn)單起見，讓我們研究一個(gè)假設(shè)的購物應(yīng)用程序，該應(yīng)用程序具有兩項(xiàng)服務(wù)：庫存數(shù)據(jù)庫和店面用戶界面。 在啟動(dòng)應(yīng)用程序之前，后端服務(wù)必須啟動(dòng)，滿足其所有檢查并開始運(yùn)行。 然后，前端服務(wù)可以啟動(dòng)，通過檢查并開始運(yùn)行。

假設(shè)我們已經(jīng)使用kubectl wait命令強(qiáng)制執(zhí)行了部署命令，例如：

kubectl wait — for=condition=Ready pod/serviceA 

但是，如果從不滿足條件，則無法進(jìn)行下一次部署，并且過程會(huì)中斷。

這是部署順序的簡(jiǎn)單流程：

> This process cannot move forward until the previous step is complete

由于Kubernetes具有自我修復(fù)功能。 標(biāo)準(zhǔn)方法是讓應(yīng)用程序中的所有服務(wù)同時(shí)啟動(dòng)，并使容器崩潰并重新啟動(dòng)，直到它們?nèi)繂?dòng)并運(yùn)行。 我讓服務(wù)A和B獨(dú)立啟動(dòng)(就像一個(gè)解耦的無狀態(tài)云原生應(yīng)用程序一樣)，但是出于用戶體驗(yàn)的考慮，也許我可以告訴UI(服務(wù)B)顯示漂亮的加載消息，直到服務(wù)A被 準(zhǔn)備就緒，但是服務(wù)B的實(shí)際啟動(dòng)不應(yīng)受到服務(wù)A的影響。

> Now when the pod crashes, Kubernetes restarts the service until everything is up and running. If y

當(dāng)然，我們需要做的不僅僅是單純依靠自我修復(fù)。 我們需要實(shí)施解決故障的解決方案，這些故障是不可避免的并會(huì)發(fā)生。 我們應(yīng)該預(yù)料到它們會(huì)發(fā)生，并制定框架進(jìn)行響應(yīng)，以幫助我們避免停機(jī)和/或數(shù)據(jù)丟失。

在我的假設(shè)購物應(yīng)用程序中，我的店面UI(服務(wù)B)需要庫存(服務(wù)A)以便為用戶提供完整的體驗(yàn)。 因此，如果出現(xiàn)部分故障，例如服務(wù)A短時(shí)間內(nèi)不可用或崩潰等，系統(tǒng)仍應(yīng)能夠從問題中恢復(fù)。

像這樣的瞬態(tài)故障是一種經(jīng)常出現(xiàn)的可能性，因此，為了將其影響降至最低，我們可以實(shí)施重試模式。 重試模式可通過以下策略幫助提高應(yīng)用程序的穩(wěn)定性：

• 取消如果故障不是暫時(shí)性的，或者如果反復(fù)嘗試該過程不太可能成功，則應(yīng)用程序應(yīng)取消該操作并報(bào)告異常，例如身份驗(yàn)證失敗。 無效的憑證永遠(yuǎn)不會(huì)起作用!
• 重試如果故障是異常或罕見的，則可能是由于異常情況(例如，網(wǎng)絡(luò)數(shù)據(jù)包損壞)引起的。 應(yīng)用程序應(yīng)立即重試該請(qǐng)求，因?yàn)椴惶赡茉俅伟l(fā)生相同的故障。
• 延遲后重試如果故障是由于常見情況(例如連接性或繁忙故障)引起的，那么最好先清除所有工作積壓或流量，然后再重試。 該應(yīng)用程序應(yīng)等待，然后重試該請(qǐng)求。
• 您還可以使用指數(shù)退避來實(shí)現(xiàn)重試模式(以指數(shù)方式增加等待時(shí)間并設(shè)置最大重試次數(shù))。

在創(chuàng)建彈性微服務(wù)應(yīng)用程序時(shí)，實(shí)現(xiàn)斷路模式也是重要的策略。 就像您家中的斷路器將如何自動(dòng)切換以保護(hù)您免受過大電流或短路造成的廣泛損害一樣，斷路器模式為您提供了一種編寫應(yīng)用程序的方法，同時(shí)可以限制可能需要較長時(shí)間才能解決的意外故障的影響。 修復(fù)，例如部分失去連接性或服務(wù)完全失敗。 在無法重試的情況下，應(yīng)用程序應(yīng)該能夠接受失敗的發(fā)生并做出相應(yīng)的響應(yīng)。

4. 部署沒有設(shè)置內(nèi)存和/或CPU限制的pod

資源分配取決于服務(wù)，并且在不測(cè)試實(shí)現(xiàn)的情況下很難預(yù)測(cè)容器可能需要哪些資源才能獲得最佳性能。 一種服務(wù)可能需要固定的CPU和內(nèi)存使用情況配置文件，而另一種服務(wù)的使用情況配置文件可能是動(dòng)態(tài)的。

如果在未仔細(xì)考慮內(nèi)存和CPU限制的情況下部署Pod，可能會(huì)導(dǎo)致資源爭(zhēng)用和不穩(wěn)定的環(huán)境。 如果容器沒有內(nèi)存或CPU限制，那么調(diào)度程序會(huì)將其內(nèi)存利用率(和CPU利用率)視為零，因此可以在任何節(jié)點(diǎn)上調(diào)度無限數(shù)量的Pod。 這可能導(dǎo)致資源過量使用，并可能導(dǎo)致節(jié)點(diǎn)崩潰和kubelet崩潰。

如果未為容器指定內(nèi)存限制，則可能有兩種情況(這些情況也適用于CPU)：

• 容器可以使用的內(nèi)存量沒有上限。 因此，容器可以使用其節(jié)點(diǎn)上的所有可用內(nèi)存，可能會(huì)調(diào)用OOM(內(nèi)存不足)殺手。 沒有資源限制的容器發(fā)生OOM銷毀情況的可能性更大。
• 命名空間(容器在其中運(yùn)行)的默認(rèn)內(nèi)存限制已分配給容器。 群集管理員可以使用LimitRange指定內(nèi)存限制的默認(rèn)值。

聲明群集中容器的內(nèi)存和CPU限制，可以有效利用群集節(jié)點(diǎn)上的可用資源。 這有助于kube-scheduler確定Pod應(yīng)該駐留在哪個(gè)節(jié)點(diǎn)上，以實(shí)現(xiàn)最有效的硬件利用率。

在設(shè)置容器的內(nèi)存和CPU限制時(shí)，應(yīng)注意不要請(qǐng)求超出限制的資源。 對(duì)于具有多個(gè)容器的容器，聚合資源請(qǐng)求不得超過設(shè)置的限制-否則，將永遠(yuǎn)不會(huì)調(diào)度容器。

> The resource request must not exceed the limit

將內(nèi)存和CPU請(qǐng)求設(shè)置為低于其限制可以完成兩件事：

• Pod在可用時(shí)可以使用內(nèi)存/ CPU，從而導(dǎo)致活動(dòng)大量爆發(fā)。
• 在突發(fā)期間，Pod僅限于合理數(shù)量的內(nèi)存/ CPU。

最佳實(shí)踐是將CPU請(qǐng)求保持在一個(gè)內(nèi)核或以下，然后使用ReplicaSets進(jìn)行擴(kuò)展，從而提高了系統(tǒng)的靈活性和可靠性。

當(dāng)您在同一集群中部署容器時(shí)，如果有不同的團(tuán)隊(duì)競(jìng)爭(zhēng)資源，會(huì)發(fā)生什么情況? 如果該進(jìn)程超出內(nèi)存限制，則它將終止，而如果超過CPU限制，則將限制該進(jìn)程(導(dǎo)致更差的性能)。

您可以通過名稱空間設(shè)置中的資源配額和LimitRange控制資源限制。 這些設(shè)置有助于解決無限制或資源需求高的容器部署問題。

設(shè)置硬資源限制可能不是滿足您需求的最佳選擇。 另一個(gè)選擇是在Vertical Pod自動(dòng)縮放器資源中使用推薦模式。

5. 在生產(chǎn)中將"Latest"標(biāo)簽拉到容器中

使用Latest標(biāo)簽被認(rèn)為是不良做法，尤其是在生產(chǎn)中。 由于各種原因，pod意外崩潰，因此它們可以隨時(shí)下拉鏡像。 不幸的是，在確定構(gòu)建何時(shí)中斷時(shí)，最新標(biāo)簽的描述性不是很高。 正在運(yùn)行哪個(gè)版本的鏡像? 上次工作是什么時(shí)候? 這在生產(chǎn)中尤其不利，因?yàn)槟枰軌蛞宰钌俚耐C(jī)時(shí)間使事情恢復(fù)并運(yùn)行。

> You shouldn't use the latest tag in production.

默認(rèn)情況下，imagePullPolicy設(shè)置為"Always"，并且在重新啟動(dòng)圖像時(shí)始終將其下拉。 如果您不指定標(biāo)簽，Kubernetes將默認(rèn)為最新。 但是，只有在發(fā)生崩潰(當(dāng)pod在重啟時(shí)拉下映像)或更改部署pod的模板(.spec.template)時(shí)，才會(huì)更新部署。 請(qǐng)參閱此論壇討論，以獲取最新的示例在開發(fā)中無法正常工作。

即使您將imagePullPolicy更改為Always之外的其他值，如果需要重新啟動(dòng)(無論是由于崩潰還是故意重新啟動(dòng))，您的pod仍會(huì)拉取鏡像。 如果使用版本控制并使用有意義的標(biāo)記(例如v1.4.0)設(shè)置imagePullPolicy，則可以回滾到最新的穩(wěn)定版本，并更容易地解決代碼中何時(shí)何處出了問題。 您可以在語義版本規(guī)范和GCP最佳實(shí)踐中閱讀有關(guān)版本最佳實(shí)踐的更多信息。

除了使用特定且有意義的Docker標(biāo)簽外，您還應(yīng)該記住容器是無狀態(tài)且不可變的。 它們也應(yīng)該是短暫的(您應(yīng)該將任何數(shù)據(jù)存儲(chǔ)在容器外部的持久存儲(chǔ)中)。 一旦啟動(dòng)了容器，就不應(yīng)對(duì)其進(jìn)行修改：沒有補(bǔ)丁，沒有更新，沒有配置更改。 當(dāng)需要更新配置時(shí)，應(yīng)使用更新的配置部署新容器。

> Docker immutability, taken from Best Practices for Operating Containers.

這種不變性可以實(shí)現(xiàn)更安全，可重復(fù)的部署。 如果您需要重新部署舊映像，也可以更輕松地回滾。 通過使Docker映像和容器保持不變，您可以在每個(gè)單獨(dú)的環(huán)境中部署相同的容器映像。 請(qǐng)參閱反模式1，以了解有關(guān)外部化配置數(shù)據(jù)以保持映像不變的信息。

> We can roll back to the previous stable version while we troubleshoot.

6. 通過殺死Pod來部署新的更新/修復(fù)程序，以便它們?cè)谥貑⑦^程中提取新的Docker鏡像

就像依靠最新標(biāo)簽來獲取更新一樣，依靠殺死Pod來推出新更新也是一種壞習(xí)慣，因?yàn)槟粚?duì)代碼進(jìn)行版本控制。 如果您要?dú)⑺赖跖撘栽谏a(chǎn)環(huán)境中提取更新的Docker映像，請(qǐng)不要這樣做。 一旦將某個(gè)版本發(fā)布到生產(chǎn)環(huán)境中，就永遠(yuǎn)不能覆蓋它。 如果出現(xiàn)問題，那么您將不知道哪里出問題或何時(shí)出問題，以及在進(jìn)行故障排除時(shí)需要回滾代碼的時(shí)間。

另一個(gè)問題是，重啟容器以提取新的Docker鏡像并不總是可行。 "只有且僅當(dāng)更改了部署的Pod模板(即.spec.template)(例如，模板的標(biāo)簽或容器映像已更新)時(shí)，才會(huì)觸發(fā)部署的推出。 其他更新，例如擴(kuò)展部署，不會(huì)觸發(fā)部署。"

您必須修改.spec.template才能觸發(fā)部署。

更新您的Pod以提取新Docker映像的正確方法是對(duì)代碼進(jìn)行版本化(或增加修訂/補(bǔ)丁)，然后修改部署規(guī)范以反映有意義的標(biāo)簽(不是最新的，請(qǐng)參閱反模式5)，以進(jìn)一步討論。 ，但類似于v1.4.0(針對(duì)新版本)或v1.4.1(針對(duì)補(bǔ)丁)。 然后Kubernetes將以零停機(jī)時(shí)間觸發(fā)升級(jí)。

• Kubernetes使用新映像啟動(dòng)一個(gè)新容器。
• 等待健康檢查通過。
• 刪除舊的Pod。

7. 在同一集群中混合生產(chǎn)和非生產(chǎn)工作負(fù)載

Kubernetes支持名稱空間功能，該功能使用戶可以管理同一物理群集中的不同環(huán)境(虛擬群集)。 命名空間可視為在單個(gè)物理群集上管理不同環(huán)境的一種經(jīng)濟(jì)高效的方式。 例如，您可以在同一群集中運(yùn)行暫存和生產(chǎn)環(huán)境，從而節(jié)省資源和金錢。 但是，在開發(fā)中運(yùn)行Kubernetes與在生產(chǎn)中運(yùn)行Kubernetes之間有很大的差距。

在同一集群上混合生產(chǎn)和非生產(chǎn)工作負(fù)載時(shí)，需要考慮很多因素。 例如，您必須考慮資源限制，以確保生產(chǎn)環(huán)境的性能不受影響(一種常見的做法是，在生產(chǎn)名稱空間上不設(shè)置配額，在任何非生產(chǎn)名稱空間上都設(shè)置配額。 )。

您還需要考慮隔離。 與生產(chǎn)環(huán)境相比，開發(fā)人員需要更多的訪問權(quán)限和許可，您可能希望將它們盡可能地鎖定。 雖然名稱空間彼此隱藏，但默認(rèn)情況下它們并未完全隔離。 這意味著開發(fā)人員命名空間中的應(yīng)用程序可以在測(cè)試，登臺(tái)或生產(chǎn)中調(diào)用應(yīng)用程序(反之亦然)，這不是一個(gè)好習(xí)慣。 當(dāng)然，您可以使用NetworkPolicies設(shè)置規(guī)則以隔離名稱空間。

但是，徹底測(cè)試資源限制，性能，安全性和可靠性非常耗時(shí)，因此不建議在與非生產(chǎn)工作負(fù)載相同的群集中運(yùn)行生產(chǎn)工作負(fù)載。 與其將生產(chǎn)和非生產(chǎn)工作負(fù)載混合在同一個(gè)集群中，不如將單獨(dú)的集群用于開發(fā)/測(cè)試/生產(chǎn)-這樣您將獲得更好的隔離和安全性。 對(duì)于CI / CD和升級(jí)，還應(yīng)該盡可能地自動(dòng)化，以減少人為錯(cuò)誤的可能性。 您的生產(chǎn)環(huán)境需要盡可能牢固。

8. 不使用藍(lán)綠部署或金絲雀部署關(guān)鍵任務(wù)

許多現(xiàn)代應(yīng)用程序都有頻繁的部署，范圍從一個(gè)月內(nèi)的幾次更改到一天之內(nèi)的多次部署。 微服務(wù)體系結(jié)構(gòu)肯定可以實(shí)現(xiàn)這一點(diǎn)，因?yàn)橹灰鼈兡軌騾f(xié)同工作以無縫執(zhí)行，就可以在不同的周期上開發(fā)，管理和發(fā)布不同的組件。 當(dāng)然，在推出更新時(shí)，保持應(yīng)用程序全天候24/7顯然很重要。

Kubernetes的默認(rèn)滾動(dòng)更新并不總是足夠的。 執(zhí)行更新的常見策略是使用默認(rèn)的Kubernetes滾動(dòng)更新功能：

.spec.strategy.type==RollingUpdate 

您可以在其中設(shè)置maxUnavailable(可用Pod的百分比或數(shù)量)和maxSurge字段(可選)來控制滾動(dòng)更新過程。 如果實(shí)施得當(dāng)，則滾動(dòng)更新允許在Pod進(jìn)行增量更新時(shí)以零停機(jī)時(shí)間進(jìn)行逐步更新。 這是一個(gè)團(tuán)隊(duì)如何通過滾動(dòng)更新以零停機(jī)時(shí)間更新其應(yīng)用程序的示例。

但是，一旦將部署更新為下一個(gè)版本，就很難總是回去。 您應(yīng)該有一個(gè)計(jì)劃，將其回滾以防生產(chǎn)中斷。 當(dāng)您的Pod更新到下一個(gè)版本時(shí)，部署將創(chuàng)建一個(gè)新的ReplicaSet。 雖然Kubernetes將存儲(chǔ)以前的ReplicaSets(默認(rèn)情況下為10個(gè)，但是您可以使用spec.revisionHistoryLimit進(jìn)行更改)。 副本集以諸如app6ff34b8374之類的名稱隨機(jī)存儲(chǔ)，并且在部署應(yīng)用程序YAML中找不到對(duì)副本集的引用。 您可以通過以下方式找到它：

ReplicaSet.metadata.annotation 

并使用以下命令檢查修訂：

kubectl get replicaset app-6ff88c4474 -o yaml 

查找修訂號(hào)。 這很復(fù)雜，因?yàn)槌悄赮AML資源中留下注釋，否則發(fā)布?xì)v史記錄不會(huì)保留日志(您可以使用— record標(biāo)志來完成此操作：

$kubectl rollout history deployment/appREVISION CHANGE-CAUSE1 kubectl create — filename=deployment.yaml — record=true 
2 kubectl apply — filename=deployment.yaml — record=true 

當(dāng)您有數(shù)十個(gè)，數(shù)百個(gè)甚至數(shù)千個(gè)部署同時(shí)進(jìn)行更新時(shí)，很難一次跟蹤所有更新。 而且，如果您存儲(chǔ)的修訂全部包含相同的回歸，那么您的生產(chǎn)環(huán)境將不會(huì)處于良好狀態(tài)! 您可以在本文中詳細(xì)了解有關(guān)使用滾動(dòng)更新的信息。

其他一些問題是：

• 并非所有的應(yīng)用程序都能夠同時(shí)運(yùn)行多個(gè)版本。
• 您的群集在更新中間可能會(huì)耗盡資源，這可能會(huì)中斷整個(gè)過程。

這些都是在生產(chǎn)環(huán)境中遇到的非常令人沮喪和壓力大的問題。

更可靠地更新部署的替代方法包括：

藍(lán)綠(紅黑)部署使用藍(lán)色/綠色，同時(shí)存在完整的舊實(shí)例和新實(shí)例。 藍(lán)色是活動(dòng)版本，新版本已部署到綠色副本。 當(dāng)綠色環(huán)境通過其測(cè)試和驗(yàn)證后，負(fù)載平衡器將流量切換到綠色，綠色即為藍(lán)色環(huán)境，而舊版本則變?yōu)榫G色。 由于我們維護(hù)了兩個(gè)完整版本，因此執(zhí)行回滾很簡(jiǎn)單-您需要做的就是切換回負(fù)載平衡器。

> The load balancer flips between blue and green to set the active version. From Continuous Deployme

其他優(yōu)點(diǎn)包括：

• 由于我們從未直接部署到生產(chǎn)環(huán)境，因此當(dāng)我們將綠色更改為藍(lán)色時(shí)，壓力非常小。
• 流量重定向會(huì)立即發(fā)生，因此不會(huì)造成停機(jī)。
• 可以進(jìn)行大量測(cè)試以反映切換之前的實(shí)際生產(chǎn)。 (如前所述，開發(fā)環(huán)境與生產(chǎn)環(huán)境非常不同。)

Kubernetes不包括藍(lán)色/綠色部署作為其本機(jī)工具之一。 在本教程中，您可以閱讀有關(guān)如何在您的CI / CD自動(dòng)化中實(shí)現(xiàn)藍(lán)色/綠色的更多信息。

Canary版本Canary版本使我們能夠在影響整個(gè)生產(chǎn)系統(tǒng)/用戶群之前測(cè)試潛在問題并滿足關(guān)鍵指標(biāo)。 我們通過直接部署到生產(chǎn)環(huán)境(但僅部署到一小部分用戶)來"進(jìn)行生產(chǎn)測(cè)試"。 您可以選擇基于百分比或由區(qū)域/用戶位置，客戶端類型和計(jì)費(fèi)屬性決定的路由。 即使部署到較小的子集，也必須仔細(xì)監(jiān)視應(yīng)用程序性能并衡量錯(cuò)誤，這些指標(biāo)也很重要-這些指標(biāo)定義了質(zhì)量閾值。 如果應(yīng)用程序的行為符合預(yù)期，我們將開始傳輸更多的新版本實(shí)例以支持更多流量。

> The load balancer gradually releases the new version into production. From Continuous Deployment S

其他優(yōu)點(diǎn)包括：

• 可觀察性
• 測(cè)試生產(chǎn)流量的能力(很難獲得真正的類似于生產(chǎn)的開發(fā)經(jīng)驗(yàn))
• 能夠向一小部分用戶發(fā)布版本，并在大版本發(fā)布之前獲得實(shí)際反饋
• 快速失敗。 由于我們直接將其部署到生產(chǎn)中，因此如果發(fā)生中斷，我們可能會(huì)快速失敗(即立即還原)，并且它只會(huì)影響一部分，而不會(huì)影響整個(gè)社區(qū)。

9. 沒有適當(dāng)?shù)闹笜?biāo)來了解部署是否成功

您的健康檢查需要應(yīng)用程序支持。

您可以利用Kubernetes完成容器編排中的許多任務(wù)：

• 控制應(yīng)用程序或團(tuán)隊(duì)的資源消耗(命名空間，CPU /內(nèi)存，限制)，以阻止應(yīng)用程序消耗過多的資源
• 跨不同應(yīng)用程序?qū)嵗M(jìn)行負(fù)載平衡，如果資源不足或主機(jī)死機(jī)，則將應(yīng)用程序?qū)嵗龔囊慌_(tái)主機(jī)移至另一臺(tái)主機(jī)
• 自我修復(fù)—如果容器崩潰，則重新啟動(dòng)
• 如果將新主機(jī)添加到群集，則自動(dòng)利用其他資源
• 和更多

因此，有時(shí)很容易忘記指標(biāo)和監(jiān)控。 但是，成功的部署并不是您的操作工作的終點(diǎn)。 最好積極主動(dòng)，為意外的意外做好準(zhǔn)備。 還有更多的層要監(jiān)視，而K8s的動(dòng)態(tài)特性使其很難進(jìn)行故障排除。 例如，如果您沒有密切關(guān)注可用資源，則pod的自動(dòng)重新安排可能會(huì)導(dǎo)致容量問題，并且您的應(yīng)用可能會(huì)崩潰或永遠(yuǎn)不會(huì)部署。 這在生產(chǎn)中尤其不幸，因?yàn)槌怯腥颂峤诲e(cuò)誤報(bào)告或您碰巧對(duì)其進(jìn)行檢查，否則您將不會(huì)知道。

監(jiān)視面臨著一系列挑戰(zhàn)：需要監(jiān)視很多層次，并且需要"在工程師身上保持相當(dāng)?shù)偷木S護(hù)負(fù)擔(dān)"。 當(dāng)運(yùn)行在Kubernetes上的應(yīng)用遇到問題時(shí)，有很多日志，數(shù)據(jù)和組件需要研究，尤其是當(dāng)涉及到多個(gè)微服務(wù)時(shí)，與傳統(tǒng)的單片架構(gòu)相比，該問題將所有內(nèi)容輸出到一些日志中。

對(duì)應(yīng)用程序行為的見解(例如應(yīng)用程序的性能)可幫助您不斷改進(jìn)。 您還需要對(duì)容器，pod，服務(wù)和整個(gè)集群有一個(gè)整體的了解。 如果您可以確定應(yīng)用程序如何使用其資源，則可以使用Kubernetes更好地檢測(cè)和消除瓶頸。 要全面了解該應(yīng)用程序，您需要使用諸如Prometheus，Grafana，New Relic或Cisco AppDynamics等應(yīng)用程序性能監(jiān)視解決方案。

無論您是否決定使用監(jiān)視解決方案，這些都是Kubernetes文檔建議您密切跟蹤的關(guān)鍵指標(biāo)：

• 運(yùn)行Pod及其部署
• 資源指標(biāo)：CPU，內(nèi)存使用率，磁盤I / O
• 容器原生指標(biāo)
• 應(yīng)用指標(biāo)

10. 云供應(yīng)商鎖定：將自己鎖定在IaaS提供商的Kubernetes或無服務(wù)器計(jì)算服務(wù)中

鎖定有多種類型(如果您想了解更多信息，Martin Fowler會(huì)寫一篇很棒的文章)，但是供應(yīng)商鎖定否定了部署到云的主要價(jià)值：容器靈活性。 的確，選擇合適的云提供商并非易事。 每個(gè)提供商都有其自己的接口，開放的API以及專有的規(guī)范和標(biāo)準(zhǔn)。 此外，一個(gè)提供商可能比其他提供商更適合您的需求，僅是因?yàn)槟臉I(yè)務(wù)需求發(fā)生了意外變化。

幸運(yùn)的是，容器與平臺(tái)無關(guān)且可移植，并且所有主要的提供商都具有與云無關(guān)的Kubernetes基礎(chǔ)。 當(dāng)您需要在云之間移動(dòng)工作負(fù)載時(shí)，您不必重新架構(gòu)或重寫應(yīng)用程序代碼，因此您不必將自己鎖定在云提供商中，因?yàn)槟鸁o法"提升和轉(zhuǎn)移"。

以下是您應(yīng)考慮采取的措施，以確保可以靈活地防止或最小化供應(yīng)商鎖定。

(1) 首先，房間整理：請(qǐng)閱讀細(xì)則

談判進(jìn)入和退出策略。 許多供應(yīng)商都使啟動(dòng)變得容易，并且很容易上癮。 這可能包括免費(fèi)試用或贈(zèng)金之類的激勵(lì)措施，但是隨著您擴(kuò)大規(guī)模，這些費(fèi)用可能會(huì)迅速增加。

檢查是否有自動(dòng)續(xù)訂，提早終止費(fèi)用之類的內(nèi)容，以及提供商在遷移到另一家供應(yīng)商以及與退出相關(guān)的SLA時(shí)是否會(huì)幫助進(jìn)行轉(zhuǎn)換等方面的工作。

(2) 設(shè)計(jì)/設(shè)計(jì)您的應(yīng)用程序，使其可以在任何云上運(yùn)行

如果您已經(jīng)在為云開發(fā)并使用云原生原理，那么您的應(yīng)用程序代碼很可能應(yīng)該易于提升和轉(zhuǎn)移。 圍繞代碼的事情可能將您鎖定在云供應(yīng)商中。 例如，您可以：

• 檢查應(yīng)用程序使用的服務(wù)和功能(例如數(shù)據(jù)庫，API等)是否可移植。
• 檢查您的部署和配置腳本是否特定于云。 某些云具有自己的本機(jī)或推薦的自動(dòng)化工具，這些工具可能無法輕松轉(zhuǎn)換為其他提供商。 有許多工具可用于協(xié)助云基礎(chǔ)架構(gòu)自動(dòng)化，并且與許多主要云提供商兼容，例如Puppet，Ansible和Chef。 該博客有一個(gè)方便的圖表，比較了常用工具的特性。
• 檢查您的DevOps環(huán)境(通常包括Git和CI / CD)是否可以在任何云中運(yùn)行。 例如，許多云具有自己特定的CI / CD工具，例如IBM Cloud Continuous Delivery，Azure CI / CD或AWS Pipelines，這可能需要額外的工作才能移植到另一個(gè)云供應(yīng)商。 取而代之的是，您可以使用Codefresh之類的完整CI / CD解決方案，這些解決方案對(duì)Docker和Kubernetes具有強(qiáng)大的支持，并與許多其他流行工具集成。 還有許多其他解決方案，例如CI或CD，或兩者都有，例如GitLab，Bamboo，Jenkins，Travis等。
• 檢查是否需要在提供商之間更改測(cè)試過程。

(3) 您還可以選擇遵循多云策略

借助多云策略，您可以從不同的云提供商中挑選和選擇最適合您希望交付的應(yīng)用程序類型的服務(wù)。 在計(jì)劃多云部署時(shí)，應(yīng)仔細(xì)考慮互操作性。

摘要

Kubernetes確實(shí)很受歡迎，但是很難上手，而且傳統(tǒng)開發(fā)中有很多實(shí)踐都無法轉(zhuǎn)化為云原生開發(fā)。

在本文中，我們研究了：

• 將配置文件放在Docker映像的內(nèi)部/旁邊：將您的配置數(shù)據(jù)外部化。 您可以使用ConfigMap和Secrets或類似的東西。
• 不使用Helm或其他類型的模板：使用Helm或Kustomize可以簡(jiǎn)化您的容器編排并減少人為錯(cuò)誤。
• 按照特定的順序部署事物：應(yīng)用程序不應(yīng)崩潰，因?yàn)橐蕾図?xiàng)尚未就緒。 利用Kubernetes的自我修復(fù)機(jī)制并實(shí)現(xiàn)重試和斷路器。
• 在沒有設(shè)置內(nèi)存和/或CPU限制的情況下部署Pod：您應(yīng)該考慮設(shè)置內(nèi)存和CPU限制以減少資源爭(zhēng)用的風(fēng)險(xiǎn)，尤其是在與其他人共享群集時(shí)。
• 在生產(chǎn)中將Latest標(biāo)簽拉到容器中：切勿使用最新標(biāo)簽。 始終使用有意義的內(nèi)容(例如v1.4.0 /根據(jù)語義版本規(guī)范)，并使用不可變的Docker映像。
• 通過殺死Pod來部署新的更新/補(bǔ)丁，以便它們?cè)谥匦聠?dòng)過程中提取新的Docker映像：對(duì)代碼進(jìn)行版本控制，以便更好地管理發(fā)布。
• 在同一群集中混合生產(chǎn)和非生產(chǎn)工作負(fù)載：如果可以，在單獨(dú)的群集中運(yùn)行生產(chǎn)和非生產(chǎn)工作負(fù)載。 這樣可以減少資源爭(zhēng)用和環(huán)境意外過渡對(duì)生產(chǎn)環(huán)境造成的風(fēng)險(xiǎn)。
• 不對(duì)任務(wù)關(guān)鍵型部署使用藍(lán)綠或金絲雀部署(Kubernetes的默認(rèn)滾動(dòng)更新并不總是足夠)：您應(yīng)該考慮使用藍(lán)綠部署或金絲雀版本，以減輕生產(chǎn)中的壓力并獲得更有意義的生產(chǎn)結(jié)果。
• 沒有適當(dāng)?shù)闹笜?biāo)來了解部署是否成功(您的運(yùn)行狀況檢查需要應(yīng)用程序支持)：您應(yīng)該確保監(jiān)視部署，以免發(fā)生任何意外情況。 您可以使用Prometheus，Grafana，New Relic或Cisco AppDynamics之類的工具來幫助您更好地了解部署情況。
• 云供應(yīng)商鎖定：將自己鎖定在IaaS提供商的Kubernetes或無服務(wù)器計(jì)算服務(wù)中：您的業(yè)務(wù)需求可能隨時(shí)發(fā)生變化。 您不應(yīng)無意間將自己鎖定在云提供商中，因?yàn)槟梢暂p松地提升和轉(zhuǎn)移云原生應(yīng)用程序。

謝謝閱讀!