構建生產就緒的K8S集羣的16點清單

Kubernetes是用於構建高度可擴展系統的強大工具。結果，許多公司已經開始或正在計劃使用它來協調生產服務。不幸的是，像大多數強大的技術同樣，Kubernetes也很複雜。咱們整理了如下清單，以幫助你生產環境最佳實踐Kubernetes。

容器最佳實踐

Kubernetes提供了一種編排容器化服務的方法，所以，若是您沒有按順序實踐你的容器，那麼集羣一開始就不會處於良好狀態。請按照如下提示開始。

1: 使用精簡基礎鏡像

what：容器是內置在系統鏡像中的應用程序堆棧。從業務邏輯到內核的全部內容都打包在一塊兒。最小的鏡像會佔用盡量多的OS，並迫使您顯式添加所需的任何組件。

why：僅在您的容器中包括要使用的軟件，同時具備性能和安全性方面的好處。磁盤上的字節數更少，複製鏡像的網絡流量更少，而且潛在的攻擊者沒法訪問的工具也更少。

how：Alpine Linux是一個流行的選擇，並具備普遍的支持。

2：使用提供最佳正常運行時間的註冊表

what：註冊表是鏡像的存儲庫，使這些鏡像可供下載和啓動。在指定部署配置時，您須要指定從何處獲取路徑爲<registry> / <remote name>：<tag>的鏡像：

why：您的集羣須要鏡像去運行。

how：大多數雲提供商都提供私有鏡像註冊表服務：Google提供Google容器註冊表，AWS提供Amazon ECR，Microsoft提供Azure容器註冊表。

仔細調研，並選擇提供最佳正常運行時間的私人註冊表。因爲您的羣集將依靠您的註冊表來啓動軟件的較新版本，所以任何停機時間都將阻止對正在運行的服務進行更新。

3：使用ImagePullSecrets對您的註冊表進行身份驗證

what：ImagePullSecrets是Kubernetes對象，可以讓您的羣集經過註冊表進行身份驗證，所以註冊表能夠選擇誰能夠下載鏡像。

why：若是您的註冊表足夠公開，可讓集羣從中提取鏡像，則代表註冊表足夠公開，須要身份驗證。

how：Kubernetes網站在配置ImagePullSecrets方面有很好的演練，該示例使用Docker做爲示例註冊表。

管理你的集羣

微服務本質上是一團糟。使用微服務的許多好處來自在服務級別上強制職責分離，有效地爲後端的各個組件建立了抽象。一些很好的例子是運行與業務邏輯分離的數據庫，運行軟件的單獨開發和生產版本，或分離出水平可伸縮的流程。

具備不一樣服務執行不一樣職責的陰暗面是，它們不能被平等對待。值得慶幸的是，Kubernetes爲您提供了許多解決此問題的工具。

4：使用命名空間隔離環境

what：命名空間是Kubernetes中最基本，最強大的分組機制。它們幾乎像虛擬集羣同樣工做。默認狀況下，Kubernetes中的大多數對象僅限於一次影響單個名稱空間。

why：大多數對象都是在命名空間範圍內定義的，所以您必須使用命名空間。鑑於它們提供了強大的隔離性，所以它們很是適合隔離具備不一樣目的的環境，例如用戶服務的生產環境和嚴格用於測試的環境，或者分離支持單個應用程序的不一樣服務堆棧，例如保持安全解決方案的工做負載與您本身的應用程序分開。一個好的經驗法則是按資源分配劃分名稱空間：若是兩組微服務將須要不一樣的資源池，請將它們放在單獨的名稱空間中。

how：它是大多數對象類型的元數據的一部分：

請注意，您應該始終建立本身的名稱空間，而不要依賴「默認」名稱空間。 Kubernetes的默認設置一般會爲開發人員優化以最小的摩擦，這一般意味着甚至放棄最基本的安全措施。

5：經過Labels 管理您的集羣

what：Labels是組織集羣的最基本且可擴展的方法。它們容許您建立用於分隔Kubernetes對象的任意key：value對。例如，您能夠建立一個標籤密鑰，將處理敏感信息的服務與不處理敏感信息的服務區分開。

why：如前所述，Kubernetes使用標籤進行組織，但更具體地說，它們用於選擇。這意味着，當您想給Kubernetes對象引用某個命名空間中的一組對象時（例如告訴網絡策略容許哪些服務相互通訊），請使用它們的標籤。因爲它們表明了這種開放式組織類型，所以請盡最大努力使事情簡單化，而且僅在須要選擇權的地方建立標籤。

