摘要：使用命名空間的概念幫助解決集群中在管理對象時的復雜性問題。命名空間為集群中的對象名稱賦予作用域。同樣，命名空間范圍的策略允許運維人員為生產環節設置嚴格的權限。這會修改操作在活躍時應用到的命名空間。

K8s使用命名空間的概念幫助解決集群中在管理對象時的復雜性問題。在本文中，會討論命名空間的工作原理，介紹常用實例，并分享如何使用命名空間來管理K8s對象。最后，介紹名為projects的Rancher特性是如何構建并擴展命名空間的概念的。

本文中，我們將探索Kubernetes命名空間，它是集群中組織和管理對象的一種方式。

介 紹

Kubernetes集群可以同時管理大量互不相關的工作負載，而組織通常會選擇將不同團隊創建的項目部署到共享集群上。隨著數量的增加，部署對象常常很快就會變得難以管理，拖慢操作響應速度，并且會增加危險錯誤出現的概率。

Kubernetes使用命名空間的概念幫助解決集群中在管理對象時的復雜性問題。命名空間允許將對象分組到一起，便于將它們作為一個單元進行篩選和控制。無論是應用自定義的訪問控制策略，還是為了測試環境而分離所有組件，命名空間都是一個按照組來處理對象、強大且靈活的概念。

在本文中，我們會討論命名空間的工作原理，介紹一些常用實例，并分享如何使用命名空間來管理Kubernetes對象。最后，我們還會介紹一個叫做projects（項目）的Rancher特性，看它是如何構建并擴展命名空間的概念的。

什么是命名空間，為什么它很重要？

命名空間（namespace）是Kubernetes提供的組織機制，用于給集群中的任何對象組進行分類、篩選和管理。每一個添加到Kubernetes集群的工作負載必須放在一個命名空間中。

命名空間為集群中的對象名稱賦予作用域。雖然在命名空間中名稱必須是唯一的，但是相同的名稱可以在不同的命名空間中使用。這對于某些場景來說可能幫助很大。例如，如果使用命名空間來劃分應用程序生命周期環境（如開發、staging、生產），則可以在每個環境中維護利用同樣的名稱維護相同對象的副本。

命名空間還可以讓用戶輕松地將策略應用到集群的具體部分。你可以通過定義ResourceQuota對象來控制資源的使用，該對象在每個命名空間的基礎上設置了使用資源的限制。類似地，當在集群上使用支持網絡策略的CNI（容器網絡接口）時，比如Calico或Canal（calico用于策略，flannel用于網絡）。你可以將NetworkPolicy應用到命名空間，其中的規則定義了pod之間如何彼此通信。不同的命名空間可以有不同的策略。

使用命名空間最大的好處之一是能夠利用Kubernetes RBAC（基于角色的訪問控制）。RBAC允許您在單個名稱下開發角色，這樣將權限或功能列表分組。ClusterRole對象用于定義集群規模的使用模式，而角色對象類型（Role object type）應用于具體的命名空間，從而提供更好的控制和粒度。在角色創建后，RoleBinding可以將定義的功能授予單個命名空間上下文中的具體具體用戶或用戶組。通過這種方式，命名空間可以使得集群操作者能夠將相同的策略映射到組織好的資源集合。

常見的命名空間使用模式

命名空間是一種非常靈活的特性，它不強制使用特定的結構或組織模式。不過盡管如此，還是有許多在團隊內常使用的模式。

將命名空間映射到團隊或項目上

在設置命名空間時有一個慣例是，為每個多帶帶的項目或者團隊創建一個命名空間。這和我們前面提到的許多命名空間的特性很好的結合在了一起。

通過給團隊提供專門的命名空間，你可以用RBAC策略委托某些功能來實現自我管理和自動化。比如從命名空間的RoleBinding對象中添加或刪除成員就是對團隊資源訪問的一種簡單方法。除此之外，給團隊和項目設置資源配額也非常有用。有了這種方式，你可以根據組織的業務需求和優先級合理地訪問資源。

使用命名空間對生命周期環境進行分區

命名空間非常適合在集群中劃分開發、staging以及生產環境。通常情況下我們會被建議將生產工作負載部署到一個完全獨立的集群中，來確保最大程度的隔離。不過對于較小的團隊和項目來說，命名空間會是一個可行的解決方案。

