Kubernetes筆記（四）：詳解Namespace與資源限制ResourceQuota，LimitRange
- 2020 年 6 月 3 日
- 筆記
- k8s, Kubernetes
前面我們對K8s的基本組件與概念有了個大致的印象，並且基於K8s實現了一個初步的CI/CD流程，但對裡面涉及的各個對象（如Namespace, Pod, Deployment, Service, Ingress, PVC等）及各對象的管理可能還缺乏深入的理解與實踐，接下來的文章就讓我們一起深入K8s的各組件內部來一探究竟吧。下圖是基於個人的理解梳理的一個K8s結構圖，示例了各個組件（只包含了主要組件）如何協同。
後續幾篇文章圍繞該圖涉及組件進行整理介紹，本文主要探究Namespace及與Namespace管理相關的資源限制ResourceQuota/LimitRange部分。
Namespace
理解
Namespace即命名空間，主要有兩個方面的作用：
- 資源隔離：可為不同的團隊/用戶（或項目）提供虛擬的集群空間，共享同一個Kubernetes集群的資源。比如可以為團隊A創建一個Namespace ns-a，團隊A的項目都部署運行在 ns-a 中，團隊B創建另一個Namespace ns-b，其項目都部署運行在 ns-b 中，或者為開發、測試、生產環境創建不同的Namespace，以做到彼此之間相互隔離，互不影響。我們可以使用 ResourceQuota 與 Resource LimitRange 來指定與限制 各個namesapce的資源分配與使用
- 許可權控制：可以指定某個namespace哪些用戶可以訪問，哪些用戶不能訪問
Kubernetes 安裝成功後，默認會創建三個namespace：
- default：默認的namespace，如果創建Kubernetes對象時不指定 metadata.namespace，該對象將在default namespace下創建
- kube-system：Kubernetes系統創建的對象放在此namespace下，我們前面說的kube-apiserver，etcd，kube-proxy等都在該namespace下
- kube-public：顧名思義，共享的namespace，所有用戶對該namespace都是可讀的。主要是為集群做預留，一般都不在該namespace下創建對象
實踐
1.查看namesapce
kubectl get namespaces
kubectl get namesapce
kubectl get ns # 三個操作等效
kubectl get ns --show-labels # 顯示namespace的label
使用namesapces,namesapce,ns都是可以的。如下列出了當前集群中的所有namespace
[root@kmaster ~]# kubectl get ns
NAME STATUS AGE
default Active 34d
develop Active 17d
ingress-nginx Active 33d
kube-node-lease Active 34d
kube-public Active 34d
kube-system Active 34d
kubernetes-dashboard Active 31d
pre-release Active 17d
可以使用 kubectl describe 命令來查看某個namespace的概要資訊，如
[root@kmaster ~]# kubectl describe ns default
Name: default
Labels: <none>
Annotations: <none>
Status: Active
No resource quota.
No resource limits.
2.創建namespace
有兩種方式：通過yaml定義文件創建或直接使用命令創建。
# 方式1. 通過yaml定義文件創建
[root@kmaster ~]# vim test-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: test # namespace的名稱
labels:
name: ns-test
[root@kmaster ~]# kubectl create -f ./test-namespace.yaml
# 方式2. 直接使用命令創建
[root@kmaster ~]# kubectl create ns test
3.在namesapce中創建對象
# 1. 在yaml中通過metadata.namesapce 指定
[root@kmaster ~]# kubectl get deploy my-nginx -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: my-nginx
name: my-nginx
namespace: test # 指定namespace
spec:
...
# 2. 在命令中通過 -n 或 --namesapce 指定
[root@kmaster ~]# kubectl run dev-nginx --image=nginx:latest --replicas=3 -n test
4.設定kubectl namesapce上下文
kubectl上下文即集群、namespace、用戶的組合，設定kubectl上下文，即可以以上下文指定的用戶，在上下文指定的集群與namespace中進行操作管理。查看當前集群kubectl上下文
# 查看當前kubectl上下文
[root@kmaster ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: //192.168.40.111:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
可見當前上下文為kubernetes-admin@kubernetes (current-context: kubernetes-admin@kubernetes)。
創建一個kubectl上下文
[root@kmaster ~]# kubectl config set-context test --namespace=test --cluster=kubernetes --user=kubernetes-admin
Context "test" created.
再次執行 kubectl config view 將可以看到上面創建的test上下文。
切換上下文
# 設置當前上下文
[root@kmaster ~]# kubectl config use-context test
Switched to context "test".
# 查看當前所在的上下文
[root@kmaster ~]# kubectl config current-context
test
指定了上下文，後續操作都在該上下文對應的namespace中進行，不需要再顯式指定namespace。在上下文中創建對象
# 在當前上下文中創建對象
[root@kmaster ~]# kubectl run my-nginx --image=nginx:latest --replicas=2
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/my-nginx created
# 查看創建的對象，不需要指定namespace
[root@kmaster ~]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
my-nginx 2/2 2 2 25m
[root@kmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
my-nginx-667764d77b-ldb78 1/1 Running 0 24m
my-nginx-667764d77b-wpgxw 1/1 Running 0 24m
刪除上下文
[root@kmaster ~]# kubectl config delete-context test
deleted context test from /root/.kube/config
也可以使用如下命令直接切換默認的namespace
# 將默認namespace設置為test
[root@kmaster ~]# kubectl config set-context --current --namespace=test
5.刪除namesapce
可以使用 kubectl delete ns <namespace名稱> 來刪除一個namesapce，該操作會刪除namespace中的所有內容。
[root@kmaster ~]# kubectl delete ns test
Resource Quota
Resource Quota即資源配額，限定單個namespace中可使用集群資源的總量，包括兩個維度：
- 限定某個對象類型（如Pod）可創建對象的總數；
- 限定某個對象類型可消耗的計算資源（CPU、記憶體）與存儲資源（存儲卷聲明）總數
如果在 namespace 中為計算資源 CPU 和記憶體設定了 ResourceQuota，用戶在創建對象（Pod、Service等）時，必須指定 requests 和 limits；如果在創建或更新對象時申請的資源與 namespace 的 ResourceQuota 衝突，則 apiserver 會返回 HTTP 狀態碼 403，以及對應的錯誤提示資訊。當集群中總的容量小於各個 namespace 資源配額的總和時，可能會發生資源爭奪，此時 Kubernetes 將按照先到先得的方式分配資源。
對象數量限制
聲明格式為： count/<resource>.<group>， 如下列出各類對象的聲明格式
count/persistentvolumeclaims
count/services
count/secrets
count/configmaps
count/replicationcontrollers
count/deployments.apps
count/replicasets.apps
count/statefulsets.apps
count/jobs.batch
count/cronjobs.batch
count/deployments.extensions
計算資源限制
定義CPU、記憶體請求（requests）、限制（limits）使用的總量，包括
- limits.cpu：namespace中，所有非終止狀態的 Pod 的 CPU 限制 resources.limits.cpu 總和不能超過該值
- limits.memory：namespace中，所有非終止狀態的 Pod 的記憶體限制 resources.limits.memory 總和不能超過該值
- requests.cpu：namespace中，所有非終止狀態的 Pod 的 CPU 請求 resources.requrest.cpu 總和不能超過該值
- requests.memory：namespace中，所有非終止狀態的 Pod 的 CPU 請求 resources.requests.memory 總和不能超過該值
存儲資源限制
定義存儲卷聲明請求的存儲總量或創建存儲卷聲明數量的限制，包括
- requests.storage：namespace中，所有存儲卷聲明（PersistentVolumeClaim）請求的存儲總量不能超過該值
- persistentvolumeclaims：namespace中，可以創建的存儲卷聲明的總數不能超過該值
<storage-class-name>.storageclass.storage.k8s.io/requests.storage：namespace中，所有與指定存儲類（StorageClass）關聯的存儲卷聲明請求的存儲總量不能超過該值<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims：namespace中，所有與指定存儲類關聯的存儲卷聲明的總數不能超過該值
除此之外，還可以對本地臨時存儲資源進行限制定義
- requests.ephemeral-storage：namespace中，所有 Pod 的本地臨時存儲（local ephemeral storage）請求的總和不能超過該值
- limits.ephemeral-storage：namespace中，所有 Pod 的本地臨時存儲限定的總和不能超過此值
實踐
查看是否開啟 Resource Quota 支援，默認一般是開啟的。如果沒有，可在啟動 apiserver 時為參數 –enable-admission-plugins 添加 ResourceQuota 配置項。
1.創建ResourceQuota
# 創建namespace
[root@kmaster ~]# kubectl create namespace test
# 編輯ResourceQuota定義文檔
[root@kmaster ~]# vim quota-test.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota-test
namespace: test
spec:
hard:
requests.cpu: "2"
requests.memory: 2Gi
limits.cpu: "4"
limits.memory: 4Gi
requests.nvidia.com/gpu: 4
pods: "3"
services: "6"
# 創建ResourceQuota
[root@kmaster ~]# kubectl apply -f quota-test.yaml
# 查看
[root@kmaster ~]# kubectl get quota -n test
NAME CREATED AT
quota-test 2020-05-26T10:31:10Z
[root@kmaster ~]# kubectl describe quota quota-test -n test
Name: quota-test
Namespace: test
Resource Used Hard
-------- ---- ----
limits.cpu 0 4
limits.memory 0 4Gi
pods 0 3
requests.cpu 0 2
requests.memory 0 2Gi
requests.nvidia.com/gpu 0 4
services 0 6
或者使用kubectl命令，如
[root@kmaster ~]# kubectl create quota quota-test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=test
我們在namespace test中創建了一個ResourceQuota，限制CPU、記憶體請求為2、2GB，限制CPU、記憶體限定使用為4、4GB，限制Pod個數為3 等。
我們來嘗試創建一個如下定義的Deployment來測試一下，
# 創建一個測試deploy
[root@kmaster ~]# vim quota-test-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: quota-test-deploy
spec:
selector:
matchLabels:
purpose: quota-test
replicas: 3
template:
metadata:
labels:
purpose: quota-test
spec:
containers:
- name: quota-test
image: nginx
resources:
limits:
memory: "2Gi"
cpu: "1"
requests:
memory: "500Mi"
cpu: "500m"
[root@kmaster ~]# kubectl apply -f quota-test-deploy.yaml -n test
# 查看pod
[root@kmaster ~]# kubectl get pod -n test
NAME READY STATUS RESTARTS AGE
quota-test-deploy-6b89fdc686-2dthq 1/1 Running 0 3m54s
quota-test-deploy-6b89fdc686-9m2qw 1/1 Running 0 3m54s
# 查看deploy狀態
[root@kmaster ~]# kubectl get deploy quota-test-deploy -n test -o yaml
message: 'pods "quota-test-deploy-6b89fdc686-rmktq" is forbidden: exceeded quota:
quota-test, requested: limits.memory=2Gi, used: limits.memory=4Gi, limited:
limits.memory=4Gi'
replicas: 3定義創建三個Pod副本，但只成功創建了兩個Pod，在deploy的status部分（最後一條命令結果），我們可以看到message提示第三個Pod創建時被拒絕，因為記憶體已達到限定。我們也可以將limits.memory調整為1Gi，將replicas調整為4，來驗證對Pod個數的限制。可看到最終只起了三個Pod，status部分message提示 pods "quota-test-deploy-9dc54f95c-gzqw7" is forbidden: exceeded quota:quota-test, requested: pods=1, used: pods=3, limited: pods=3。
Resource Limit Range
理解
Resource Quota 是對namespace中總體的資源使用進行限制，Resource Limit Range 則是對具體某個Pod或容器的資源使用進行限制。默認情況下，namespace中Pod或容器的資源消耗是不受限制的，這就可能導致某個容器應用記憶體泄露耗盡資源影響其它應用的情況。Limit Range可以用來限定namespace內Pod（或容器）可以消耗資源的數量。
使用LimitRange對象，我們可以：
- 限制namespace中每個Pod或容器的最小與最大計算資源
- 限制namespace中每個Pod或容器計算資源request、limit之間的比例
- 限制namespace中每個存儲卷聲明（PersistentVolumeClaim）可使用的最小與最大存儲空間
- 設置namespace中容器默認計算資源的request、limit，並在運行時自動注入到容器中
如果創建或更新對象（Pod、容器、PersistentVolumeClaim）對資源的請求與LimitRange相衝突，apiserver會返回HTTP狀態碼403，以及相應的錯誤提示資訊；如果namespace中定義了LimitRange 來限定CPU與記憶體等計算資源的使用，則用戶創建Pod、容器時，必須指定CPU或記憶體的request與limit，否則將被系統拒絕；當namespace總的limit小於其中Pod、容器的limit之和時，將發生資源爭奪，Pod或者容器將不能創建，但不影響已經創建的Pod或容器。
實踐
創建一個測試namespace test-limitrange，
# 創建測試namespace
[root@kmaster ~]# kubectl create namespace test-limitrange
# 切換默認的namespace
[root@kmaster ~]# kubectl config set-context --current --namespace=test-limitrange
創建LimitRange定義文件 lr-test.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: lr-test
spec:
limits:
- type: Container #資源類型
max:
cpu: "1" #限定最大CPU
memory: "1Gi" #限定最大記憶體
min:
cpu: "100m" #限定最小CPU
memory: "100Mi" #限定最小記憶體
default:
cpu: "900m" #默認CPU限定
memory: "800Mi" #默認記憶體限定
defaultRequest:
cpu: "200m" #默認CPU請求
memory: "200Mi" #默認記憶體請求
maxLimitRequestRatio:
cpu: 2 #限定CPU limit/request比值最大為2
memory: 1.5 #限定記憶體limit/request比值最大為1.5
- type: Pod
max:
cpu: "2" #限定Pod最大CPU
memory: "2Gi" #限定Pod最大記憶體
- type: PersistentVolumeClaim
max:
storage: 2Gi #限定PVC最大的requests.storage
min:
storage: 1Gi #限定PVC最小的requests.storage
該文件定義了在namespace test-limitrange 中，容器、Pod、PVC的資源限制，在該namesapce中，只有滿足如下條件，對象才能創建成功
- 容器的
resources.limits部分CPU必須在100m-1之間，記憶體必須在100Mi-1Gi之間，否則創建失敗 - 容器的
resources.limits部分CPU與resources.requests部分CPU的比值最大為2，memory比值最大為1.5，否則創建失敗 - Pod內所有容器的
resources.limits部分CPU總和最大為2，記憶體總和最大為2Gi，否則創建失敗 - PVC的
resources.requests.storage最大為2Gi，最小為1Gi，否則創建失敗
如果容器定義了
resources.requests沒有定義resources.limits，則LimitRange中的default部分將作為limit注入到容器中；如果容器定義了resources.limits卻沒有定義resources.requests，則將requests值也設置為limits的值；如果容器兩者都沒有定義，則使用LimitRange中default作為limits，defaultRequest作為requests值
創建與查看LimitRange，
# 創建LimitRange
[root@kmaster ~]# kubectl apply -f lr-test.yaml
# 查看
[root@kmaster ~]# kubectl describe limits lr-test
Name: lr-test
Namespace: test-limitrange
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container cpu 100m 1 200m 900m 2
Container memory 100Mi 1Gi 200Mi 800Mi 1500m
Pod cpu - 2 - - -
Pod memory - 2Gi - - -
PersistentVolumeClaim storage 1Gi 2Gi - - -
我們可以創建不同配置的容器或Pod對象來驗證，出於篇幅不再列出驗證步驟。
總結
本文對K8s的Namespace及針對Namespace的資源限制管理ResourceQuota，LimitRange進行了較為深入的探索，其中ResourceQuota對整個Namespace的資源使用情況進行限制，LimitRange則對單個的Pod或容器的資源使用進行限制。Namespace的許可權控制可基於RBAC來實現，後續再單獨進行梳理介紹。
原文地址：//blog.jboost.cn/k8s4-namespace.html
相關閱讀：
- Kubernetes筆記（一）：十分鐘部署一套K8s環境
- Kubernetes筆記（二）：了解k8s的基本組件與概念
- Kubernetes筆記（三）：Gitlab+Jenkins Pipeline+Docker+k8s+Helm自動化部署實踐（乾貨分享！）
作者：雨歌，一枚仍在學習路上的IT老兵
歡迎關注作者公眾號：半路雨歌，一起學習成長
