建設 Kubernetes 生產環境的 16條建議

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

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

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

六、使用註釋來跟蹤重要的系統更改等

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

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

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

讓你的集羣更加安全

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

七、使用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指南。

八、使用Pod安全策略防止危險行爲

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

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

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

九、使用網絡策略實施網絡控制/防火牆

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

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

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

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

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

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

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

十一、使用鏡像掃描識別和修復鏡像漏洞

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

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

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

保持集羣穩定

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

十二、遵循CI / CD方法

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

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

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

1三、使用Canary方法進行更新

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

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

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

1四、實施監控並將其與SIEM集成

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

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

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

深度建議

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

1五、使用服務網格管理服務間通訊

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

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

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

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

1六、使用准入控制器解鎖Kubernetes中的高級功能

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

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

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

來源：開源Linux