本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 命名空間：用例和見解

作者：Mike Altarace (Google Cloud Platform), Daz Wilkin (Google Cloud Platform) |

「誰在一壘，什麼在二壘，我不知道在三壘」 

誰在一壘？ 艾伯特與卡斯特羅主演

簡介

Kubernetes 是一個具有多個概念的系統。許多這些概念都體現在 RESTful API 中的「物件」（通常稱為「資源」或「種類」）。其中一個概念是命名空間。在 Kubernetes 中，命名空間是將單個 Kubernetes 叢集劃分為多個虛擬叢集的方式。在這篇文章中，我們將重點介紹我們的客戶如何使用命名空間的範例。 

但首先，打個比方：命名空間就像人類的姓氏。姓氏，例如 Wong，標識一個家庭單位。在 Wong 家庭中，其中一位成員，例如 Sam Wong，很容易被家庭成員簡稱為「Sam」。在家庭之外，為了避免「哪個 Sam？」的問題，Sam 通常會被稱為「Sam Wong」，甚至可能是「來自舊金山的 Sam Wong」。 

命名空間是一種邏輯劃分功能，使單個 Kubernetes 叢集可以被多個使用者、使用者團隊或具有多個應用程式的單個使用者使用，而無需擔心不希望有的互動。每個使用者、使用者團隊或應用程式都可以存在於其命名空間中，與叢集的其他每個使用者隔離，並且像叢集的唯一使用者一樣運作。（此外，資源配額提供了將 Kubernetes 叢集資源的子集分配給命名空間的能力。）

對於 Kubernetes 的所有但最不重要的用途，您都將受益於使用命名空間。在這篇文章中，我們將介紹我們在 Google Cloud Platform 上看到的 Kubernetes 使用者使用命名空間的最常見方式，但我們的列表並非詳盡無遺，我們很樂意從您那裡了解其他範例。

涵蓋的用例

  • 企業中命名空間的角色和職責
  • 劃分環境：開發 vs. 測試 vs. 生產
  • 非多租戶情境的客戶劃分
  • 何時不使用命名空間

用例 #1：企業中的角色和職責

典型的企業包含多個業務/技術實體，這些實體彼此獨立運作，並具有某種形式的企業本身管理的總體控制層。當定義了與 Kubernetes 相關的角色和職責時，在這種環境中有效運作 Kubernetes 叢集是可行的。 

以下是一些建議的角色及其職責，這些角色可以使在大型組織中管理 Kubernetes 叢集變得更容易。

  • 設計師/架構師角色：此角色將定義整體命名空間策略，考慮產品/位置/團隊/成本中心，並確定如何最好地將這些映射到 Kubernetes 命名空間。投資於這樣一個角色可以防止命名空間擴散和「雪花」命名空間。
  • 管理員角色：此角色具有對所有 Kubernetes 叢集的管理員存取權限。管理員可以建立/刪除叢集並新增/移除節點以擴展叢集。此角色將負責修補、保護和維護叢集。以及在組織中的不同實體之間實施配額。Kubernetes 管理員負責實施設計師/架構師定義的命名空間策略。 

這兩個角色和實際使用叢集的開發人員也將收到企業安全和網路團隊關於安全隔離要求以及命名空間如何適應此模型的支援和回饋，或關於網路子網路和負載平衡器設定的協助。

反模式

  1. 沒有集中控制的隔離 Kubernetes 使用「孤島」：如果沒有在建立圍繞 Kubernetes 管理的集中控制結構的初始投資，則存在最終形成「蘑菇農場」拓撲的風險，即組織內叢集的未定義大小/形狀/結構。結果是難以管理、風險更高且由於資源未充分利用而導致成本升高。
  2. 舊世界的 IT 控制扼殺使用和創新：常見的趨勢是嘗試將現有的地端控制/程序移植到新的動態框架上。這導致削弱了這些框架的敏捷性，並抵消了快速動態部署的好處。
  3. 全能叢集：延遲建立命名空間管理結構/機制的努力可能會導致一個大型全能叢集，該叢集難以剝離回較小的使用群組。 

用例 #2：使用命名空間劃分開發環境

軟體開發團隊通常將其開發管道劃分為離散單元。這些單元採用各種形式並使用各種標籤，但往往會產生離散的開發環境、測試|QA 環境、可能是預備環境，最後是生產環境。由此產生的佈局非常適合 Kubernetes 命名空間。管道中的每個環境或階段都成為唯一的命名空間。

上述方法運作良好，因為每個命名空間都可以模板化並鏡像到開發週期中的下一個後續環境，例如 dev->qa->prod。每個命名空間在邏輯上都是離散的事實允許開發團隊在隔離的「開發」命名空間內工作。DevOps（Google 最接近的角色稱為網站可靠性工程「SRE」） 將負責在管道中遷移程式碼，並確保將適當的團隊分配給每個環境。最終，DevOps 全權負責最終的生產環境，解決方案將交付給最終使用者。

