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項目以及它們是如何通過對命名空間本身進行分組來擴展命名空間的。
命名空間是一個非常簡單又重要的概念，可以幫助團隊管理集羣資源並且降低複雜性。花一些時間熟悉它們的優點和特性可以幫助你有效地配置集羣，避免將來遇到麻煩。