和前面的用例一樣，網絡策略、RBAC策略以及配額是實現用例的重要因素。在管理環境時，通過將網絡隔離來控制和組件之間的通信能力是很有必要的。同樣，命名空間范圍的RBAC策略允許運維人員為生產環節設置嚴格的權限。配額能夠確保對最敏感環境的重要資源的訪問。

重新使用對象名稱的能力在這里很有幫助。在測試和發布對象時，可以把它們放到新環境中，同時保留其命名空間。這樣可以避免因為環境中出現相似的對象而產生的混淆，并且減少認知開銷。

使用命名空間隔離不同的使用者

另一個命名空間可以解決的用例是根據使用者對工作負載進行分段。比如，如果你的集群為多個客戶提供基礎設施，那么按命名空間進行分段就能夠實現管理每個客戶，同時跟蹤賬單的去向。

另外，命名空間的特性可以讓你控制網絡和訪問策略，為你的使用者定義不同的配額。在通用的情況下，命名空間允許你為每個用戶開發和部署相同模板化環境的不同實例。這種一致性可以大大簡化管理和故障診斷的過程。

理解預配置的Kubernetes命名空間

在我們進行創建命名空間之前，先討論一下Kubernetes是如何自動設置它的。在默認情況下，新的集群上有三個命名空間：

default：向集群中添加對象而不提供命名空間，這樣它會被放入默認的命名空間中。在創建替代的命名空間之前，該命名空間會充當用戶新添加資源的主要目的地，無法刪除。

kube-public：kube-public命名空間的目的是讓所有具有或不具有身份驗證的用戶都能全局可讀。這對于公開bootstrap組件所需的集群信息非常有用。它主要是由Kubernetes自己管理。

kube-system：kube-system命名空間用于Kubernetes管理的Kubernetes組件，一般規則是，避免向該命名空間添加普通的工作負載。它一般由系統直接管理，因此具有相對寬松的策略。

雖然這些命名空間有效地將用戶工作負載與系統管理的工作負載隔離，但它們并不強制使用任何額外的結構對應用程序進行分類和管理。比較友好的是，創建和使用額外的命名空間非常簡單

使用命名空間

使用kubectl管理命名空間及其包含的資源相當簡單。在這一節中，我們將演示一些最常見的命名空間操作，便于你開始有效地分割資源。

查看現有的命名空間

要顯示集群中可用的所有命名空間，使用kubectl get namespaces命令：

該命令顯示了所有可用的命名空間，無論它們是否是活躍的。此外還有資源的時長（age）。

如果想獲得更詳細的信息，使用kubectl describe命令：

Name: default

Labels: field.cattle.io/projectId=p-cmn9g

