Kubernetes CKA課程筆記 18
Namespaces(ns):
- 在K8s的Cluster中,可以定義所謂的Namespaces
- 並在Namespaces內組織所需要的K8s Components
- (像是deploy,pod,ingress…etc)
- 可以將Namespaces想像成Cluster中的虛擬的Cluster
可以在master機透過以下指令確認有哪些Namespace(ns):
kubectl get namespace
當然我們可以自己建Namespace,執行以下指令:
kubectl create namespace {namespace名稱}
另一種建立namespace的方式是用namespace的configuration file:
其他K8s元件的configuration file通常也會描述在哪一個namespace
也是元件歷史的部分,所以都建議要使用namespace(如下)
接下來講講為啥會建議要用Namespaces:
- 如果不建Namespaces
亦即所有K8s元件都存在於default這個Namespace:
- 又當應用程式龐大又複雜情況(如下圖),所需K8s元件非常多
- 整體就很難Overview裡面總共有哪些元件
但是改成以下這樣就很容易看:
2.團隊區分Namespaces:
- 不同團隊共用預設的default namespace可能會有以下衝突結果
- 但是改用下列方式將不同團隊做區別就沒問題
- 或是也可以幫不同團隊創造各自專案使用的namespace來劃分
3.不同階段(dev,uat...etc)程式共用資源:
- 考量方式如下圖,不同程式驗證階段可以共用cluster內相同的資源
- 並且上述dev/uat也可以是PROD的blue & green(做藍綠佈署驗證)!
4.限制團隊Resources
- 不同團隊僅能進去自己所屬的namespace操作K8s元件
- (namespace還有限制CPU/記憶體/storage per NS等硬體資源)
- 如下圖所示概念
整理上述劃分namespaces可能場景如下:
- Structure tour components
- Avoid conflicts between teams
- Share service between different environments
- Access And Resource Limits on Namespace Level
值得注意的是,例如ConfigMap內容都指向同一個DB
兩個AP的namespace內應用程式都需要時,只能建各自的ConfigMap
(儘管裡面DB帳號密碼URL都一致,不同Namespace也無法共用)
(同理secret也是如此)
但是ConfigMap內指向的DB的service元件
其ConfigMap內的db_url可能也帶有namespace的部分名稱
另外還要注意有部分K8s元件無法定義在namespace內部例如:
1.volume(persistent volume),整個cluster內的元件都可以調用
其他還有哪些K8s元件(Resources)是有分在namespace內還是外,可用指令:
kubectl api-resources --namespaced=false
反過來看那些元件Resources是有被namespace綁住的執行:
kubectl api-resources --namespaced=true
確認namespace還可簡短如下:
kubectl get ns
並且有些其他指令也會順帶帶出namespace資訊,例如:
kubectl get pod
由上可以看出指令預設都執行到default這個namespace去了
所以可以改執行指定我們要查找的namespace如下:
kubectl get pod -n {namespace名稱}
指定找kube-system這個namespace內的pod示範如下:
