前面我們對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: 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、記憶體請求為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來實作，后續再單獨進行梳理介紹，
原文地址：http://blog.jboost.cn/k8s4-namespace.html
相關閱讀：
- Kubernetes筆記（一）：十分鐘部署一套K8s環境
- Kubernetes筆記（二）：了解k8s的基本組件與概念
- Kubernetes筆記（三）：Gitlab+Jenkins Pipeline+Docker+k8s+Helm自動化部署實踐（干貨分享！）
作者：雨歌，一枚仍在學習路上的IT老兵
歡迎關注作者公眾號：半路雨歌，一起學習成長
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/6764.html
標籤：其他
上一篇：如何通過IAM打造零信任安全架構
下一篇：Docker 容器優雅終止方案