設(shè)計(jì)云原生應(yīng)用程序的15條基本原則

作者：進(jìn)擊云原生 2022-04-14 10:01:49

云計(jì)算

云原生 在本文中，我將介紹如何設(shè)計(jì)云原生應(yīng)用程序并將其部署在 Kubernetes 上的15條基本原則。

創(chuàng)新互聯(lián)專(zhuān)注于徽縣網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供徽縣營(yíng)銷(xiāo)型網(wǎng)站建設(shè)，徽縣網(wǎng)站制作、徽縣網(wǎng)頁(yè)設(shè)計(jì)、徽縣網(wǎng)站官網(wǎng)定制、成都微信小程序服務(wù)，打造徽縣網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供徽縣網(wǎng)站排名全網(wǎng)營(yíng)銷(xiāo)落地服務(wù)。

設(shè)計(jì)可擴(kuò)展的云原生應(yīng)用程序需要深思熟慮，即便擁有大量云來(lái)部署我們的應(yīng)用程序，目前仍有許多挑戰(zhàn)需要克服。以復(fù)雜而臭名昭著的分布式計(jì)算仍然是真實(shí)的。同時(shí)網(wǎng)絡(luò)的不穩(wěn)定也會(huì)導(dǎo)致速度變慢和意外錯(cuò)誤。因?yàn)樵圃鷳?yīng)用程序通常是微服務(wù)，因此必須專(zhuān)門(mén)設(shè)計(jì)和部署以克服這些挑戰(zhàn)。

在本文中，我將介紹如何設(shè)計(jì)云原生應(yīng)用程序并將其部署在 Kubernetes 上的15條基本原則。

原則1：?jiǎn)蝹€(gè) Pod 幾乎是不可用的

因?yàn)?Kubernetes 可以在必要時(shí)自行決定終止 Pod，所以你需要一個(gè)控制器來(lái)創(chuàng)建你的 Pod。除了一次性調(diào)試之外，盡量少使用單個(gè) Pod。

副本集也幾乎不是你想直接使用的東西。

相反，你應(yīng)該有一個(gè) Deployment 或 StatefulSet 創(chuàng)建 Pod。無(wú)論你是否打算運(yùn)行多個(gè)實(shí)例，這都適用。你希望實(shí)現(xiàn)自動(dòng)化的原因是 Kubernetes 不保證 Pod 的持續(xù)生命周期，所以需要同時(shí)運(yùn)行多個(gè)實(shí)例，以防萬(wàn)一其中的容器發(fā)生故障。

原則2：明確區(qū)分有狀態(tài)和無(wú)狀態(tài)組件

Kubernetes 定義了許多不同的資源和管理它們的控制器。每個(gè)都有自己的語(yǔ)義。我看到了關(guān)于 Deployment、StatefulSet 和 DaemonSet 是什么以及它們能做什么或不能做什么的困惑。用對(duì)了意味著你清楚地表達(dá)了你的意圖，Kubernetes 可以幫助你實(shí)現(xiàn)目標(biāo)。

如果使用得當(dāng)，Kubernetes 會(huì)強(qiáng)制你這樣做，但存在許多復(fù)雜的解決方案。簡(jiǎn)單的經(jīng)驗(yàn)法則是讓所有有狀態(tài)的東西都在 StatefulSet 中，而在 Deployments 中是無(wú)狀態(tài)的，因?yàn)檫@樣做是 Kubernetes 的方式。使用時(shí)還請(qǐng)仔細(xì)閱讀官方文檔。

原則3：將秘密與非秘密配置分開(kāi)，以明確使用以保證安全

ConfigMap 和 Secret 之間幾乎沒(méi)有技術(shù)差異 。既包括它們?cè)?Kubernetes 內(nèi)部的表示方式，也包括它們的使用方式。例如，應(yīng)用程序配置存儲(chǔ)在 ConfigMap 中，然后帶有憑據(jù)的數(shù)據(jù)庫(kù)連接字符串屬于Secret。

原則4：?jiǎn)⒂米詣?dòng)擴(kuò)容選項(xiàng)

就像所有 Pod 實(shí)際上都由 Deployment 管理并以 Service 為前端一樣，你還應(yīng)該始終考慮為你的 Deployment 使用Horizontal Pod Autoscaler (HPA)。

從來(lái)沒(méi)有人愿意在他們的服務(wù)在生產(chǎn)環(huán)境中耗盡容量。同樣，沒(méi)有人希望最終用戶因?yàn)?Pod 的容量分配不佳而受苦。從一開(kāi)始就為此做好準(zhǔn)備意味著你將被迫進(jìn)入縮放可以并且將會(huì)發(fā)生的心態(tài)。這比容量用完要好得多。

