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

Kubernetes 名字空間：用例和見解

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

“誰在一壘，什麼在二壘，我不知道在三壘”

誰在一壘？由 Abbott 和 Costello 創作

引言

Kubernetes 是一個包含多個概念的系統。其中許多概念在 RESTful API 中表現為“物件”（通常稱為“資源”或“種類”）。其中一個概念是名稱空間。在 Kubernetes 中，名稱空間是將單個 Kubernetes 叢集劃分為多個虛擬叢集的方式。在本文中，我們將重點介紹客戶如何使用名稱空間的示例。

但首先，一個比喻：名稱空間就像人類的姓氏。一個姓氏，例如王，標識一個家庭單元。在王家內部，其中一個成員，例如王山，很容易被家人稱為“山”。在家庭之外，為了避免“哪個山？”的問題，山通常會被稱為“王山”，甚至可能是“來自舊金山的王山”。

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

除了最簡單的 Kubernetes 用法，您都將受益於使用名稱空間。在本文中，我們將介紹我們觀察到的 Google Cloud Platform (GCP) 使用者使用名稱空間的最常見方式，但我們的列表並非詳盡無遺，我們很樂意從您那裡瞭解其他示例。

涵蓋的用例

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

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

典型的企業包含多個業務/技術實體，它們相互獨立運作，並由企業自身管理某種形式的總體控制層。在這種環境中有效執行 Kubernetes 叢集，需要定義與 Kubernetes 相關的角色和職責。

以下是一些推薦的角色及其職責，它們可以使大型組織中管理 Kubernetes 叢集變得更容易。

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

這兩個角色和實際使用叢集的開發人員還將獲得企業安全和網路團隊的支援和反饋，解決諸如安全隔離要求以及名稱空間如何適應此模型，或協助設定網路子網和負載均衡器等問題。

反模式

  1. 沒有集中控制的孤立 Kubernetes 使用“孤島”：如果最初沒有投入建立圍繞 Kubernetes 管理的集中控制結構，則存在最終形成“蘑菇農場”拓撲的風險，即組織內部叢集沒有定義的規模/形狀/結構。結果是難以管理、風險更高且由於資源利用不足而導致成本升高。
  2. 舊式 IT 控制扼殺使用和創新：一種常見的傾向是嘗試將現有的本地控制/程式移植到新的動態框架上。這導致動態框架的敏捷性受到拖累，並抵消了快速動態部署的好處。
  3. 全能叢集：推遲建立名稱空間管理結構/機制的工作可能導致一個龐大的全能叢集，難以將其拆分為更小的使用組。

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

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

上述方法效果很好，因為每個名稱空間都可以模板化並映象到開發週期中的下一個後續環境，例如 dev->qa->prod。每個名稱空間邏輯上都是離散的，這使得開發團隊可以在隔離的“開發”名稱空間中工作。DevOps（谷歌最接近的角色稱為站點可靠性工程“SRE”）將負責透過管道遷移程式碼，並確保適當的團隊被分配到每個環境。最終，DevOps 全權負責最終的生產環境，解決方案將在此處交付給終端使用者。

將名稱空間應用於開發週期的主要好處是，可以在不同環境之間保持軟體元件（例如微服務/端點）的命名一致性，而不會發生衝突。這是由於 Kubernetes 名稱空間的隔離特性，例如，開發環境中的 serviceX 在所有其他名稱空間中也將被稱為 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 容器模型共存，該模型還提供了透過部署在版本之間自動遷移的功能。此外，版本範圍的名稱空間將導致叢集中名稱空間的大量擴散，從而使其難以管理。

免責宣告

您可能希望建立名稱空間層次結構，但實際上無法做到。名稱空間不能相互巢狀。例如，您不能建立 `my-team.my-org` 作為名稱空間，但可以有 `team-org`。

名稱空間易於建立和使用，但也很容易無意中將程式碼部署到錯誤的名稱空間。良好的 DevOps 實踐建議儘可能地記錄和自動化流程，這將有所幫助。避免使用錯誤名稱空間的另一種方法是設定 kubectl 上下文。

如前所述，Kubernetes（目前）不提供強制跨名稱空間安全的機制。您應該只在受信任的域內（例如內部使用）使用名稱空間，而當您需要確保 Kubernetes 叢集的使用者或其資源無法訪問任何其他名稱空間資源時，則不應使用名稱空間。Kubernetes 身份驗證和授權特別興趣小組正在討論這種增強的安全功能，請在 SIG-Auth 參與討論。