超長乾貨 | Kubernetes命名空間詳解

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項目以及它們是如何經過對命名空間自己進行分組來擴展命名空間的。

命名空間是一個很是簡單又重要的概念，能夠幫助團隊管理集羣資源而且下降複雜性。花一些時間熟悉它們的優勢和特性能夠幫助你有效地配置集羣，避免未來遇到麻煩。