圖片來源：veer

本文作者

Steven Wong (VMware)

Michael Gasch (VMware)

文章翻譯

?Karen Lee

文章來源

K8S技術(shù)社區(qū)

原文鏈接

https://kubernetes.io/blog/2018/08/03/out-of-the-clouds-onto-the-ground-how-to-make-kubernetes-production-grade-anywhere

如需轉(zhuǎn)載，請聯(lián)系原作者授權(quán)

“生產(chǎn)級”是什么意思？

安裝是安全的
部署通過可重復(fù)和記錄的過程進(jìn)行管理
性能可預(yù)測且一致

可以安全地更新和更改配置
有日志和監(jiān)控用來檢測和診斷故障和資源短缺
考慮到可用資源(包括對資金、物理空間、電力等的限制），服務(wù)“足夠高可用”。
恢復(fù)過程可用、有記錄和經(jīng)過測試，以便在發(fā)生故障時使用

簡而言之，生產(chǎn)級意味著預(yù)測事故并以最小的痛苦和延遲為恢復(fù)做好準(zhǔn)備。

本文針對虛擬機(jī)管理程序或裸機(jī)平臺上的內(nèi)部Kubernetes部署——與主要公有云的可擴(kuò)展性相比，面臨有限的支持資源。但是，如果預(yù)算約束限制了可使用的資源，其中一些建議在公有云中也可能有用。
單節(jié)點(diǎn)裸機(jī)Minikube部署可能既便宜又容易，但不是生產(chǎn)級。相反，你不太可能在零售店、分支機(jī)構(gòu)或邊緣地點(diǎn)獲得Google的Borg體驗(yàn)，當(dāng)然也不太可能需要。
即使在處理某些資源限制時，本文也提供了有關(guān)實(shí)現(xiàn)有價值的Kubernetes部署的一些指南。

01

Kubernetes集群中的關(guān)鍵組件

在深入了解細(xì)節(jié)之前，了解整體Kubernetes架構(gòu)至關(guān)重要。
Kubernetes集群是基于控制平面和集群worker節(jié)點(diǎn)架構(gòu)的高度分布式系統(tǒng)，如下所示。

通常，API服務(wù)器、Controller Manager和Scheduler組件共同位于控制平面（也稱為Master）節(jié)點(diǎn)的多個實(shí)例中。Master節(jié)點(diǎn)通常也包括etcd，盡管有高可用性和大型集群場景要求在獨(dú)立主機(jī)上運(yùn)行etcd。組件可以作為容器運(yùn)行，并且可選為由Kubernetes監(jiān)督，即作為靜態(tài)容器運(yùn)行。
為了實(shí)現(xiàn)高可用性，使用了這些組件的冗余實(shí)例。冗余的重要性和要求程度各不相同。

02

從HA的角度看Kubernetes組件

這些組件面臨的風(fēng)險包括硬件故障、軟件錯誤、錯誤更新、人為錯誤、網(wǎng)絡(luò)中斷以及導(dǎo)致資源耗盡的過載系統(tǒng)。冗余可以減輕許多這些危害的影響。此外，管理程序平臺的資源調(diào)度和高可用性功能可以超越使用Linux操作系統(tǒng)、Kubernetes和單獨(dú)的容器運(yùn)行時可以實(shí)現(xiàn)的功能。
API Server使用負(fù)載均衡器之后的多個實(shí)例來實(shí)現(xiàn)擴(kuò)展和可用性。負(fù)載均衡器是實(shí)現(xiàn)高可用性的關(guān)鍵組件。如果你沒有負(fù)載均衡器，則可能有多個DNS API Server “A”記錄。
kube-scheduler和kube-controller-manager參與leader選舉過程，而不是使用負(fù)載均衡器。由于cloud-controller-manager用于選定的托管基礎(chǔ)設(shè)施類型，并且這些具有實(shí)施變化，因此除了指示它們是控制平面組件之外，不做更多討論。
在Kubernetes worker節(jié)點(diǎn)上運(yùn)行的pod由kubelet代理管理。每個worker實(shí)例都運(yùn)行kubelet代理和CRI兼容的容器運(yùn)行時。Kubernetes本身旨在監(jiān)控和恢復(fù)worker節(jié)點(diǎn)中斷。但對于關(guān)鍵工作負(fù)載，可以使用虛擬機(jī)管理程序資源管理、工作負(fù)載隔離和可用性功能來增強(qiáng)可用性并使性能更具可預(yù)測性。

03

etcd

etcd是所有Kubernetes對象的持久存儲。etcd集群的可用性和可恢復(fù)性應(yīng)該是生產(chǎn)級Kubernetes部署中的首要考慮因素。
如果能負(fù)擔(dān)得起，五節(jié)點(diǎn)etcd集群是最佳實(shí)踐。為什么？因?yàn)槟憧梢栽谝粋€上進(jìn)行維護(hù)，但仍能容忍故障。即使只有一個虛擬機(jī)管理程序主機(jī)可用，三節(jié)點(diǎn)集群也是生產(chǎn)級服務(wù)的最低建議。除跨越多個可用區(qū)域的超大型安裝外，不建議使用超過七個節(jié)點(diǎn)。
托管etcd集群節(jié)點(diǎn)的最低建議是2GB RAM和8GB SSD支持的磁盤。通常，8GB RAM和20GB磁盤就足夠了。磁盤性能會影響節(jié)點(diǎn)恢復(fù)時間。有關(guān)詳細(xì)信息，請參閱https://coreos.com/etcd/docs/latest/op-guide/hardware.html。

