深入理解K8s資源限制，你明白了嗎？
深入理解K8s資源限制
資源限制是 Kubernetes 中可配置的重要選項之一，它包含兩方面內容：
工作負載的資源需求：用于定義工作負載運行時所需的最低資源。調度器根據這一信息選擇合適的節點來部署工作負載。
資源的最大限制：用于規定工作負載可以消耗的資源上限。Kubelet 節點守護進程依賴這一配置來管理 Pod 的運行和健康狀態。
換句話說，資源需求確保工作負載能夠正常運行，而資源限制則避免單個工作負載過度消耗節點資源。
資源限制
資源限制通過每個容器的 containerSpec 中的 resources 字段進行設置，該字段是 v1 版本的 ResourceRequirements 類型的 API 對象。通過設置 limits 和 requests，可以分別定義資源的上限和需求。
當前支持的資源類型主要有 CPU 和 內存。通常情況下，deployment、statefulset 和 daemonset 的定義中都會包含 podSpec，而 podSpec 內部會定義一個或多個 containerSpec。
以下是一個完整的 v1 資源對象的 YAML 配置示例：
resources:
requests:
cpu: 50m
memory: 50Mi
limits:
cpu: 100m
memory: 100Mi可以這樣理解：該容器通常需要 5% 的 CPU 時間 和 50MiB 的內存（由 requests 定義），但在高峰時允許其最多使用 10% 的 CPU 時間 和 100MiB 的內存（由 limits 定義）。
稍后我會更詳細地解釋 requests 和 limits 的區別，但一般來說：
- requests 在調度階段更為關鍵，因為調度器會根據 requests 判斷節點是否有足夠的資源來運行容器。
- limits 在運行階段更重要，Kubelet 會使用它來限制容器的資源消耗，確保單個容器不會過度占用節點資源。
雖然資源限制是為每個容器配置的，但 Pod 的整體資源限制可以視為其所有容器資源限制的總和。從系統的角度來看，這種關系非常直觀。
內存限制
CPU資源限制比內存資源限制更復雜，但它們都是通過cgroup控制的，所以我們可以用類似的方法來處理。接下來，我們重點看它們的不同之處。
首先，我們在之前的 YAML 文件中加入 CPU 的資源限制：
resources:
requests:
memory: 50Mi
cpu: 50m
limits:
memory: 100Mi
cpu: 100m這里的 m 表示千分之一核。例如，50m 代表 0.05 核，100m 代表 0.1 核，而 2000m 就是 2 核。這樣配置后，容器需要至少 5% 的 CPU 資源才能運行，同時最多能使用 10% 的 CPU 資源。
接著，我們創建一個只配置了 CPU requests 的 Pod：
kubectl run limit-test --image=busybox --requests "cpu=50m" --command -- /bin/sh -c "while true; do sleep 2; done"用以下命令可以驗證 Pod 的資源配置：
kubectl get pods limit-test-5b4c495556-p2xkr -o=jsnotallow='{.spec.containers[0].resources}'輸出：
map[requests:map[cpu:50m]]同時，用 Docker 查看容器對應的 CPU 配置：
docker ps | grep busy | cut -d' ' -f1
f2321226620e
docker inspect f2321226620e --format '{{.HostConfig.CpuShares}}'
51這里顯示 51 而不是 50，是因為 Kubernetes 把 CPU 核心劃分為 1000 個份額（shares），而 Linux 內核用 1024 個時間片表示 CPU 的分配比例。CPU 的 shares 是一個相對值，用來劃分 CPU 使用權：
- 如果有兩個 cgroup（A 和 B），A 的 shares 是 1024，B 是 512，那么 A 獲得 66% 的 CPU 資源，B 獲得 33%。
- 如果 CPU 空閑，B 可以使用更多資源。
- 如果新增一個 cgroup C，A 和 B 的占比會減少。
接下來，再看看設置了 CPU limits 的 Pod 會發生什么：
kubectl run limit-test --image=busybox --requests "cpu=50m" --limits "cpu=100m" --command -- /bin/sh -c "while true; do sleep 2; done"再次用 kubectl 查看資源限制：
kubectl get pods limit-test-5b4fb64549-qpd4n -o=jsnotallow='{.spec.containers[0].resources}'輸出：
map[limits:map[cpu:100m] requests:map[cpu:50m]]而對應的 Docker 配置：
docker inspect f2321226620e --format '{{.HostConfig.CpuShares}} {{.HostConfig.CpuQuota}} {{.HostConfig.CpuPeriod}}'
51 10000 100000CpuShares 是對應 requests 的 CPU 份額。
CpuQuota和
CpuPeriod是用來實現
limits的：
- CpuPeriod 表示一個時間周期（默認為 100 毫秒，即 100,000 微秒）。
- CpuQuota 表示每周期允許使用的 CPU 時間（100m 對應 10,000 微秒）。
這些值最終映射到 cgroup：
cat /sys/fs/cgroup/cpu,cpuacct/.../cpu.cfs_period_us
100000
cat /sys/fs/cgroup/cpu,cpuacct/.../cpu.cfs_quota_us
10000例子：
限制 1 核（每 250ms 內用 250ms CPU 時間）：
echo 250000 > cpu.cfs_quota_us
echo 250000 > cpu.cfs_period_us限制 2 核（每 500ms 內用 1000ms CPU 時間）：
echo 1000000 > cpu.cfs_quota_us
echo 500000 > cpu.cfs_period_us限制 1 核的 20%（每 50ms 用 10ms CPU 時間）：
echo 10000 > cpu.cfs_quota_us
echo 50000 > cpu.cfs_period_us簡單總結：
- requests 保證容器最少能用的 CPU 資源。
- limits 確保容器最多使用的 CPU 時間不會超過限制。
默認限制
要為命名空間中的 Pod 設置默認的資源限制，可以使用 Kubernetes 提供的 LimitRange 資源。通過配置 LimitRange，可以為每個命名空間設置默認的 requests 和 limits，從而確保 Pod 的資源分配有合理的默認值和邊界限制。以下是如何實現的說明和示例：
創建一個 LimitRange 示例：
以下 YAML 文件定義了一個 LimitRange 資源：
apiVersion: v1
kind: LimitRange
metadata:
name: default-limit
spec:
limits:
- default:
memory: 100Mi
cpu: 100m
defaultRequest:
memory: 50Mi
cpu: 50m
- max:
memory: 512Mi
cpu: 500m
- min:
memory: 50Mi
cpu: 50m
type: Container字段解析
default:
- 設置默認的 limits 值。
- 如果 Pod 未明確指定 limits，則系統自動分配 100Mi 內存和 100m CPU。
defaultRequest:
- 設置默認的 requests 值。
- 如果 Pod 未明確指定 requests，則系統自動分配 50Mi 內存和 50m CPU。
max 和 min:
- max: 定義 limits 的最大值。如果 Pod 資源分配超過這個值，Pod 將被拒絕創建。
- min: 定義 requests 的最小值。如果 Pod 資源分配低于這個值，Pod 也將被拒絕創建。
type:
- 指定適用范圍為 Container。
工作機制
Kubernetes 的LimitRanger準入控制器負責應用這些限制：
- 在創建 Pod 之前，如果 Pod 的 limits 或 requests 未設置，則自動添加 LimitRange 中的默認值。
- 如果 Pod 的資源配置超出 max 或低于 min，則拒絕創建。
示例 Pod 及 LimitRanger 插件設置的注釋
apiVersion: v1
kind: Pod
metadata:
annotations:
kubernetes.io/limit-ranger: 'LimitRanger plugin set: cpu request for container limit-test'
name: limit-test
namespace: default
spec:
containers:
- name: limit-test
image: busybox
args:
- /bin/sh
- -c
- while true; do sleep 2; done
resources:
requests:
cpu: 100mannotations: 顯示 LimitRanger 插件已經為 Pod 自動添加了默認的資源 requests。
總結
1、使用 LimitRange，可以為命名空間設置默認的 requests 和 limits，避免 Pod 沒有資源限制帶來的風險。
2、max 和 min 設置了資源的上下限，確保 Pod 的資源分配符合命名空間的約束。
3、LimitRanger 插件會在 Pod 創建時檢查并自動設置默認值，使資源限制更加自動化和規范化