根據(jù)一般的可擴(kuò)展性設(shè)計(jì)原則，你應(yīng)該已經(jīng)準(zhǔn)備好運(yùn)行每個(gè)應(yīng)用程序組件的多個(gè)實(shí)例。這對(duì)于可用性和可擴(kuò)展性至關(guān)重要。

請(qǐng)注意，你也可以使用 HPA 自動(dòng)擴(kuò)展 StatefulSet。然而，有狀態(tài)的組件通常應(yīng)該只在絕對(duì)需要時(shí)才進(jìn)行擴(kuò)展。

例如，擴(kuò)展數(shù)據(jù)庫(kù)可能會(huì)導(dǎo)致大量數(shù)據(jù)復(fù)制和額外的事務(wù)管理發(fā)生，如果數(shù)據(jù)庫(kù)已經(jīng)處于高負(fù)載狀態(tài)，這會(huì)產(chǎn)生不可控制的問(wèn)題。此外，如果你確實(shí)自動(dòng)縮放有狀態(tài)組件，請(qǐng)考慮禁用自動(dòng)縮減。特別是，如果有狀態(tài)組件需要以某種方式與其他實(shí)例同步。相反，手動(dòng)觸發(fā)此類(lèi)操作更安全。

原則5：通過(guò)與容器生命周期管理掛鉤來(lái)增強(qiáng)和啟用自動(dòng)化

一個(gè)容器可以定義一個(gè) PostStart 和 PreStop 鉤子，這兩個(gè)鉤子都可以用來(lái)執(zhí)行重要的工作，以通知應(yīng)用程序的其他組件一個(gè)實(shí)例的新啟動(dòng)或其即將終止。PreStop 函數(shù)將在終止之前調(diào)用，并且有一個(gè)(可配置的)時(shí)間來(lái)完成。使用它來(lái)確保即將終止的實(shí)例完成其工作，將文件提交到持久卷，或者為了有序和自動(dòng)關(guān)閉而需要發(fā)生的任何其他事情。

原則6：正確使用探針來(lái)檢測(cè)故障并自動(dòng)從故障中恢復(fù)

與單進(jìn)程系統(tǒng)相比，分布式系統(tǒng)將以越來(lái)越不直觀的方式失敗。網(wǎng)絡(luò)是一大類(lèi)新的故障原因。我們?cè)侥軝z測(cè)到故障，我們就越有機(jī)會(huì)從故障中自動(dòng)恢復(fù)。

為此，Kubernetes 為我們提供了探測(cè)能力。特別是就緒探測(cè)非常有用，因?yàn)槭?huì)向 Kubernetes 發(fā)出信號(hào)，表明你的容器(以及 Pod)還沒(méi)有準(zhǔn)備好接受請(qǐng)求。

盡管有明確的文檔，但活性探針經(jīng)常被誤解。失敗的活性探測(cè)表明組件永久卡在需要強(qiáng)制重啟才能解決的不良情況。

啟動(dòng)探針被添加到 Kubernetes 以指示何時(shí)開(kāi)始使用其他探針進(jìn)行探測(cè)。因此，這是一種將它們推遲到執(zhí)行它們開(kāi)始有意義的方法。

原則7：讓有故障組件快速暴露出來(lái)

應(yīng)用程序組件發(fā)生嚴(yán)重故障(崩潰)、快速故障(一旦出現(xiàn)問(wèn)題)和大聲故障(在其日志中包含信息豐富的錯(cuò)誤消息)。這樣做可以防止數(shù)據(jù)在你的應(yīng)用程序中陷入奇怪的狀態(tài)，只會(huì)將流量路由到健康的實(shí)例，并且還會(huì)提供根本原因分析所需的所有信息。本文中的所有自動(dòng)化和其他原則將幫助你在找到根本原因的同時(shí)保持你的應(yīng)用程序處于良好狀態(tài)。

無(wú)論是在你的組件中，還是在集群本身中。失敗是不可避免的，應(yīng)用程序中的組件必須能夠自動(dòng)處理失敗或重啟。

原則8：保證可觀測(cè)性

監(jiān)控、日志記錄和鏈路跟蹤是可觀察性的三大支柱。只需將自定義指標(biāo)提供給你的監(jiān)控系統(tǒng)，編寫(xiě)結(jié)構(gòu)化日志(例如 JSON 格式)，而不是故意刪除 HTTP 標(biāo)頭(例如帶有相關(guān) ID 的標(biāo)頭)，而是將它們作為記錄內(nèi)容的一部分，將為你的應(yīng)用程序提供可觀察的所有內(nèi)容。

