摘要：客戶到命名空間的映射方式不統(tǒng)一。命名空間形成的邏輯分區(qū)有很多優(yōu)勢，但是目前還沒有能力保證利用分區(qū)的優(yōu)勢。你不應該使用命名空間區(qū)分集群資源的版本。如前所述，目前不提供命名空間級別的安全機制。

Kubernetes 中有不少概念，這些概念在 RESTful API 中表現(xiàn)為對象 (“resource” 或 “kinds”)。

其中一個比較重要的概念是 namespace (命名空間)。 Kubernetes中，命名空間將單個集群分拆成多個虛擬的集群。本文的主題是命名空間的應用場景。

首先我們舉個生活中的例子，做一個類比：命名空間就像家族的姓氏。比如一個家族的姓是”張”，有個家族成員叫”張三”，那么在這個家族中，大家說 “三”，我們可以唯一地確定是 “張三”。但是在家族外，如果要唯一確定這個人，則必須帶上姓: “張三”，或者更準確一點 “趙家莊的張三”。

命名空間定義了一個邏輯分區(qū)，實現(xiàn)了一定程度上的隔離，它使得單個集群可以由多個用戶(組) 使用，或者擁有多個應用的單個用戶使用，而不用關心不同的應用會互相影響。

每個用戶、用戶組或應用都能夠與其它用戶和操作隔離開，仿佛這個集群只有這一個用戶一樣。此外，通過Resource Quota，我們能夠把Kubernetes集群資源的一個子集分配給某個特定的命名空間。

對于大多數(shù)應用場景，命名空間都非常受用。在這篇文章中，我們將涵蓋谷歌云平臺上Kubernetes用戶對命名空間的常見使用方式，具體體現(xiàn)在下面幾個方面：

命名空間在企業(yè)中的角色和責任

分區(qū)：dev vs. test vs.prod

非多租戶場景下的客戶分區(qū)

什么時候不使用命名空間

一個典型的企業(yè)包含多個業(yè)務/技術實體，這些實體的操作相互獨立，但又都在企業(yè)的管控之下。只要Kubernetes 相關的角色和職責被定義好，在這樣一個環(huán)境下管理 Kubernetes 集群并不難。

下面是一些關于角色和職責的建議，有了他們，在大型組織中管理 Kubernetes集群將會更簡單：

設計師/架構師角色 ：該角色定義了整體的命名空間策略，需要考慮到產(chǎn)品/定位/團隊/成本中心這些因素，并確定如何把這些因素映射到 Kubernetes 命名空間。設計這樣一個角色能防止命名空間膨脹和碎片化。

管理員角色 ：該角色管理所有kubernetes集群的訪問：創(chuàng)建/刪除集群、添加/遷移節(jié)點來伸縮集群。除此之外，該角色還負責集群的更新、安全和維護，以及組織中不同實體間的配額實現(xiàn)。kubernetes管理員負責實施由設計師/架構師定義的命名空間策略。

這兩個角色以及實際開發(fā)者使用集群的過程中也會收到企業(yè)安全和網(wǎng)絡團隊對問題的支持和反饋。常見的問題有：安全隔離要求，命名空間如何適應這種模型，或協(xié)助網(wǎng)絡子網(wǎng)和負載均衡器設置。

使用命名空間進行隔離，但是沒有中心化的控制 ：初期沒有圍繞kubernetes管理建立一套中心化的控制結構，有很大的風險建立起用“蘑菇農(nóng)場”的拓撲結構：即沒有統(tǒng)一的尺寸/形狀/結構。 結果就是難以管理、高風險和由于資源利用不足導致的高成本。

舊的 IT 控制妨礙了正常使用和創(chuàng)新 ：一個常見的趨勢是嘗試將現(xiàn)有的內(nèi)部控制機制和流程應用到新的、動態(tài)的框架。這樣會降低新框架的敏捷性，也抹殺了快速動態(tài)部署的優(yōu)點。

大雜燴集群 ：延遲為命名空間創(chuàng)建管理機制和結構，最終會導致一個功能雜亂的大雜燴集群，到時候再根據(jù)功能分拆成較小的使用組會非常困難。

開發(fā)團隊通常把開發(fā)流水線劃分為離散的單元。這些單元會采用不同的形式或者被打上不同的標簽，但是最終會被劃分到幾類：開發(fā)環(huán)境、測試 (QA)環(huán)境、staging環(huán)境、生產(chǎn)環(huán)境。最終產(chǎn)生的布局非常適合Kubernetes命名空間。流水線中的每個環(huán)境或階段都有唯一的命名空間。

以上工作以及每個命名空間在開發(fā)周期中可以模板化并鏡像到下一個后續(xù)的環(huán)境，例如開發(fā)->測試->產(chǎn)品。事實上每個命名空間邏輯離散允許開發(fā)團隊在一個隔離的“ development ”命名空間內(nèi)工作。

DevOps（谷歌最接近的角色，被稱為網(wǎng)站可靠性工程，簡稱“SRE”）將負責在流水線各階段遷移代碼并確保為每個團隊分配適當?shù)沫h(huán)境。從根本上來說，DevOps僅負責最終的生產(chǎn)環(huán)境，這些環(huán)境運行著交付給終端用戶的解決方案。

