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

[[341879]]

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

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

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

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

十個Kubernetes反模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

kubectl wait — for=condition=Ready pod/serviceA 

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

這是部署順序的簡單流程：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> The resource request must not exceed the limit

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

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

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

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

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

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

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

使用Latest標(biāo)簽被認為是不良做法，尤其是在生產(chǎn)中。 由于各種原因，pod意外崩潰，因此它們可以隨時下拉鏡像。 不幸的是，在確定構(gòu)建何時中斷時，最新標(biāo)簽的描述性不是很高。 正在運行哪個版本的鏡像? 上次工作是什么時候? 這在生產(chǎn)中尤其不利，因為您需要能夠以最少的停機時間使事情恢復(fù)并運行。

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

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

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

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

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

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

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

6. 通過殺死Pod來部署新的更新/修復(fù)程序，以便它們在重啟過程中提取新的Docker鏡像

就像依靠最新標(biāo)簽來獲取更新一樣，依靠殺死Pod來推出新更新也是一種壞習(xí)慣，因為您不對代碼進行版本控制。 如果您要殺死吊艙以在生產(chǎn)環(huán)境中提取更新的Docker映像，請不要這樣做。 一旦將某個版本發(fā)布到生產(chǎn)環(huán)境中，就永遠不能覆蓋它。 如果出現(xiàn)問題，那么您將不知道哪里出問題或何時出問題，以及在進行故障排除時需要回滾代碼的時間。

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

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

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

• Kubernetes使用新映像啟動一個新容器。
• 等待健康檢查通過。
• 刪除舊的Pod。

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

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

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

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

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

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

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

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

.spec.strategy.type==RollingUpdate 

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

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

ReplicaSet.metadata.annotation 

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

kubectl get replicaset app-6ff88c4474 -o yaml 

查找修訂號。 這很復(fù)雜，因為除非您在YAML資源中留下注釋，否則發(fā)布歷史記錄不會保留日志(您可以使用— 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ù)十個，數(shù)百個甚至數(shù)千個部署同時進行更新時，很難一次跟蹤所有更新。 而且，如果您存儲的修訂全部包含相同的回歸，那么您的生產(chǎn)環(huán)境將不會處于良好狀態(tài)! 您可以在本文中詳細了解有關(guān)使用滾動更新的信息。

其他一些問題是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) 首先，房間整理：請閱讀細則

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

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

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

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

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

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

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

摘要

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

在本文中，我們研究了：

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

謝謝閱讀!