如果你需要更詳細(xì)的跟蹤信息，請(qǐng)將你的應(yīng)用程序與 Open Telemetry API 集成。但是前面的步驟使你的應(yīng)用程序易于觀察，無(wú)論是人工操作員還是自動(dòng)化?；趯?duì)你的應(yīng)用程序有意義的指標(biāo)進(jìn)行自動(dòng)縮放幾乎總是比基于 CPU 使用率等原始指標(biāo)更好。

SRE 的 “四個(gè)黃金信號(hào)” 是延遲、流量、錯(cuò)誤和飽和度。從經(jīng)驗(yàn)上看，使用特定于應(yīng)用程序的指標(biāo)跟蹤這些監(jiān)控信號(hào)比使用通用基礎(chǔ)資源獲得的原始指標(biāo)要有用得多。

原則9：適當(dāng)限制 Pod 資源請(qǐng)求

通過(guò)適當(dāng)?shù)卦O(shè)置Pod資源請(qǐng)求和限制，Horizontal Pod Autoscaler 和 Cluster Autoscaler 都可以做得更好。如果他們知道需要多少容量和可用容量，則確定你的 Pod 和整個(gè)集群需要多少容量的工作會(huì)容易的多。

不要將你的請(qǐng)求和限制設(shè)置得太低!一開(kāi)始這可能很誘人，因?yàn)樗试S集群運(yùn)行更多的 Pod。但除非請(qǐng)求和限制設(shè)置相同(為 Pod 提供 “有保證的” QoS 類(lèi))，否則你的 Pod 在正常(常規(guī)流量)操作期間可能會(huì)獲得更多資源?？雌饋?lái)一切都很好地工作。但在高峰期，它們的QPS將被限制在你指定的數(shù)量。而擴(kuò)大規(guī)模實(shí)際上意味著每個(gè)部署的 Pod 占用更多的資源，但是整體性能可能會(huì)更差。

原則10：預(yù)留容量并優(yōu)先考慮 Pod 優(yōu)先級(jí)

在容量管理方面，命名空間資源配額、節(jié)點(diǎn)上預(yù)留的計(jì)算資源以及適當(dāng)設(shè)置 Pod 優(yōu)先級(jí) 有助于確保集群容量和穩(wěn)定性不受影響。

避免集群負(fù)載過(guò)高，以至于網(wǎng)絡(luò)插件的 Pod 被驅(qū)逐。

原則11：根據(jù)需要強(qiáng)制合并或分散 Pod

Pod傳播約束以及親和性和反親和性規(guī)則可以做到將 Pod 放在一起(以提高網(wǎng)絡(luò)流量效率)或?qū)⑺鼈兎稚?以實(shí)現(xiàn)冗余)跨多云區(qū)域保證可用性的好方法。

原則12：在可能導(dǎo)致停機(jī)的計(jì)劃操作期間確保 Pod 可用性

Pod Disruption Budget 指定一次允許多少個(gè) Pod 集合(例如在 Deployment 中)被 自愿中斷(即由于你的命令，而不是故障)。盡管管理員標(biāo)記了部分不可用集群節(jié)點(diǎn)，這有助于確保高可用性。例如，在集群升級(jí)期間會(huì)發(fā)生這種情況，并且通常每月發(fā)生一次，因?yàn)?Kubernetes 更新速度很快。

請(qǐng)注意，如果你錯(cuò)誤地設(shè)置 Pod 中斷預(yù)算，你可能會(huì)限制管理員進(jìn)行集群升級(jí)的能力。這會(huì)干擾自動(dòng)操作系統(tǒng)修補(bǔ)并危及環(huán)境的安全狀況。

PDB 會(huì)限制因自愿中斷而同時(shí)停機(jī)的復(fù)制應(yīng)用程序的 Pod 數(shù)量。

原則13：選擇藍(lán)/綠或金絲雀部署而不是停機(jī)部署

在這個(gè)時(shí)代，為了升級(jí)維護(hù)而關(guān)閉整個(gè)應(yīng)用程序是不可接受的。這現(xiàn)在被稱(chēng)為“stop-the-world 部署”，其中應(yīng)用程序暫時(shí)無(wú)法訪問(wèn)。通過(guò)更復(fù)雜的部署策略，可以實(shí)現(xiàn)更平滑和更漸進(jìn)的變化。最終用戶根本不需要知道應(yīng)用程序已更改。