在特殊情況下考慮多個etcd集群

對于非常大的Kubernetes集群，請考慮為Kubernetes事件使用單獨(dú)的etcd集群，以便事件風(fēng)暴不會影響主要的Kubernetes API服務(wù)。如果你使用flannel網(wǎng)絡(luò)，它會在etcd中保留配置，并且可能有不同的版本要求（而不是Kubernetes），這可能使etcd備份復(fù)雜化——考慮為flannel使用專用的etcd集群。

04

單主機(jī)部署

可用性風(fēng)險包括硬件、軟件和人員。如果你只有一臺主機(jī)，那么使用冗余存儲、糾錯內(nèi)存和雙電源可以減少硬件故障。在物理主機(jī)上運(yùn)行虛擬機(jī)管理程序?qū)⒃试S冗余軟件組件的運(yùn)維，并增加與部署、升級和資源消耗治理相關(guān)的運(yùn)維優(yōu)勢，還在壓力下具有可預(yù)測且可重復(fù)的性能。例如，即使你只能負(fù)擔(dān)運(yùn)行主服務(wù)的單例，也需要在與應(yīng)用程序工作負(fù)載競爭時保護(hù)它們免受過載和資源耗盡的影響。與配置Linux調(diào)度器優(yōu)先級、cgroup、Kubernetes標(biāo)志等相比，虛擬機(jī)管理程序可以更有效，更易于管理。
如果主機(jī)上的資源允許，可以部署三個etcd VM。每個etcd VM應(yīng)由不同的物理存儲設(shè)備支持，或者它們應(yīng)使用冗余（鏡像、RAID等）來使用后備存儲的單獨(dú)分區(qū)。
如果你的單個主機(jī)有資源，則API服務(wù)器、調(diào)度器和控制器管理器的雙冗余實(shí)例將是下一個升級。

單主機(jī)部署選項

05

雙主機(jī)部署

