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

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

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

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

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

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

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

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

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

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

什么時(shí)候不使用命名空間

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這兩個(gè)特性背后的機(jī)制都會(huì)說明為什么要分離Kubernetes集群。

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

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

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

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

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

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

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