※超省錢租車方案
商務出差、學生出遊、旅遊渡假、臨時用車!GO 神州租賃有限公司!合法經營、合法連鎖、合法租賃小客車!
前面我們對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中可使用集群資源的總量，包括兩個維度：
※Google地圖已可更新顯示潭子電動車充電站設置地點!!
日本、大陸，發現這些先進的國家已經早就讓電動車優先上路，而且先進國家空氣品質相當好，電動車節能減碳可以減少空污
- 限定某個對象類型（如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老兵
歡迎關注作者公眾號：半路雨歌，一起學習成長
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
有別於一般網頁架設公司，除了模組化的架站軟體，我們的營業主軸還包含：資料庫程式開發、網站建置、網頁設計、電子商務專案開發、系統整合、APP設計建置、專業網路行銷。