藍(lán)/綠 和 金絲雀 部署曾經(jīng)是一門(mén)黑色藝術(shù)，但 Kubernetes 讓所有人都可以更廉價(jià)的使用它。更快的推出組件的新版本。不過(guò)可能需要您在自己的腳本中或多或少地手動(dòng)實(shí)現(xiàn)它們，但是更多好的方式是選擇一些 CD 發(fā)布工具，以執(zhí)行高級(jí)部署策略，例如 ArgoCD(藍(lán)/綠或金絲雀)。

在技術(shù)層面上，大多數(shù)部署策略歸結(jié)為同時(shí)部署同一組件的兩個(gè)版本，并以不同的方式將請(qǐng)求拆分給它們。你可以通過(guò) Service 本身執(zhí)行此操作，例如，用適當(dāng)?shù)臉?biāo)簽標(biāo)記新版本的 5% 的 Pod，以使 Service 將流量路由到它們?；蛘呒磳⑼瞥龅?Kubernetes Gateway 將開(kāi)箱即用。

原則14：避免授予 Pod 不需要的權(quán)限

Kubernetes 本身并不安全，默認(rèn)情況下也不安全。但是您可以對(duì)其進(jìn)行配置以強(qiáng)制執(zhí)行安全最佳實(shí)踐，例如限制容器在節(jié)點(diǎn)上可以執(zhí)行的操作。

以非 root 用戶身份運(yùn)行您的容器。在 Docker 中構(gòu)建容器鏡像使得容器默認(rèn)以 root 身份運(yùn)行這一事實(shí)可能已經(jīng)為黑客帶來(lái)了近十年的樂(lè)土。僅在容器構(gòu)建過(guò)程中使用 root 來(lái)安裝依賴(lài)項(xiàng)，然后創(chuàng)建一個(gè)非 root 用戶并讓其運(yùn)行您的應(yīng)用程序。

如果你的應(yīng)用程序確實(shí)需要提升權(quán)限，那么仍然使用非 root 用戶，刪除所有 Linux 功能，并僅添加最少的功能集。

原則15：限制Pod在集群中可以做的事情

禁止將默認(rèn)服務(wù)帳戶暴露給您的應(yīng)用程序。除非您特別需要與 Kubernetes API 交互，否則不應(yīng)將默認(rèn)服務(wù)帳戶令牌安裝到其中。然而，默認(rèn)情況下，Kubernetes 是允許的。

設(shè)置并執(zhí)行最嚴(yán)格的 Pod 安全策略 ，以確保默認(rèn)情況下不會(huì)不必要地使不安全的操作模式成為可能。

使用網(wǎng)絡(luò)策略來(lái)限制你的 Pod 可以連接到的其他 Pod。Kubernetes 中暢通無(wú)阻的默認(rèn)網(wǎng)絡(luò)是一場(chǎng)安全噩夢(mèng)，因?yàn)檫@樣，攻擊者只需進(jìn)入一個(gè) Pod 即可直接訪問(wèn)所有其他 Pod。

Log4Shell 對(duì)具有鎖定網(wǎng)絡(luò)策略的容器完全無(wú)效，它會(huì)禁止所有出口流量，除了白名單上的流量(以及那個(gè)來(lái)自漏洞利用的 LDAP 服務(wù)不會(huì)生效)。

概括

本文介紹了如何設(shè)計(jì)云原生應(yīng)用程序并將其部署在 Kubernetes 上的 15 條原則。通過(guò)遵循這些原則，你的云原生應(yīng)用程序可以與 Kubernetes 工作負(fù)載編排器協(xié)同工作。這樣做可以讓你獲得 Kubernetes 平臺(tái)以及設(shè)計(jì)和操作軟件的云原生方式提供的所有好處。

你已經(jīng)學(xué)習(xí)了如何正確使用 Kubernetes 資源、為自動(dòng)化做準(zhǔn)備、如何處理故障、利用 Kubernetes 探測(cè)功能提高穩(wěn)定性、為應(yīng)用程序準(zhǔn)備可觀察性、使 Kubernetes 調(diào)度程序?yàn)槟ぷ?、使用高?jí)策略執(zhí)行部署，以及如何限制已部署應(yīng)用程序的攻擊面。

將這些方面融入到你的軟件架構(gòu)工作中，可以讓你的日常 DevOps 流程更加順暢和可靠。

當(dāng)前名稱(chēng)：設(shè)計(jì)云原生應(yīng)用程序的15條基本原則
轉(zhuǎn)載來(lái)于：http://fisionsoft.com.cn/article/dhghcsc.html