圖片來源：veer

本文作者

Steven Wong (VMware)

Michael Gasch (VMware)

文章翻譯

?Karen Lee

文章來源

K8S技術社區

原文鏈接

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

如需轉載，請聯系原作者授權

“生產級”是什么意思？

安裝是安全的
部署通過可重復和記錄的過程進行管理
性能可預測且一致

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

簡而言之，生產級意味著預測事故并以最小的痛苦和延遲為恢復做好準備。

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

01

Kubernetes集群中的關鍵組件

在深入了解細節之前，了解整體Kubernetes架構至關重要。
Kubernetes集群是基于控制平面和集群worker節點架構的高度分布式系統，如下所示。

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

02

從HA的角度看Kubernetes組件

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

03

etcd

etcd是所有Kubernetes對象的持久存儲。etcd集群的可用性和可恢復性應該是生產級Kubernetes部署中的首要考慮因素。
如果能負擔得起，五節點etcd集群是最佳實踐。為什么？因為你可以在一個上進行維護，但仍能容忍故障。即使只有一個虛擬機管理程序主機可用，三節點集群也是生產級服務的最低建議。除跨越多個可用區域的超大型安裝外，不建議使用超過七個節點。
托管etcd集群節點的最低建議是2GB RAM和8GB SSD支持的磁盤。通常，8GB RAM和20GB磁盤就足夠了。磁盤性能會影響節點恢復時間。有關詳細信息，請參閱https://coreos.com/etcd/docs/latest/op-guide/hardware.html。

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

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

04

單主機部署

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

單主機部署選項

05

雙主機部署

兩臺主機的情況下，etcd的存儲問題與單個主機相同，你需要冗余。你最好運行3個etcd實例。雖然可能有違直覺，但最好將所有etcd節點集中在一臺主機上。通過在兩臺主機上進行2 + 1拆分，無法獲得可靠性，因為丟失擁有多數etcd實例的節點會導致中斷（無論多數是2還是3）。如果主機不相同，請將整個etcd集群放在最可靠的主機上。
建議運行冗余API Server、kube-scheduler和kube-controller-manager。這些應該在主機之間拆分，以最大程度地降低由于容器運行時、操作系統和硬件故障帶來的風險。
在物理主機上運行虛擬機管理程序層將允許使用資源消耗治理來運維冗余軟件組件，并且可以具有計劃好的的維護運維優勢。

雙主機部署選項

三個（或更多）主機部署——進入不妥協的生產級服務，建議跨三臺主機拆分etcd。單個硬件故障將降低應用程序工作負載容量，但不應導致徹底的服務中斷。
對于非常大的集群，將需要更多的etcd實例。
運行虛擬機管理程序層可提供運維優勢和更好的工作負載隔離。這超出了本文的范圍，但在三個或更多主機級別，可以使用高級功能（集群冗余共享存儲、具有動態負載均衡的資源治理、具有實時遷移或故障轉移的自動化運行狀況監控）。

三個（或更多）主機選項

06

Kubernetes配置設置

應保護master節點和worker節點免受過載和資源耗盡的影響。管理程序功能可用于隔離關鍵組件和預留資源。還有Kubernetes配置設置可以限制API調用率和每個節點的pod等內容。某些安裝套件和商業發行版處理了此問題，但如果你正在執行自定義Kubernetes部署，可能會發現默認值不合適，尤其是在資源較少或集群較大的情況下。
控制平面的資源消耗將與pod的數量和pod流失率相關。非常大和非常小的集群將受益于kube-apiserver請求限制和內存的非默認設置。如果這些太高可能導致超出請求限制和內存不足的錯誤。
在worker節點上，應根據每個節點上合理的可支持工作負載密度配置Node Allocatable?？梢詣摻臻g以將worker節點集群細分為具有資源CPU和內存配額的多個虛擬集群?？梢耘渲觅Y源條件不足的kubelet處理。

07

安全

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

建議：

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

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

08

災難恢復和備份

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

signing、“Front proxy”、Front proxy client

????關鍵DNS記錄
????IP /子網分配和預留
????外部負載均衡器
????kubeconfig文件
????LDAP或其他身份驗證詳細信息
????云提供商特定的帳戶和配置數據

09

后續生產工作負載的注意事項

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

10

其他考慮

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

你的生產部署應該使用自動安裝、配置和更新工具（如Ansible、BOSH、Chef、Juju、kubeadm、Puppet等）。手動過程將具有可重復性問題、勞動密集、容易出錯且難以擴展。經過認證的發行版可能包含一個用于保留更新中配置設置的工具，但如果你自己安裝和配置工具鏈，則保留、備份和恢復配置工件至關重要?？紤]將部署組件和設置保存在Git等版本控制系統下。

11

故障恢復

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

12

最后的想法

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

完

投稿啦！！！

精彩繼續

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

文章題材

• 首先你需要關注我們的公眾號“CSDN云計算”，這樣你會更準確了解我們需要的文章風格；

• 側重于云計算領域相關的文章，可以是技術、運維、趨勢等方面的務實內容；

• 原創，要求文章有鮮明觀點和看法。

投稿須知

• ?稿費：根據原創性、實用性和時效性等方面進行審核，通過的文章會發布在本微信平臺。一經采用，我們將支付作者酬勞。酬勞可能不多，這代表的是一個心意，更多是因為愛好，是有識之士抒發胸懷的一種方式；

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

• 投稿郵箱：lijy@csdn.net?；蛘咛砑游⑿疟砻鱽硪?#xff0c;微信號：tangguoyemeng。請備注投稿+姓名+公司職位。

  
  

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

總結

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

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