兩臺主機(jī)的情況下，etcd的存儲問題與單個主機(jī)相同，你需要冗余。你最好運(yùn)行3個etcd實(shí)例。雖然可能有違直覺，但最好將所有etcd節(jié)點(diǎn)集中在一臺主機(jī)上。通過在兩臺主機(jī)上進(jìn)行2 + 1拆分，無法獲得可靠性，因?yàn)閬G失擁有多數(shù)etcd實(shí)例的節(jié)點(diǎn)會導(dǎo)致中斷（無論多數(shù)是2還是3）。如果主機(jī)不相同，請將整個etcd集群放在最可靠的主機(jī)上。
建議運(yùn)行冗余API Server、kube-scheduler和kube-controller-manager。這些應(yīng)該在主機(jī)之間拆分，以最大程度地降低由于容器運(yùn)行時、操作系統(tǒng)和硬件故障帶來的風(fēng)險。
在物理主機(jī)上運(yùn)行虛擬機(jī)管理程序?qū)訉⒃试S使用資源消耗治理來運(yùn)維冗余軟件組件，并且可以具有計劃好的的維護(hù)運(yùn)維優(yōu)勢。

雙主機(jī)部署選項

三個（或更多）主機(jī)部署——進(jìn)入不妥協(xié)的生產(chǎn)級服務(wù)，建議跨三臺主機(jī)拆分etcd。單個硬件故障將降低應(yīng)用程序工作負(fù)載容量，但不應(yīng)導(dǎo)致徹底的服務(wù)中斷。
對于非常大的集群，將需要更多的etcd實(shí)例。
運(yùn)行虛擬機(jī)管理程序?qū)涌商峁┻\(yùn)維優(yōu)勢和更好的工作負(fù)載隔離。這超出了本文的范圍，但在三個或更多主機(jī)級別，可以使用高級功能（集群冗余共享存儲、具有動態(tài)負(fù)載均衡的資源治理、具有實(shí)時遷移或故障轉(zhuǎn)移的自動化運(yùn)行狀況監(jiān)控）。

三個（或更多）主機(jī)選項

06

Kubernetes配置設(shè)置

應(yīng)保護(hù)master節(jié)點(diǎn)和worker節(jié)點(diǎn)免受過載和資源耗盡的影響。管理程序功能可用于隔離關(guān)鍵組件和預(yù)留資源。還有Kubernetes配置設(shè)置可以限制API調(diào)用率和每個節(jié)點(diǎn)的pod等內(nèi)容。某些安裝套件和商業(yè)發(fā)行版處理了此問題，但如果你正在執(zhí)行自定義Kubernetes部署，可能會發(fā)現(xiàn)默認(rèn)值不合適，尤其是在資源較少或集群較大的情況下。
控制平面的資源消耗將與pod的數(shù)量和pod流失率相關(guān)。非常大和非常小的集群將受益于kube-apiserver請求限制和內(nèi)存的非默認(rèn)設(shè)置。如果這些太高可能導(dǎo)致超出請求限制和內(nèi)存不足的錯誤。
在worker節(jié)點(diǎn)上，應(yīng)根據(jù)每個節(jié)點(diǎn)上合理的可支持工作負(fù)載密度配置Node Allocatable。可以創(chuàng)建命名空間以將worker節(jié)點(diǎn)集群細(xì)分為具有資源CPU和內(nèi)存配額的多個虛擬集群。可以配置資源條件不足的kubelet處理。

07

安全

每個Kubernetes集群都有一個集群根Certificate Authority（CA）。需要生成并安裝Controller Manager、API Server、Scheduler、kubelet客戶端，kube-proxy和管理員證書。如果你使用安裝工具或發(fā)行版，可能不需要自己動手。下面描述了手動過程。你應(yīng)準(zhǔn)備好在節(jié)點(diǎn)替換或擴(kuò)展時重新安裝證書。
由于Kubernetes完全由API驅(qū)動，因此控制和限制誰可以訪問集群以及允許他們執(zhí)行哪些操作至關(guān)重要。此文檔（https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/）介紹了加密和身份驗(yàn)證選項。
Kubernetes應(yīng)用程序工作負(fù)載基于容器鏡像。你希望這些鏡像的來源和內(nèi)容值得信賴。這幾乎總是意味著你得有本地容器鏡像存儲庫。從公共互聯(lián)網(wǎng)中提取鏡像可能會帶來可靠性和安全性問題。你應(yīng)該選擇一個支持鏡像簽名、安全掃描、推送和拉取鏡像的訪問控制以及活動記錄的存儲庫。
必須有流程來支持應(yīng)用主機(jī)固件、虛擬機(jī)管理程序、操作系統(tǒng)、Kubernetes和其他依賴項的更新。應(yīng)該進(jìn)行版本監(jiān)控以支持審核。