將命名空間應用到開發(fā)周期的主要優(yōu)勢是：軟件組件（微服務/endpoints）很容易維護，在不同的環(huán)境之間不會產(chǎn)生命名沖突。這一點是借助于命名空間的隔離性實現(xiàn)的，比如 dev 環(huán)境下的 serviceX 對于其它命名空間而言是唯一的；但是，如果有必要，可以使用全名 service.development.mycluster.com 唯一地表示它。

在開發(fā)流水線中濫用命名空間，會產(chǎn)生一些不必要的環(huán)境。因此，如果你不做 staging 部署，就不要創(chuàng)建一個 ”staging” 命名空間。

擁擠的命名空間。比如，把所有的開發(fā)項目都放到 “devepment” 的命名空間下。由于命名空間類似于分區(qū)，你也可以對項目進行分區(qū)。由于命名空間是扁平的（不分層），你可能會希望這樣使用：projectA-dev，projectA-prod 作為projectA 的命名空間。

舉個例子，如果你是一家咨詢公司，希望為每個客戶管理多帶帶的應用程序，那么你可以使用命名空間進行分區(qū)。你可以為每個客戶、客戶項目或客戶業(yè)務單元創(chuàng)建一個多帶帶的命名空間，既能區(qū)分這些客戶，同時不需要擔心不同項目使用相同的資源名稱。

有一點需要注意：目前 Kubernetes 還沒有提供命名空間級別的訪問權限控制，對于你使用這種方式開發(fā)的應用，我們建議不要暴露給外界。

多租戶應用不需要使用 Kubernetes 的命名空間，因為應用本身已經(jīng)執(zhí)行了分區(qū)。如果使用的話，反而增加了額外的復雜度。

客戶到命名空間的映射方式不統(tǒng)一。例如，你贏得一個跨國企業(yè)客戶，可能最初考慮給它一個命名空間，而沒有考慮到它們內(nèi)部需要進一步分區(qū)，比如分成 BigCorp Accounting 和 BigCorp Engineering兩個區(qū)。這種情況下，客戶的每一個部門都要保證有一個命名空間。

在某些情況下，Kubernetes 命名空間提供的隔離不是你想要的，或者無法提供你想要的隔離。原因可能是地理，計費或安全因素。命名空間形成的邏輯分區(qū)有很多優(yōu)勢，但是目前還沒有能力保證利用分區(qū)的優(yōu)勢。Kubernetes集群中的任何用戶或資源，在不考慮命名空間時，可以訪問任意的集群資源。所以，如果你需要保護或隔離資源，終極的命名空間是一個多帶帶的Kubernetes集群，你可以定期對它做安全和ACL控制。

如果你希望使用跨地理的部署，也不要考慮命名空間。舉個例子，你希望部署在接近美國、歐洲和亞洲客戶的地理位置，那么最好在每個區(qū)部署一個kubernetes集群。

如果客戶要求細粒度的計費賬單，那么建議將賬單留給你基礎設置提供商。比如，在Google云計算平臺，你可以使用一個多帶帶的GCP項目或計費賬戶，針對特定客戶的項目創(chuàng)建一個kubernetes集群。

如果你要求客戶的保密和合規(guī)對其他客戶是完全不透明的，每個客戶一個集群的模式可以提供這種級別的隔離。而且，你需要將資源分區(qū)委托給底層的基礎設置供應商。

目前我們正在致力于兩個方面的開發(fā)：

1.為命名空間提供ACL，以增強安全性；
2, 提供集群聯(lián)邦。

這兩個特性背后的機制都會說明為什么要分離Kubernetes集群。

一個很容易理解的反模式是使用命名空間進行版本控制。你不應該使用命名空間區(qū)分集群資源的版本。容器和registry已經(jīng)提供了版本管理的功能，在Kubernetes中部署資源時也支持版本管理。

充分利用kubernetes的容器模型，可以實現(xiàn)多個版本共存，借助于 deployment 也可以實現(xiàn)版本的自動更新。另外，基于版本的命名空間會導致命名空間的不斷膨脹，增加了管理上的困難。

你可能希望創(chuàng)建層級的命名空間，然而事實上并不能。命名空間不能嵌套。比如說，你不能創(chuàng)建一個my-team.my-org 的命名空間，盡管你在 my-org 下可能有 my-team。

命名空間易于創(chuàng)建和使用，但是它也容易把代碼部署到錯誤的命名空間下。好的DevOps應該把這類工作文檔化和自動化，以充分減少錯誤的可能。另外，還要避免為kubectl 上下文設置錯誤的命名空間。

如前所述，Kubernetes 目前不提供命名空間級別的安全機制。只有在信任域內(nèi)（例如內(nèi)部使用）你才可以使用命名空間；如果你需要保證一個集群用戶或資源沒有權限訪問其他命名空間的資源，不要使用命名空間。對于這部分增強安全特性，涉及到 SIG-auth, 在Kubernetes特殊興趣小組 Authentication & Authorization 分組已經(jīng)討論過。

本文由時速云翻譯，如若轉(zhuǎn)載，需注明轉(zhuǎn)載自“時速云”

原文鏈接：http://blog.kubernetes.io/201...