為什麼需要 Namespace#
前一章的 Request 與 Limit 提供了「單一容器」層級的資源宣告,但實務上一個叢集往往同時被多個團隊或多個專案共用。如果所有資源都堆在同一個空間,名稱衝突、資源界線模糊等問題就會接踵而至。
Kubernetes 把這個問題抽象成 Namespace 概念:在同一個實體叢集裡,劃分出多個彼此隔離的「虛擬叢集(virtual cluster)」,讓不同團隊或專案能各自管理自己的資源。
什麼時候用 Namespace#
- 有多個團隊或多個專案同時使用同一個叢集。
- 需要對不同群組套用不同的資源配額或政策。
- 希望同一種資源名稱在不同情境下可以共存。
如果叢集只有少數幾個使用者,其實不一定要一開始就切 Namespace。借用前端框架 Vue 對 Vuex 的一句話:「就像眼鏡一樣,你總會在需要它的時候才想起它」。
查看 Namespace#
kubectl get namespace執行後會看到類似輸出:
NAME STATUS AGE
default Active 36h
kube-node-lease Active 36h
kube-public Active 36h
kube-system Active 36h
kubernetes-dashboard Active 36hKubernetes 預設會建立四個 Namespace:
default:沒有特別指定 Namespace 的物件會被放進這裡。kube-system:Kubernetes 系統元件使用的 Namespace。kube-public:自動建立,所有使用者(包含未驗證者)都可讀取,多用來放整個叢集都應該看得到的資源。kube-node-lease:存放與每個節點關聯的 Lease 物件,kubelet 透過它送出 heartbeat,幫助控制平面偵測節點故障。
預設的系統 Namespace 不要隨手刪。雖然 Kubernetes 會嘗試把它們重建回來,刪到一半出錯會帶來不必要的麻煩。
建立 Namespace#
kubectl create namespace demo-namespace建立後再查一次:
kubectl get namespace會多出一行:
demo-namespace Active 7s在指令中指定 Namespace#
當下指令時,用 --namespace 參數指定要操作的 Namespace:
kubectl run nginx --image=nginx --namespace=demo-namespace
kubectl get pods --namespace=demo-namespace修改預設 Namespace#
預設 kubectl 操作的對象都是 default Namespace。每次都加 --namespace 太繁瑣時,可以把 context 預設的 Namespace 換掉:
kubectl config set-context --current --namespace=demo-namespace驗證設定:
kubectl config view --minify | grep namespace:在 YAML 中指定 Namespace#
在資源 spec 的 metadata.namespace 欄位也可以直接指定 Namespace;省略時會落到當前 context 的預設 Namespace:
kind: Pod
metadata:
namespace: <ns-name>
name: <pod-name>Namespace 的幾個特性#
- 同一個 Namespace 內,資源名稱必須唯一。
- 不同 Namespace 之間,資源名稱可以重複。
- 刪除 Namespace 時,裡面的所有資源會一併消失。
- 可以搭配 ResourceQuota 與 LimitRange,在 Namespace 層級分配與限制資源。
小結#
Namespace 提供了「分組」與「隔離」的能力,是進入多人多專案管理的第一步。等到開始要替不同 Namespace 設定不同的資源規範,就會自然進入下一章的 LimitRange 與 ResourceQuota。
原文出處#
- GitHub:https://github.com/MikeHsu0618/2022-ithelp/tree/main/Day22
- iThome:https://ithelp.ithome.com.tw/articles/10296200