Kubernetes筆記（四）：詳解Namespace與資源限制ResourceQuota，LimitRange

【雨歌】發表於2020-06-03
筆記namespaceMIT

前面我們對K8s的基本元件與概念有了個大致的印象，並且基於K8s實現了一個初步的CI/CD流程，但對裡面涉及的各個物件（如Namespace, Pod, Deployment, Service, Ingress, PVC等）及各物件的管理可能還缺乏深入的理解與實踐，接下來的文章就讓我們一起深入K8s的各元件內部來一探究竟吧。下圖是基於個人的理解梳理的一個K8s結構圖，示例了各個元件（只包含了主要元件）如何協同。

k8s-struct

後續幾篇文章圍繞該圖涉及元件進行整理介紹，本文主要探究Namespace及與Namespace管理相關的資源限制ResourceQuota/LimitRange部分。

Namespace

理解

Namespace即名稱空間，主要有兩個方面的作用：

  1. 資源隔離：可為不同的團隊/使用者（或專案）提供虛擬的叢集空間，共享同一個Kubernetes叢集的資源。比如可以為團隊A建立一個Namespace ns-a，團隊A的專案都部署執行在 ns-a 中，團隊B建立另一個Namespace ns-b，其專案都部署執行在 ns-b 中，或者為開發、測試、生產環境建立不同的Namespace，以做到彼此之間相互隔離，互不影響。我們可以使用 ResourceQuota 與 Resource LimitRange 來指定與限制 各個namesapce的資源分配與使用
  2. 許可權控制：可以指定某個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: 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中可使用叢集資源的總量，包括兩個維度：

  1. 限定某個物件型別（如Pod）可建立物件的總數；
  2. 限定某個物件型別可消耗的計算資源（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 配置項。
resource-quota.png

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物件，我們可以：

  1. 限制namespace中每個Pod或容器的最小與最大計算資源
  2. 限制namespace中每個Pod或容器計算資源request、limit之間的比例
  3. 限制namespace中每個儲存卷宣告（PersistentVolumeClaim）可使用的最小與最大儲存空間
  4. 設定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

相關閱讀：

  1. Kubernetes筆記（一）：十分鐘部署一套K8s環境
  2. Kubernetes筆記（二）：瞭解k8s的基本元件與概念
  3. Kubernetes筆記（三）：Gitlab+Jenkins Pipeline+Docker+k8s+Helm自動化部署實踐（乾貨分享！）

作者：雨歌，一枚仍在學習路上的IT老兵
歡迎關注作者公眾號：半路雨歌，一起學習成長
qrcode

相關文章