集群編譯器
1. 了解Kubernetes資源類型
在深入研究Kubernetes資源之前，讓我們先澄清一下「資源」一詞在這里指的是什麼。我們在Kubernetes集群中創建的任何東西都被視為一種資源：部署、pod、服務等。在本文中，我們將重點介紹CPU和內存等主要資源，以及暫態存儲和擴展資源等其他資源類型。
集群管理的一個方面是將這些資源自動分配給在pod中運行的容器，這樣，理想情況下，每個容器都有它所需的資源（但沒有更多）。
在本文中，我們將重點介紹集群上運行的容器的邏輯資源。我們將分析開發人員每天使用的四種常見Kubernetes資源：CPU、內存、暫態存儲和擴展資源。對於每種資源，我們將 探索 如何在Kubernetes中衡量它，回顧如何監控每種特定資源，並強調優化資源使用的一些最佳實踐。
CPU
Kubernetes集群通常運行在多台機器上，每台機器都有多個CPU核。它們加起來就是可用內核的總數。
我們不需要使用所有的內核。我們可以以1/1000的增量指定CPU核心的任何部分（例如，半個核心或500百萬CPU）。
Kubernetes容器在Linux內核上運行，這允許指定cGroup來限制資源。Linux調度器將使用的CPU時間（由內部時間片定義）與定義的限制進行比較，以決定是否在下一個時間片中運行容器。我們可以使用kubectl top命令查詢CPU資源，為pod或節點調用它。
我們可以通過改進演算法和編碼，或者通過編譯器優化，使程序在容器中運行更加高效，從而優化處理器時間的使用。集群用戶對預編譯容器的速度或效率沒有太大影響。
內存
Kubernetes集群中的每台機器也都有內存，加起來就是集群的總數。內核級控制主內存，類似於使用cGroup的CPU時間。如果容器中的常式請求的內存分配超出了硬限制，則表示內存不足錯誤。
優化資源使用在很大程度上取決於應用程序的開發工作。一個步驟是提高垃圾收集頻率，以防止基於堆的鏡像分配的內存超過硬限制。同樣，kubectl top命令可以提供有關內存使用的信息。
探索 CPU和內存
作為我們的第一個深入示例，讓我們將流行web伺服器NGINX的三個復制容器部署到本地Kubernetes安裝中。我們在筆記本電腦上運行一個單節點「集群」，它只有兩個內核和2 GiB的內存。
下面的代碼定義了這種pod部署，並將十分之一的核心（100 milli-CPU）和100 MiB的主內存授予三個NGINX容器中的每一個。下面的代碼還將它們的使用限制為請求值的兩倍。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
cpu: "100m"
memory: "100Mi"
limits:
cpu: "200m"
memory: "200Mi"
ports:
- containerPort: 80
我們可以這樣部署到默認命名空間：
kubectl apply -f nginx.yaml
本地集群只有一個節點。使用此命令可返回有關它的詳細信息：
kubectl describe nodes docker-desktop
在剪切大部分輸出後，我們可以檢查一些有關資源使用的信息：
[...]
Namespace Name CPU. Requests CPU Limits Memory Requests Memory Limits Age
--------- ---- ------------ ---------- --------------- ------------- ---
default nginx-deployment-585bd9cc5f-djql8 100m (5%) 200m (10%)100Mi (5%) 200Mi (10%) 66s
default nginx-deployment-585bd9cc5f-gz98r 100m (5%) 200m (10%)100Mi (5%) 200Mi (10%) 66s
default nginx-deployment-585bd9cc5f-vmdnc 100m (5%) 200m (10%)100Mi (5%) 200Mi (10%) 66s
[...]
Resource Requests Limits
-------- -------- ------
cpu 1150m (57%) 600m (30%)
memory 540Mi (28%) 940Mi (49%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
[...]
此信息顯示CPU和內存使用請求和限制，就像我們的部署對象指定的那樣。它還將值顯示為最大可能分配的百分比。
接下來是該節點的當前總數，再次以絕對值和百分比列出。這些數字包括在kube系統命名空間中運行的一些其他容器，我們在這里沒有顯示這些容器，因此上面的輸出中沒有包含差異。
上面代碼段的最後三行表示CPU和內存之外的其他類型的資源，在本例中，這些資源沒有設置請求或限制。
暫態存儲
另外一種Kubernetes資源類型是暫態存儲。這是在pod生命周期內無法存活的掛載式存儲。Kubernetes經常使用暫態存儲來緩存或日誌，但從不將其用於重要數據，如用戶記錄。我們可以請求或限制暫態存儲，比如主內存，但它通常不是一種有限的資源。
那麼，在上面的代碼片段中，hugepages-1Gi和hugepages-2Mi是什麼意思呢？巨頁面是Linux內核的一種現代內存功能，用於為進程分配可配置大小的大型主內存頁面。為了提高效率，我們可以這樣做。
Kubernetes支持將如此大的頁面分配給容器。這些構成了我們可以單獨請求的每個頁面大小的資源類型。
在指定請求或限制時，我們設置的是內存總量，而不是頁數。
limits:
hugepages-2Mi: "100Mi"
hugepages-1Gi: "2Gi"Here, we limit the number of 2 MiB pages to 50 and the number of 1 GiB pages to 2.
擴展資源
集群用戶還可以使用擴展資源類型定義自己的資源類型（每個集群或節點）。一旦定義了類型並指定了可用單元，我們就可以使用請求和限制，就像我們目前使用的內置資源一樣。
例如：
limits:
cpu: "200m"
myproject.com/handles: 100
此設置將容器限制為核心的20%和項目句柄的100%。
資源請求和限制
請注意，資源請求和限制是我們討論暫態存儲和擴展資源的關鍵。這是因為最終用戶可以在應用程序的部署清單中指定資源請求和限制，這對Kubernetes應該如何處理容器或pod施加了一些規則。
請求指示容器應該擁有多少資源。它們幫助調度器根據請求的資源量和節點上的可用資源量將pod分配給節點。
限制用於指示容器可以使用多少資源的硬上限，在操作系統級別強制執行。請求和限制是可選的，但如果我們不指定限制，容器可以使用節點的大部分資源，這可能會帶來負面的成本或性能影響。因此，我們必須謹慎行事。
請記住，雖然一個pod可以包含多個容器，但通常每個pod只有一個容器。我們將資源分配給容器，但pod的所有容器都來自節點級別的公共資源池。
考慮服務質量
到目前為止，我們描述的資源系統是管理計算資源的一種相當簡單的方法。Kubernetes提供了一個簡單的服務質量（QoS）系統。
QoS描述了一個技術系統在硬體有限的情況下，在保持最佳總體質量的同時提供不同服務級別的方法。Kubernetes QoS系統為pod分配三個級別中的一個：Guaranteed、Burstable和BestEffort。
在pod的生命周期內，Guaranteed級別提供了所需且有限的資源，適合在恆定負載下運行的監控系統等應用。
Burstable服務級別適用於具有基本使用模式的pod，由於需求增加，這些pod的使用模式有時會超過基線。這個級別非常適合資料庫或web伺服器，它們的負載取決於傳入請求的數量。
BestEffort不保證資源可用性。因此，它最適合於批處理作業之類的應用程序，它們可以在需要時重復，或者適合於非任務關鍵型的暫存環境。
結論
Kubernetes集群維護CPU時間、內存、暫態存儲和擴展資源等硬體資源，並將它們分配給正在運行的容器。通過一個請求和限制系統，運維人員可以根據單個容器定製資源分配，然後讓Kubernetes系統將它們適當地分配給節點。
擴展資源使我們能夠定義自己的資源類型，並以類似的方式使用它們。Kubernetes還根據請求和限制將服務質量指定給pod。然後，它使用這些名稱來制定計劃和終止決策。
Kubernetes資源優化對於平衡成本和最終用戶體驗至關重要。然而，使用本文的方法手動分配參數可能會非常耗時、昂貴，而且難以擴展。
原文鏈接：
https://thenewstack.io/understanding-kubernetes-resource-types/