how：標籤是一個簡單的規範字段，您能夠將其添加到YAML文件中：

6：使用註釋來跟蹤重要的系統更改等

what：註釋是能夠附加到pod的任意鍵值元數據，就像標籤同樣。可是，Kubernetes不會讀取或處理批註，所以圍繞您能夠和不能使用批註進行註釋的規則至關寬鬆，而且不能用於選擇。

why：它們可幫助您跟蹤容器化應用程序的某些重要功能，例如版本號或首次啓動的日期和時間。僅在Kubernetes的上下文中，註釋是一種無能爲力的構造，可是當用於跟蹤重要的系統更改時，註釋能夠成爲開發人員和運營團隊的資產。

how：註釋是相似於標籤的規格字段。

讓你的集羣更加安全

好了，您已經創建了集羣並按所需方式組織了-如今呢？好吧，接下來是要確保一些安全。您可能會花費一輩子的時間來學習，但仍未發現有人能夠侵入您系統的全部方式。博客文章的內容空間要比一輩子少得多，所以您必須知足一些強烈的建議。

7：使用RBAC實施訪問控制

what：RBAC（基於角色的訪問控制）使您能夠控制誰能夠查看或修改羣集的不一樣方面。

why：若是要遵循最小特權原則，則須要設置RBAC來限制羣集用戶和部署可以執行的操做。

how：若是要設置本身的集羣（即不使用託管的Kube服務），請確保使用''--authorization-mode = Node，RBAC「啓動您的kube apiserver。若是使用託管的Kubernetes例如，您能夠經過查詢用於啓動kube apiserver的命令來檢查它是否設置爲使用RBAC。惟一通用的檢查方法是在kubectl cluster-info dump的輸出中查找「 --authorization-mode ...」。

RBAC打開後，您須要更改默認權限以適合您的需求。 Kubernetes項目站點在此處提供了有關設置角色和RoleBindings的演練。託管的Kubernetes服務須要啓用RBAC的自定義步驟-請參閱Google的GKE指南或Amazon的AKS指南。

8: 使用Pod安全策略防止危險行爲

what：Pod安全策略是一種資源，很是相似於Deployment或Role，能夠經過kubectl以相同的方式建立和更新。每一個都有一個標誌集合，可用來防止集羣中特定的不安全行爲。

why：若是建立Kubernetes的人認爲限制這些行爲足夠重要，能夠建立一個特殊的對象來處理它，那麼它們很重要。

how：讓他們工做可能會使人沮喪。我建議啓動並運行RBAC，而後在此處查看Kubernetes項目的指南。在我看來，最重要的使用是防止特權容器和對主機文件系統的寫訪問，由於它們表明了容器抽象中一些較泄漏的部分。

9: 使用網絡策略實施網絡控制/防火牆

what：網絡策略是容許您明確聲明容許哪些流量的對象，而Kubernetes將阻止全部其餘不符合標準的流量。

why：限制羣集中的網絡流量是一項基本且重要的安全措施。默認狀況下，Kubernetes啓用全部服務之間的開放式通訊。保留此「默認開放」配置意味着與Internet鏈接的服務與存儲敏感信息的數據庫僅一步之遙。

how：有一篇文章寫的很好，具體詳情查看這裏。

10：使用Secrets來存儲和管理必要的敏感信息

what：Secrets是您如何在Kubernetes中存儲敏感數據，包括密碼，證書和令牌。

why：不管您是實施TLS仍是限制訪問，您的服務均可能須要相互認證，與其餘第三方服務或您的用戶進行認證。

how：Kubernetes項目在此處提供了指南。一個關鍵建議：避免將機密做爲環境變量加載，由於在您的環境中擁有機密數據一般是不安全的。相反，將機密裝入容器中的只讀卷中-您能夠在本 Use Secrets中找到一個示例。

11：使用鏡像掃描識別和修復鏡像漏洞

what：掃描儀檢查鏡像中安裝的組件。從操做系統到應用程序堆棧的全部內容。掃描程序對於找出鏡像所包含的軟件版本中存在哪些漏洞很是有用。

why：漏洞一直在流行的開源軟件包中發現。一些著名的例子是Heartbleed和Shellshock。您將想知道這些漏洞在系統中的什麼位置，以便您知道哪些鏡像可能須要更新。

