Kubernetes筆記（四）：詳解Namespace與資源限制ResourceQuota，LimitRange
前面咱們對K8s的基本組件與概念有了個大體的印象，而且基於K8s實現了一個初步的CI/CD流程，但對裏面涉及的各個對象（如Namespace, Pod, Deployment, Service, Ingress, PVC等）及各對象的管理可能還缺少深刻的理解與實踐，接下來的文章就讓咱們一塊兒深刻K8s的各組件內部來一探究竟吧。下圖是基於我的的理解梳理的一個K8s結構圖，示例了各個組件（只包含了主要組件）如何協同。html
後續幾篇文章圍繞該圖涉及組件進行整理介紹，本文主要探究Namespace及與Namespace管理相關的資源限制ResourceQuota/LimitRange部分。node
Namespace
理解
Namespace即命名空間，主要有兩個方面的做用：nginx
- 資源隔離：可爲不一樣的團隊/用戶（或項目）提供虛擬的集羣空間，共享同一個Kubernetes集羣的資源。好比能夠爲團隊A建立一個Namespace ns-a，團隊A的項目都部署運行在 ns-a 中，團隊B建立另外一個Namespace ns-b，其項目都部署運行在 ns-b 中，或者爲開發、測試、生產環境建立不一樣的Namespace，以作到彼此之間相互隔離，互不影響。咱們可使用 ResourceQuota 與 Resource LimitRange 來指定與限制 各個namesapce的資源分配與使用
- 權限控制：能夠指定某個namespace哪些用戶能夠訪問，哪些用戶不能訪問
Kubernetes 安裝成功後，默認會建立三個namespace：shell
- default：默認的namespace，若是建立Kubernetes對象時不指定 metadata.namespace，該對象將在default namespace下建立
- kube-system：Kubernetes系統建立的對象放在此namespace下，咱們前面說的kube-apiserver，etcd，kube-proxy等都在該namespace下
- kube-public：顧名思義，共享的namespace，全部用戶對該namespace都是可讀的。主要是爲集羣作預留，通常都不在該namespace下建立對象
實踐
1.查看namesapcevim
kubectl get namespaces kubectl get namesapce kubectl get ns # 三個操做等效 kubectl get ns --show-labels # 顯示namespace的label
使用namesapces,namesapce,ns都是能夠的。以下列出了當前集羣中的全部namespaceapi
[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的概要信息，如app
[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中建立對象spa
# 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: https://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、內存請求爲二、2GB，限制CPU、內存限定使用爲四、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來實現，後續再單獨進行梳理介紹。
原文地址：http://blog.jboost.cn/k8s4-namespace.html
相關閱讀：
- Kubernetes筆記（一）：十分鐘部署一套K8s環境
- Kubernetes筆記（二）：瞭解k8s的基本組件與概念
- Kubernetes筆記（三）：Gitlab+Jenkins Pipeline+Docker+k8s+Helm自動化部署實踐（乾貨分享！）
做者：雨歌，一枚仍在學習路上的IT老兵
歡迎關注做者公衆號：半路雨歌，一塊兒學習成長
- 1. Kubernetes筆記（四）：詳解Namespace與資源限制ResourceQuota，LimitRange
- 2. kubernetes資源調度之LimitRange
- 3. kubernetes(k8s)：容器資源限制（內存限制、cpu限制、namespace限制）
- 4. Kubernetes Pod 資源限制
- 5. 深入理解Kubernetes資源限制：CPU
- 6. 深刻理解Kubernetes資源限制：CPU
- 7. 深刻理解 Kubernetes 資源限制：CPU
- 8. Kubernetes K8S之CPU和內存資源限制詳解
- 9. Kubernetes-Ingress資源詳解
- 10. 針對Kubernetes羣集作資源限制
- 更多相關文章...
- • Docker 資源彙總 - Docker教程
- • ARP協議的工作機制詳解 - TCP/IP教程
- • Tomcat學習筆記（史上最全tomcat學習筆記）
- • Docker容器實戰(六) - 容器的隔離與限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Kubernetes筆記（四）：詳解Namespace與資源限制ResourceQuota，LimitRange
- 2. kubernetes資源調度之LimitRange
- 3. kubernetes(k8s)：容器資源限制（內存限制、cpu限制、namespace限制）
- 4. Kubernetes Pod 資源限制
- 5. 深入理解Kubernetes資源限制：CPU
- 6. 深刻理解Kubernetes資源限制：CPU
- 7. 深刻理解 Kubernetes 資源限制：CPU
- 8. Kubernetes K8S之CPU和內存資源限制詳解
- 9. Kubernetes-Ingress資源詳解
- 10. 針對Kubernetes羣集作資源限制