建議：

加強(qiáng)控制平面組件上的安全設(shè)置（例如，鎖定worker節(jié)點(diǎn)）
利用Pod Security Policies
考慮網(wǎng)絡(luò)解決方案可用的NetworkPolicy集成，包括如何完成跟蹤、監(jiān)控和故障排除。
使用RBAC來推動授權(quán)決策和執(zhí)行。
考慮物理安全性，尤其是在部署到可能無人值守的邊緣或遠(yuǎn)程辦公室位置時。包括存儲加密，以限制被盜設(shè)備的暴露，并防止附加USB密鑰等惡意設(shè)備。
保護(hù)Kubernetes純文本云提供商憑證（訪問密鑰、令牌、密碼等）。

Kubernetes秘密對象適用于保存少量敏感數(shù)據(jù)。這些都保留在etcd中。這些可以很容易地用于保存Kubernetes API的憑據(jù)，但有時工作負(fù)載或集群的擴(kuò)展本身需要功能更全的解決方案。如果你需要的內(nèi)容多于內(nèi)置的秘密對象，HashiCorp Vault項目是一種流行的解決方案。

08

災(zāi)難恢復(fù)和備份

通過使用多個主機(jī)和VM來利用冗余有助于減少某些類別的中斷，但是諸如全站點(diǎn)自然災(zāi)害、不良更新、被黑客入侵、軟件錯誤或人為錯誤等情況仍可能導(dǎo)致中斷。
生產(chǎn)部署的一個關(guān)鍵部分是做好恢復(fù)的準(zhǔn)備。
值得注意的是，如果你需要在多個站點(diǎn)進(jìn)行大規(guī)模復(fù)制部署，那么你在設(shè)計、記錄和自動化恢復(fù)過程方面的一些投資可能是可重用的。
災(zāi)難恢復(fù)計劃的要素包括備份（可能是復(fù)制）、替換、計劃好的流程、可以執(zhí)行流程的人員以及反復(fù)的培訓(xùn)。定期的測試練習(xí)和混沌工程原理可用于審核準(zhǔn)備情況。
你的可用性要求可能要求你保留操作系統(tǒng)、Kubernetes組件和容器鏡像的本地副本，以便即使在因特網(wǎng)中斷期間也可以進(jìn)行恢復(fù)。在“air-gapped”場景中部署替換主機(jī)和節(jié)點(diǎn)的能力還可以提供安全性和部署速度優(yōu)勢。
所有Kubernetes對象都存儲在etcd上。定期備份etcd集群數(shù)據(jù)對于在災(zāi)難情況下（例如丟失所有主節(jié)點(diǎn)）恢復(fù)Kubernetes集群非常重要。
備份etcd集群可以使用etcd的內(nèi)置快照機(jī)制完成，并將生成的文件復(fù)制到不同故障域中的存儲中。快照文件包含所有Kubernetes狀態(tài)和關(guān)鍵信息。為了保證敏感Kubernetes數(shù)據(jù)的安全，請加密快照文件。
使用基于磁盤卷的etcd快照恢復(fù)可能會出現(xiàn)問題（見＃40027）。基于API的備份解決方案（如Ark）可以提供比etcd快照更細(xì)粒度的恢復(fù)，但更慢。你可以同時使用基于快照和基于API的備份，但至少應(yīng)該使用一種形式的etcd備份。
請注意，某些Kubernetes擴(kuò)展可能會在獨(dú)立的etcd集群中、持久卷上或通過其他機(jī)制維持狀態(tài)。如果此狀態(tài)至關(guān)重要，則應(yīng)該有備份和恢復(fù)計劃。
一些關(guān)鍵狀態(tài)存在于etcd之外。可以通過自動安裝/更新工具管理證書、容器鏡像以及其他與配置和運(yùn)維相關(guān)的狀態(tài)。即使可以重新生成這些項目，備份或復(fù)制也可以使故障發(fā)生后的恢復(fù)更快。考慮對以下項目進(jìn)行備份：
證書和密鑰對：CA、API Server、Apiserver-kubelet-client、ServiceAccount