how：掃描儀是基礎設施中至關常見的部分-大多數雲提供商都提供了產品。若是您想本身託管一些東西，那麼開源Clair項目是一個受歡迎的選擇。

保持您進羣穩定

Kubernetes表明很高的技術棧。您擁有在嵌入式內核上運行的應用程序，在VM中運行的應用程序（在某些狀況下甚至在裸機上），以及Kubernetes本身的服務共享硬件。考慮到全部這些因素，在物理和虛擬領域中不少事情都會出錯，所以儘量下降開發週期的風險很是重要。 Kubernetes周圍的生態系統已經開發了一系列最佳實踐，以使事情儘量保持一致。

12：遵循CI / CD方法

what：持續集成/持續部署是一種過程哲學。相信對代碼庫進行的每次修改都應增長增量值，並準備投入生產。所以，若是代碼庫中的某些內容發生了更改，則可能要啓動服務的新版本，以運行測試。

why：遵循CI / CD能夠幫助您的工程團隊在平常工做中牢記質量。若是出現問題，修復問題將成爲整個團隊的當務之急，由於此後依賴於已分解的提交的全部更改也將被分解。

how：因爲雲部署軟件的興起，CI / CD愈來愈流行。所以，您能夠從託管或自託管的衆多出色產品中進行選擇。若是您的團隊比較小，我建議您採用託管路線，由於節省的時間和精力絕對值得您付出額外的費用。

13：使用Canary方法進行更新

what：Canary是一種將服務更改從代碼庫中的提交帶給用戶的方法。您啓動了一個運行最新版本的新實例，而後將用戶緩慢遷移到新實例，從而逐漸得到了對更新的信心，而不是一次所有交換。

why：不管您的單元測試和集成測試有多普遍，它們都沒法徹底模擬生產中的運行-老是有可能某些功能沒法按預期運行。使用金絲雀能夠限制用戶接觸這些問題。

how：Kubernetes的可擴展性提供了許多途徑來逐步推出服務更新。最直接的方法是建立一個單獨的部署，與當前正在運行的實例共享一個負載平衡器。這個想法是您擴展新的部署，同時縮減舊的部署，直到全部正在運行的實例都是新版本。

14：實施監控並將其與SIEM集成

what：監視意味着跟蹤和記錄您的服務正在作什麼。

why：讓咱們面對現實吧-無論您的開發人員多麼出色，不管您的安全專家如何努力地發揮他們的聰明才智，事情都會出錯。當他們這樣作時，您將想知道發生了什麼，以確保您不會兩次犯相同的錯誤。

how：成功監視服務有兩個步驟-須要對代碼進行檢測，而且須要將該檢測的輸出饋送到某個地方以進行存儲，檢索和分析。執行檢測的方式在很大程度上取決於您的工具鏈，可是快速的網絡搜索應該可讓您有所做爲。就存儲輸出而言，除非您有專門知識或需求，不然我建議使用託管SIEM（例如Splunk或Sumo Logic）-根據個人經驗，DIY始終是與任何存儲相關的指望時間和精力的10倍。

深度建議

一旦集羣達到必定規模後，您將發現手動執行全部最佳作法將變得再也不可行，結果將給系統的安全性和穩定性帶來挑戰。超過此閾值後，請考慮如下主題：

15：使用服務網格管理服務間通訊

what：服務網格是管理服務間通訊的一種方法，能夠有效地建立在實施服務時使用的虛擬網絡。

why：使用服務網格能夠減輕管理羣集的一些較繁瑣的方面，例如確保對通訊進行正確的加密。

how：根據您對服務網格的選擇，啓動和運行的複雜性可能千差萬別。做爲最經常使用的服務網格，Istio彷佛正在蓬勃發展，而且您的配置過程將在很大程度上取決於您的工做負載。

一個警告：若是您須要採用一個服務網格，請儘早採用它而不是稍後採用它-逐漸改變集羣中的通訊樣式可能會很是痛苦。

16：使用准入控制器解鎖Kubernetes中的高級功能

what：准入控制器是一種很好的萬能工具，可用於管理集羣中發生的一切。它們容許您設置Kubernetes在啓動時將參考的Webhook。它們有兩種形式：變異和驗證。突變准入控制器會在部署啓動以前更改其配置。驗證准入控制器會與您的webhook一致，以容許啓動給定的部署。

why：它們的用例普遍且數量衆多–它們提供了一種經過自行開發的邏輯和限制來迭代地提升集羣穩定性的好方法。

how：查看有關如何開始使用Admission Controllers的指南。