將命名空間應用於開發週期的主要好處是，軟體組件（例如微服務/端點）的命名可以保持，而不會在不同環境中發生衝突。這是由於 Kubernetes 命名空間的隔離，例如，dev 中的 serviceX 在所有其他命名空間中都將被如此引用；但是，如果需要，可以使用其完整限定名稱 serviceX.development.mycluster.com 在 mycluster.com 的開發命名空間中唯一引用。

反模式

  1. 濫用命名空間的好處，導致開發管道中出現不必要的環境。因此；如果您不進行預備部署，請不要建立「預備」命名空間。
  2. 過度擁擠命名空間，例如將所有開發專案放在一個巨大的「開發」命名空間中。由於命名空間嘗試劃分，因此也使用這些命名空間按專案劃分。由於命名空間是扁平的，您可能希望類似於：projectA-dev、projectA-prod 作為 projectA 的命名空間。

用例 #3：劃分您的客戶

例如，如果您是一家諮詢公司，希望為您的每個客戶管理單獨的應用程式，則命名空間提供的劃分非常吻合。您可以為每個客戶、客戶專案或客戶業務部門建立單獨的命名空間，以保持這些命名空間的獨特性，同時無需擔心跨專案重用相同的資源名稱。

這裡一個重要的考慮因素是，Kubernetes 目前不提供跨命名空間強制執行存取控制的機制，因此我們建議您不要對外公開使用此方法開發的應用程式。

反模式

  1. 多租戶應用程式不需要 Kubernetes 命名空間的額外複雜性，因為應用程式已經在強制執行這種劃分。
  2. 客戶到命名空間的映射不一致。例如，您在全球企業贏得業務，您最初可能會考慮為企業建立一個命名空間，而沒有考慮到該客戶可能更喜歡進一步劃分，例如 BigCorp 會計和 BigCorp 工程。在這種情況下，客戶的部門可能各自需要一個命名空間。

何時不使用命名空間

在某些情況下，Kubernetes 命名空間將無法提供您需要的隔離。這可能是由於地理、計費或安全因素。對於命名空間邏輯劃分的所有好處，目前還沒有能力強制執行劃分。Kubernetes 叢集中的任何使用者或資源都可以存取叢集中的任何其他資源，而與命名空間無關。因此，如果您需要保護或隔離資源，最終的命名空間是一個單獨的 Kubernetes 叢集，您可以對其應用常規的安全|ACL 控制。

您可能考慮不使用命名空間的另一個時間是當您希望反映地理分佈式部署時。如果您希望部署靠近美國、歐盟和亞洲客戶，建議在每個區域本地部署 Kubernetes 叢集。

當需要細粒度的計費時，例如按成本中心或按客戶收費，建議將計費委託給您的基礎設施供應商。例如，在 Google Cloud Platform (GCP) 中，您可以使用單獨的 GCP 專案或計費帳戶，並將 Kubernetes 叢集部署到特定客戶的專案中。

在機密性或合規性要求客戶之間完全不透明的情況下，每個客戶/工作負載一個 Kubernetes 叢集將提供所需的隔離級別。再次強調，您應該將資源劃分委託給您的供應商。

正在進行的工作是提供 (a) Kubernetes 命名空間上的 ACL，以便能夠強制執行安全；(b) 提供 Kubernetes 叢集聯邦。這兩種機制都將解決在這些反模式中使用單獨 Kubernetes 叢集的原因。 

Kubernetes 命名空間的一個容易理解的反模式是版本控制。您不應使用命名空間作為消除 Kubernetes 資源版本歧義的方式。容器和容器登錄檔以及 Kubernetes Deployment 資源中都存在對版本控制的支援。多個版本應該共存，方法是利用 Kubernetes 容器模型，該模型還提供部署期間版本之間的自動遷移。此外，版本範圍命名空間將導致叢集內命名空間的大量擴散，使其難以管理。

Caveat Gubernator

您可能希望，但您無法建立命名空間的層次結構。命名空間不能彼此巢狀。例如，您不能建立 my-team.my-org 作為命名空間，但可以建立 team-org。

命名空間易於建立和使用，但也容易不經意地將程式碼部署到錯誤的命名空間中。良好的 DevOps 習慣表明盡可能記錄和自動化流程，這將有所幫助。避免使用錯誤命名空間的另一種方法是設定 kubectl 環境定義。 

如前所述，Kubernetes（目前）不提供跨命名空間強制執行安全性的機制。您應該僅在受信任的網域（例如內部使用）中使用命名空間，並且當您需要能夠保證 Kubernetes 叢集的使用者或其資源無法存取任何其他命名空間資源時，請勿使用命名空間。此增強的安全功能正在 Kubernetes 特殊興趣小組中討論，用於身份驗證和授權，請在 SIG-Auth 參與。