signing、“Front proxy”、Front proxy client

????關(guān)鍵DNS記錄
????IP /子網(wǎng)分配和預(yù)留
????外部負(fù)載均衡器
????kubeconfig文件
????LDAP或其他身份驗(yàn)證詳細(xì)信息
????云提供商特定的帳戶和配置數(shù)據(jù)

09

后續(xù)生產(chǎn)工作負(fù)載的注意事項

Anti-affinity規(guī)范可用于跨備份主機(jī)拆分集群服務(wù)，但此時僅在調(diào)度pod時才使用這些設(shè)置。這意味著Kubernetes可以重新啟動集群應(yīng)用程序的故障節(jié)點(diǎn)，但在故障恢復(fù)后沒有本機(jī)機(jī)制來重新均衡。這是一個值得單獨(dú)寫篇文章的主題，但補(bǔ)充邏輯可能有助于在主機(jī)或工作節(jié)點(diǎn)恢復(fù)或擴(kuò)展后實(shí)現(xiàn)最佳工作負(fù)載放置。?Pod Priority and Preemption功能可用于在由故障或突發(fā)工作負(fù)載導(dǎo)致資源短缺的情況下指定首選分類。
對于有狀態(tài)服務(wù)，外部掛載卷安裝是非集群服務(wù)（例如，典型SQL數(shù)據(jù)庫）的標(biāo)準(zhǔn)Kubernetes建議。此時，由Kubernetes管理的這些外部卷的快照屬于路線圖功能請求的類別，可能與Container Storage Interface（CSI）集成一致。因此，執(zhí)行此類服務(wù)的備份將涉及特定于應(yīng)用程序的pod內(nèi)活動（這超出了本文范圍）。在等待更好的對快照和備份工作流的Kubernetes支持的同時，你可以在VM而不是容器中運(yùn)行數(shù)據(jù)庫服務(wù)，并將其暴露給你的Kubernetes工作負(fù)載。
如果資源允許，集群分布式有狀態(tài)服務(wù)（如Cassandra）可以通過使用本地持久卷來跨主機(jī)分割而受益。這將需要部署多個Kubernetes worker節(jié)點(diǎn)（可能是虛擬機(jī)管理程序主機(jī)上的VM）以在單點(diǎn)故障下保留仲裁。

10

其他考慮

日志和指標(biāo)（如果收集并持續(xù)保留）對診斷中斷很有價值，但鑒于可用的技術(shù)種類繁多，本文不會討論這個話題。如果因特網(wǎng)連接可用，則可能需要在中心位置外部保留日志和指標(biāo)。

你的生產(chǎn)部署應(yīng)該使用自動安裝、配置和更新工具（如Ansible、BOSH、Chef、Juju、kubeadm、Puppet等）。手動過程將具有可重復(fù)性問題、勞動密集、容易出錯且難以擴(kuò)展。經(jīng)過認(rèn)證的發(fā)行版可能包含一個用于保留更新中配置設(shè)置的工具，但如果你自己安裝和配置工具鏈，則保留、備份和恢復(fù)配置工件至關(guān)重要。考慮將部署組件和設(shè)置保存在Git等版本控制系統(tǒng)下。

11

故障恢復(fù)