Annotations: cattle.io/status={"Conditions":[{"Type":"ResourceQuotaInit","Status":"True","Message":"","LastUpdateTime":"2018-12-17T23:17:48Z"},{"Type":"InitialRolesPopulated","Status":"True","Message":"","LastUpda... field.cattle.io/projectId=c-7tf7d:p-cmn9g lifecycle.cattle.io/create.namespace-auth=true

Status: Active

No resource quota.

No resource limits.

該命令用于顯示與命名空間關聯的標簽和注釋，以及已經應用了的所有配額或資源限制。

創建命名空間

我們使用kubectl create namespace命令來創建命名空間。用命名空間的名稱作為該命令的參數。

你還可以通過文件，使用manifest來創建命名空間。例如，下面的文件定義了我們和上面一模一樣的命名空間。

假設上面的規范保存在demo-namespace.yml文件中。你可以輸入指令來使用它：

無論我們采用哪種方法創建命名空間，在我們再次檢查可用命名空間時，應該能列出新的命名空間（我們使用ns——命名空間的縮寫，第二次進行查詢）：

我們新創建的命名空間已經變為可使用。

根據命名空間篩選和執行操作

如果我們將一個工作負載對象部署到集群而不指定命名空間，它將被添加到默認命名空間：

我們可以使用kubectl來驗證部署是否創建在默認的命名空間：

如果我們嘗試再次使用相同的名稱創建部署，會得到命名空間沖突的錯誤。

要將操作應用于不同的命名空間，我們必須在命令中包含—namespace=這一選項。下面我們在demo-namespace命名空間上創建具有相同名稱的部署：

這次部署成功了，盡管我們仍然使用的是相同的部署名稱。命名空間為資源名稱提供了不同的作用域，避免了前面所經歷的命名沖突。

如果想查看新部署的詳細信息，我們再次使用—namespace=選項指定命名空間：

這說明我們已經在demo-namespace命名空間創建了另一個名為demo-nginx的部署。

通過設置Context選擇命名空間

如果希望避免為每個命令提供同樣的命名空間，可以通過配置kubectl的context來改變命令作用的默認命名空間。這會修改操作在context活躍時應用到的命名空間。

列出context配置的細節，輸入：

上圖說明我們使用了一個名為Default的context，context沒有指定命名空間，因此使用了默認命名空間。

想要將該context使用的命名空間修改成demo-context，我們輸入：

我們可以在此查看context配置來驗證當前是否選擇了demo-namespace：

驗證我們的kubectl describe命令現在默認使用demo-namespace，它會請求我們的demo-nginx部署而不需要指定命名空間：

刪除命名空間并清理

如果不需要命名空間了，我們可以刪除它。

刪除命名空間這一功能非常強大，因為它不僅刪除命名空間，還會清理其中部署了的所有資源。這一功能非常方便，但是同時如果你一不小心，也會非常危險。

在刪除之前，最好列出和命名空間相關的資源，確定想要刪除的對象：

一旦確定了要操作的范圍，可以輸入下面的命令刪除demo-namespace命名空間和其中的所有資源：

命名空間及其資源將從集群中刪除

如果你之前在kubectl上下文中更改了所選的命名空間，那么輸入下面的命令清除所選的命名空間：

在清理demo資源時，請記住刪除我們最初提供給默認命名空間的原始demo-nginx部署：

現在你的集群應該處于一開始的狀態了。

使用Rancher的Project擴展命名空間

如果你使用Rancher來管理Kubernetes集群，那么你就可以使用projects特性提供的擴展功能。Rancher里的Project是一個額外的組織層，用于將多個命名空間綁定在一起。

Rancher的project在命名空間上覆蓋了一個控制結構，允許你將命名空間分組成邏輯單元并對其應用相應的策略。Project在大多數情況下反映了命名空間，但它是作為命名空間的容器而不是多帶帶的工作負載資源。Rancher中的每個命名空間只存在于一個project中，命名空間繼承應用于該項目的所有策略。

在默認情況下，Rancher集群定義了兩個project：

Default：該project包含了默認命名空間

System：該project包含所有其他預配置的命名空間，包括kube-public、kube-system和系統提供的所有命名空間

在選擇了集群之后，你可以通過訪問Projects/Namespaces選項卡來查看集群中可用的項目：

在這里，單擊Add Project按鈕來添加project。在新建project時，你可以配置project成員及其訪問權限，還可以配置安全策略和資源配額。

你還可以點擊project的Add Namespace按鈕向現有的項目添加命名空間。如果要將命名空間移動到不同的project上，請先選擇命名空間，單擊Move按鈕。將命名空間移動到新project中的開關會立即修改應用于該命名空間的權限和策略。

Rancher的project沒有引入新的組織模型，而是簡單地將相同的抽象應用到了命名空間上，而命名空間作用于工作負載對象。如果你喜歡使用命名空間，但是又需要額外的控制層的話，那么它們就能夠填補這一使用上的空白。

總 結

在本文中，我們介紹了Kubernetes命名空間的概念以及它們是如何幫助管理集群資源的。我們討論了集群中命名空間是如何為資源名稱分段和分作用域的，以及在命名空間層面應用的策略如何影響用戶權限和資源分配。

之后，我們介紹了團隊用命名空間將集群分段成邏輯塊的一些常用模式，描述了Kubernetes預配置的命名空間及其用途。然后，我們還了解了如何在集群中創建和使用命名空間。最后，我們還介紹了Rancher項目以及它們是如何通過對命名空間本身進行分組來擴展命名空間的。

命名空間是一個非常簡單又重要的概念，可以幫助團隊管理集群資源并且降低復雜性。花一些時間熟悉它們的優點和特性可以幫助你有效地配置集群，避免將來遇到麻煩。