記錄恢復(fù)過程的Runbook應(yīng)該進(jìn)行測試并保持離線狀態(tài)，甚至可能打印出來。當(dāng)一名待命工作人員在星期五晚上凌晨2點(diǎn)被召喚時，可能不是即興發(fā)揮的好時機(jī)。最好從預(yù)先計劃好的、經(jīng)過測試的清單中執(zhí)行——由遠(yuǎn)程和現(xiàn)場人員共享訪問。

12

最后的想法

在商業(yè)航空公司購買機(jī)票既方便又安全。但是當(dāng)你前往一個跑道很短的偏遠(yuǎn)地區(qū)時，沒有商用空客A320飛機(jī)可選。這并不意味著沒法飛了，而是意味著必須做出一些妥協(xié)。
航空業(yè)的格言是，在單引擎飛機(jī)上，引擎故障意味著墜機(jī)。使用雙引擎，至少可以讓你在哪里墜機(jī)有更多選擇。少數(shù)主機(jī)上的Kubernetes是相似的，如果你的商業(yè)用例證明了這一點(diǎn)，你可能會擴(kuò)展到更大的混合大型和小型車輛的車隊（如FedEx、亞馬遜）。
那些設(shè)計生產(chǎn)級Kubernetes解決方案的人有很多選擇和決定。本文無法提供所有答案，也無法了解你的具體優(yōu)先事項。我們希望提供一個需要考慮的事項清單，以及一些有用的指導(dǎo)。一些選項被忽略了（如運(yùn)行使用自托管而不是靜態(tài)pod的Kubernetes組件）。如果有興趣，我們可以在后續(xù)跟進(jìn)中涵蓋這些內(nèi)容。此外，Kubernetes的更新很快，如果你在2019年之后發(fā)現(xiàn)這篇文章，某些內(nèi)容可能會過時。

完

投稿啦！！！

精彩繼續(xù)

CSDN作為國內(nèi)專業(yè)的云計算服務(wù)平臺，目前提供云計算、大數(shù)據(jù)、虛擬化、數(shù)據(jù)中心、OpenStack、CloudStack、機(jī)器學(xué)習(xí)、智能算法等相關(guān)云計算觀點(diǎn)、技術(shù)、平臺、實(shí)踐、云產(chǎn)業(yè)咨詢等服務(wù)。CSDN?公眾號也一直堅持「與千萬技術(shù)人共成長」的理念，深度解讀行業(yè)內(nèi)熱門技術(shù)與場景應(yīng)用，致力于讓所有開發(fā)者保持敏銳的技術(shù)嗅覺、對行業(yè)趨勢與技術(shù)獲得更廣闊的認(rèn)知。

文章題材

• 首先你需要關(guān)注我們的公眾號“CSDN云計算”，這樣你會更準(zhǔn)確了解我們需要的文章風(fēng)格；

• 側(cè)重于云計算領(lǐng)域相關(guān)的文章，可以是技術(shù)、運(yùn)維、趨勢等方面的務(wù)實(shí)內(nèi)容；

• 原創(chuàng)，要求文章有鮮明觀點(diǎn)和看法。

投稿須知

• ?稿費(fèi)：根據(jù)原創(chuàng)性、實(shí)用性和時效性等方面進(jìn)行審核，通過的文章會發(fā)布在本微信平臺。一經(jīng)采用，我們將支付作者酬勞。酬勞可能不多，這代表的是一個心意，更多是因?yàn)閻酆?#xff0c;是有識之士抒發(fā)胸懷的一種方式；

• 字?jǐn)?shù)要求：稿件字?jǐn)?shù)以2K-8K為宜，少于2K或多于8K都會一定程度降低閱讀愉悅感；

• 投稿郵箱：lijy@csdn.net。或者添加微信表明來意，微信號：tangguoyemeng。請備注投稿+姓名+公司職位。

  
  

如果咱們的合作穩(wěn)定又愉快，還可以簽訂合同長期合作哦！

總結(jié)

以上是生活随笔為你收集整理的如何让Kubernetes集群生产可用？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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