2. 程式人生 > >深入理解K8s資源限制[轉

深入理解K8s資源限制[轉

阿新 • • 發佈：2019-07-02

寫在前面

當我開始大範圍使用Kubernetes的時候，我開始考慮一個我做實驗時沒有遇到的問題：當叢集裡的節點沒有足夠資源的時候，Pod會卡在Pending狀態。你是沒有辦法給節點增加CPU或者記憶體的，那麼你該怎麼做才能將這個Pod從這個節點拿走？最簡單的辦法是新增另一個節點，我承認我總是這麼幹。最終這個策略無法發揮出Kubernetes最重要的一個能力：即它優化計算資源使用的能力。這些場景裡面實際的問題並不是節點太小，而是我們沒有仔細為Pod計算過資源限制。

資源限制是我們可以向Kubernetes提供的諸多配置之一，它意味著兩點：工作負載執行需要哪些資源；最多允許消費多少資源。第一點對於排程器而言十分重要，因為它要以此選擇合適的節點。第二點對於Kubelet非常重要，每個節點上的守護程序Kubelet負責Pod的執行健康狀態。大多數本文的讀者可能對資源限制有一定的瞭解，實際上這裡面有很多有趣的細節。在這個系列的兩篇文章中我會先仔細分析記憶體資源限制，然後第二篇文章中分析CPU資源限制。

資源限制

資源限制是通過每個容器containerSpec的resources欄位進行設定的，它是v1版本的ResourceRequirements型別的API物件。每個指定了”limits”和”requests”的物件都可以控制對應的資源。目前只有CPU和記憶體兩種資源。第三種資源型別，持久化儲存仍然是beta版本，我會在以後的部落格裡進行分析。大多數情況下，deployment、statefulset、daemonset的定義裡都包含了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比較重要，在執行時limits比較重要。儘管資源限制配置在每個容器上，你可以認為Pod的資源限制就是它裡面容器的資源限制之和，我們可以從系統的視角觀察到這種關係。

記憶體限制

通常情況下分析記憶體要比分析CPU簡單一些，所以我從這裡開始著手。我的一個目標是給大家展示記憶體在系統中是如何實現的，也就是Kubernetes對容器執行時（docker/containerd）所做的工作，容器執行時對Linux核心所做的工作。從分析記憶體資源限制開始也為後面分析CPU打好了基礎。首先，讓我們回顧一下前面的例子：

resources:  
    requests:    
        memory: 50Mi
    limits:    
        memory: 100Mi

單位字尾Mi表示的是MiB，所以這個資源物件定義了這個容器需要50MiB並且最多能使用100MiB的記憶體。當然還有其他單位可以進行表示。為了瞭解如何用這些值是來控制容器程序，我們首先建立一個沒有配置記憶體限制的Pod:

$ kubectl run limit-test --image=busybox --command -- /bin/sh -c "while true; do sleep 2; done"
deployment.apps "limit-test" created

用Kubectl命令我們可以驗證這個Pod是沒有資源限制的：

$ kubectl get pods limit-test-7cff9996fc-zpjps -o=jsonpath='{.spec.containers[0].resources}'
map[]

Kubernetes最酷的一點是你可以跳到系統以外的角度來觀察每個構成部分，所以我們登入到執行Pod的節點，看看Docker是如何執行這個容器的：

$ docker ps | grep busy | cut -d' ' -f1
5c3af3101afb
$ docker inspect 5c3af3101afb -f "{{.HostConfig.Memory}}"
0

這個容器的.HostConfig.Memory域對應了docker run時的--memory引數，0值表示未設定。Docker會對這個值做什麼？為了控制容器程序能夠訪問的記憶體數量，Docker配置了一組control group，或者叫cgroup。Cgroup在2008年1月時合併到Linux 2.6.24版本的核心。它是一個很重要的話題。我們說cgroup是容器的一組用來控制核心如何執行程序的相關屬性集合。針對記憶體、CPU和各種裝置都有對應的cgroup。Cgroup是具有層級的，這意味著每個cgroup擁有一個它可以繼承屬性的父親，往上一直直到系統啟動時建立的root cgroup。

Cgroup可以通過/proc和/sys偽檔案系統輕鬆檢視到，所以檢查容器如何配置記憶體的cgroup就很簡單了。在容器的Pid namespace裡，根程序的pid為1，但是namespace以外它呈現的是系統級pid，我們可以用來查詢它的cgroups：

$ ps ax | grep /bin/sh
   9513 ?        Ss     0:00 /bin/sh -c while true; do sleep 2; done
$ sudo cat /proc/9513/cgroup
...
6:memory:/kubepods/burstable/podfbc202d3-da21-11e8-ab5e-42010a80014b/0a1b22ec1361a97c3511db37a4bae932d41b22264e5b97611748f8b662312574

我列出了記憶體cgroup，這正是我們所關注的。你在路徑裡可以看到前面提到的cgroup層級。一些比較重要的點是：首先，這個路徑是以kubepods開始的cgroup，所以我們的程序繼承了這個group的每個屬性，還有burstable的屬性（Kubernetes將Pod設定為burstable QoS類別）和一組用於審計的Pod表示。最後一段路徑是我們程序實際使用的cgroup。我們可以把它追加到/sys/fs/cgroups/memory後面檢視更多資訊：

$ ls -l /sys/fs/cgroup/memory/kubepods/burstable/podfbc202d3-da21-11e8-ab5e-42010a80014b/0a1b22ec1361a97c3511db37a4bae932d41b22264e5b97611748f8b662312574
...
-rw-r--r-- 1 root root 0 Oct 27 19:53 memory.limit_in_bytes
-rw-r--r-- 1 root root 0 Oct 27 19:53 memory.soft_limit_in_bytes

再一次，我只列出了我們所關心的記錄。我們暫時不關注memory.soft_limit_in_bytes，而將重點轉移到memory.limit_in_bytes屬性，它設定了記憶體限制。它等價於Docker命令中的--memory引數，也就是Kubernetes裡的記憶體資源限制。我們看看：

$ sudo cat /sys/fs/cgroup/memory/kubepods/burstable/podfbc202d3-da21-11e8-ab5e-42010a80014b/0a1b22ec1361a97c3511db37a4bae932d41b22264e5b97611748f8b662312574/memory.limit_in_bytes
9223372036854771712

這是沒有設定資源限制時我的節點上顯示的情況。這裡有對它的一個簡單的解釋(https://unix.stackexchange.com/questions/420906/what-is-the-value-for-the-cgroups-limit-in-bytes-if-the-memory-is-not-restricte)。 所以我們看到如果沒有在Kubernetes裡設定記憶體限制的話，會導致Docker設定HostConfig.Memory值為0，並進一步導致容器程序被放置在預設值為”no limit”的memory.limit_in_bytes記憶體cgroup下。我們現在建立使用100MiB記憶體限制的Pod：

$ kubectl run limit-test --image=busybox --limits "memory=100Mi" --command -- /bin/sh -c "while true; do sleep 2; done"
deployment.apps "limit-test" created

我們再一次使用kubectl驗證我們的資源配置：

$ kubectl get pods limit-test-5f5c7dc87d-8qtdx -o=jsonpath='{.spec.containers[0].resources}'
map[limits:map[memory:100Mi] requests:map[memory:100Mi]]

你會注意到除了我們設定的limits外，Pod還增加了requests。當你設定limits而沒有設定requests時，Kubernetes預設讓requests等於limits。如果你從排程器的角度看這是非常有意義的。我會在下面進一步討論requests。當這個Pod啟動後，我們可以看到Docker如何配置的容器以及這個程序的記憶體cgroup：

$ docker ps | grep busy | cut -d' ' -f1
8fec6c7b6119
$ docker inspect 8fec6c7b6119 --format '{{.HostConfig.Memory}}'
104857600
$ ps ax | grep /bin/sh
   29532 ?      Ss     0:00 /bin/sh -c while true; do sleep 2; done
$ sudo cat /proc/29532/cgroup
...
6:memory:/kubepods/burstable/pod88f89108-daf7-11e8-b1e1-42010a800070/8fec6c7b61190e74cd9f88286181dd5fa3bbf9cf33c947574eb61462bc254d11
$ sudo cat /sys/fs/cgroup/memory/kubepods/burstable/pod88f89108-daf7-11e8-b1e1-42010a800070/8fec6c7b61190e74cd9f88286181dd5fa3bbf9cf33c947574eb61462bc254d11/memory.limit_in_bytes
104857600

正如你所見，Docker基於我們的containerSpec正確地設定了這個程序的記憶體cgroup。但是這對於執行時意味著什麼？Linux記憶體管理是一個複雜的話題，Kubernetes工程師需要知道的是：當一個宿主機遇到了記憶體資源壓力時，核心可能會有選擇性地殺死程序。如果一個使用了多於限制記憶體的程序會有更高几率被殺死。因為Kubernetes的任務是儘可能多地向這些節點上安排Pod，這會導致節點記憶體壓力異常。如果你的容器使用了過多記憶體，那麼它很可能會被oom-killed。如果Docker收到了核心的通知，Kubernetes會找到這個容器並依據設定嘗試重啟這個Pod。

所以Kubernetes預設建立的記憶體requests是什麼？擁有一個100MiB的記憶體請求會影響到cgroup？可能它設定了我們之前看到的memory.soft_limit_in_bytes？讓我們看看：

$ sudo cat /sys/fs/cgroup/memory/kubepods/burstable/pod88f89108-daf7-11e8-b1e1-42010a800070/8fec6c7b61190e74cd9f88286181dd5fa3bbf9cf33c947574eb61462bc254d11/memory.soft_limit_in_bytes
9223372036854771712

你可以看到軟限制仍然被設定為預設值“no limit”。即使Docker支援通過引數--memory-reservation進行設定，但Kubernetes並不支援這個引數。這是否意味著為你的容器指定記憶體requests並不重要？不，不是的。requests要比limits更重要。limits告訴Linux核心什麼時候你的程序可以為了清理空間而被殺死。requests幫助Kubernetes排程找到合適的節點執行Pod。如果不設定它們，或者設定得非常低，那麼可能會有不好的影響。

例如，假設你沒有配置記憶體requests來執行Pod，而配置了一個較高的limits。正如我們所知道的Kubernetes預設會把requests的值指向limits，如果沒有合適的資源的節點的話，Pod可能會排程失敗，即使它實際需要的資源並沒有那麼多。另一方面，如果你運行了一個配置了較低requests值的Pod，你其實是在鼓勵核心oom-kill掉它。為什麼？假設你的Pod通常使用100MiB記憶體，你卻只為它配置了50MiB記憶體requests。如果你有一個擁有75MiB記憶體空間的節點，那麼這個Pod會被排程到這個節點。當Pod記憶體消耗擴大到100MiB時，會讓這個節點壓力變大，這個時候核心可能會選擇殺掉你的程序。所以我們要正確配置Pod的記憶體requests和limits。

希望這篇文章能夠幫助說明Kubernetes容器記憶體限制是如何設定和實現的，以及為什麼你需要正確設定這些值。如果你為Kubernetes提供了它所需要的足夠資訊，它可以智慧地排程你的任務並最大化使用你的雲端計算資源。

CPU限制

CPU 資源限制比記憶體資源限制更復雜，原因將在下文詳述。幸運的是 CPU 資源限制和記憶體資源限制一樣都是由 cgroup 控制的，上文中提到的思路和工具在這裡同樣適用，我們只需要關注他們的不同點就行了。首先，讓我們將 CPU 資源限制新增到之前示例中的 yaml：

resources:
  requests:
    memory: 50Mi
    cpu: 50m
  limits:
    memory: 100Mi
    cpu: 100m

單位字尾 m 表示千分之一核，也就是說 1 Core = 1000m。因此該資源物件指定容器程序需要 50/1000 核（5%）才能被排程，並且允許最多使用 100/1000 核（10%）。同樣，2000m 表示兩個完整的 CPU 核心，你也可以寫成 2 或者 2.0。為了瞭解 Docker 和 cgroup 如何使用這些值來控制容器，我們首先建立一個只配置了 CPU requests 的 Pod：

$ kubectl run limit-test --image=busybox --requests "cpu=50m" --command -- /bin/sh -c "while true; do sleep 2; done"
deployment.apps "limit-test" created

通過 kubectl 命令我們可以驗證這個 Pod 配置了 50m 的 CPU requests：

$ kubectl get pods limit-test-5b4c495556-p2xkr -o=jsonpath='{.spec.containers[0].resources}'
map[requests:map[cpu:50m]]

我們還可以看到 Docker 為容器配置了相同的資源限制：

$ docker ps | grep busy | cut -d' ' -f1
f2321226620e

$ docker inspect f2321226620e --format '{{.HostConfig.CpuShares}}'
51

這裡顯示的為什麼是 51，而不是 50？這是因為 Linux cgroup 和 Docker 都將 CPU 核心數分成了 1024 個時間片（shares），而 Kubernetes 將它分成了 1000 個 shares。
shares 用來設定 CPU 的相對值，並且是針對所有的 CPU（核心），預設值是 1024，假如系統中有兩個 cgroup，分別是 A 和 B，A 的 shares 值是 1024，B 的 shares 值是 512，那麼 A 將獲得 1024/(1204+512)=66% 的 CPU 資源，而 B 將獲得 33% 的 CPU 資源。

shares 有兩個特點：

  1. 如果 A 不忙，沒有使用到 66% 的 CPU 時間，那麼剩餘的 CPU 時間將會被系統分配給 B，即 B 的 CPU 使用率可以超過 33%。
  2. 如果添加了一個新的 cgroup C，且它的 shares 值是 1024，那麼 A 的限額變成了 1024/(1204+512+1024)=40%，B 的變成了 20%。

從上面兩個特點可以看出：

在閒的時候，shares 基本上不起作用，只有在 CPU 忙的時候起作用，這是一個優點。
由於 shares 是一個絕對值，需要和其它 cgroup 的值進行比較才能得到自己的相對限額，而在一個部署很多容器的機器上，cgroup 的數量是變化的，所以這個限額也是變化的，自己設定了一個高的值，但別人可能設定了一個更高的值，所以這個功能沒法精確的控制 CPU 使用率。

與配置記憶體資源限制時 Docker 配置容器程序的記憶體 cgroup 的方式相同，設定 CPU 資源限制時 Docker 會配置容器程序的 cpu,cpuacct cgroup：

$ ps ax | grep /bin/sh
   60554 ?      Ss     0:00 /bin/sh -c while true; do sleep 2; done

$ sudo cat /proc/60554/cgroup
...
4:cpu,cpuacct:/kubepods/burstable/pode12b33b1-db07-11e8-b1e1-42010a800070/3be263e7a8372b12d2f8f8f9b4251f110b79c2a3bb9e6857b2f1473e640e8e75

$ ls -l /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pode12b33b1-db07-11e8-b1e1-42010a800070/3be263e7a8372b12d2f8f8f9b4251f110b79c2a3bb9e6857b2f1473e640e8e75
total 0
drwxr-xr-x 2 root root 0 Oct 28 23:19 .
drwxr-xr-x 4 root root 0 Oct 28 23:19 ..
...
-rw-r--r-- 1 root root 0 Oct 28 23:19 cpu.shares

Docker 容器的 HostConfig.CpuShares 屬性對映到 cgroup 的 cpu.shares 屬性，可以驗證一下：

$ sudo cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/podb5c03ddf-db10-11e8-b1e1-42010a800070/64b5f1b636dafe6635ddd321c5b36854a8add51931c7117025a694281fb11444/cpu.shares
51

你可能會很驚訝，設定了 CPU requests 竟然會把值傳播到 cgroup，而在上一篇文章中我們設定記憶體 requests 時並沒有將值傳播到 cgroup。這是因為記憶體的 soft limit 核心特性對 Kubernetes 不起作用，而設定了 cpu.shares 卻對 Kubernetes 很有用。後面我會詳細討論為什麼會這樣。現在讓我們先看看設定 CPU limits 時會發生什麼：

$ kubectl run limit-test --image=busybox --requests "cpu=50m" --limits "cpu=100m" --command -- /bin/sh -c "while true; do
sleep 2; done"
deployment.apps "limit-test" created

再一次使用 kubectl 驗證我們的資源配置：

$ kubectl get pods limit-test-5b4fb64549-qpd4n -o=jsonpath='{.spec.containers[0].resources}'
map[limits:map[cpu:100m] requests:map[cpu:50m]]

檢視對應的 Docker 容器的配置：

$ docker ps | grep busy | cut -d' ' -f1
f2321226620e
$ docker inspect 472abbce32a5 --format '{{.HostConfig.CpuShares}} {{.HostConfig.CpuQuota}} {{.HostConfig.CpuPeriod}}'
51 10000 100000

可以明顯看出，CPU requests 對應於 Docker 容器的 HostConfig.CpuShares 屬性。而 CPU limits 就不太明顯了，它由兩個屬性控制：HostConfig.CpuPeriod 和 HostConfig.CpuQuota。Docker 容器中的這兩個屬性又會對映到程序的 cpu,couacct cgroup 的另外兩個屬性：cpu.cfs_period_us 和 cpu.cfs_quota_us。我們來看一下：

$ sudo cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod2f1b50b6-db13-11e8-b1e1-42010a800070/f0845c65c3073e0b7b0b95ce0c1eb27f69d12b1fe2382b50096c4b59e78cdf71/cpu.cfs_period_us
100000

$ sudo cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod2f1b50b6-db13-11e8-b1e1-42010a800070/f0845c65c3073e0b7b0b95ce0c1eb27f69d12b1fe2382b50096c4b59e78cdf71/cpu.cfs_quota_us
10000

如我所說，這些值與容器配置中指定的值相同。但是這兩個屬性的值是如何從我們在 Pod 中設定的 100m cpu limits 得出的呢，他們是如何實現該 limits 的呢？這是因為 cpu requests 和 cpu limits 是使用兩個獨立的控制系統來實現的。Requests 使用的是 cpu shares 系統，cpu shares 將每個 CPU 核心劃分為 1024 個時間片，並保證每個程序將獲得固定比例份額的時間片。如果總共有 1024 個時間片，並且兩個程序中的每一個都將 cpu.shares 設定為 512，那麼它們將分別獲得大約一半的 CPU 可用時間。但 cpu shares 系統無法精確控制 CPU 使用率的上限，如果一個程序沒有設定 shares，則另一個程序可用自由使用 CPU 資源。

大約在 2010 年左右，谷歌團隊和其他一部分人注意到了這個問題。為了解決這個問題，後來在 linux 核心中增加了第二個功能更強大的控制系統：CPU 頻寬控制組。頻寬控制組定義了一個 週期，通常為 1/10 秒（即 100000 微秒）。還定義了一個 配額，表示允許程序在設定的週期長度內所能使用的 CPU 時間數，兩個檔案配合起來設定CPU的使用上限。兩個檔案的單位都是微秒（us），cfs_period_us 的取值範圍為 1 毫秒（ms）到 1 秒（s），cfs_quota_us 的取值大於 1ms 即可，如果 cfs_quota_us 的值為 -1（預設值），表示不受 CPU 時間的限制。

下面是幾個例子：

# 1.限制只能使用1個CPU（每250ms能使用250ms的CPU時間）
$ echo 250000 > cpu.cfs_quota_us /* quota = 250ms */
$ echo 250000 > cpu.cfs_period_us /* period = 250ms */

# 2.限制使用2個CPU（核心）（每500ms能使用1000ms的CPU時間，即使用兩個核心）
$ echo 1000000 > cpu.cfs_quota_us /* quota = 1000ms */
$ echo 500000 > cpu.cfs_period_us /* period = 500ms */

# 3.限制使用1個CPU的20%（每50ms能使用10ms的CPU時間，即使用一個CPU核心的20%）
$ echo 10000 > cpu.cfs_quota_us /* quota = 10ms */
$ echo 50000 > cpu.cfs_period_us /* period = 50ms */

在本例中我們將 Pod 的 cpu limits 設定為 100m，這表示 100/1000 個 CPU 核心，即 100000 微秒的 CPU 時間週期中的 10000。所以該 limits 翻譯到 cpu,cpuacct cgroup 中被設定為 cpu.cfs_period_us=100000 和 cpu.cfs_quota_us=10000。順便說一下，其中的 cfs 代表 Completely Fair Scheduler（絕對公平排程），這是 Linux 系統中預設的 CPU 排程演算法。還有一個實時排程演算法，它也有自己相應的配額值。

現在讓我們來總結一下：

  • 在 Kubernetes 中設定的 cpu requests 最終會被 cgroup 設定為 cpu.shares 屬性的值， cpu limits 會被頻寬控制組設定為 cpu.cfs_period_us 和 cpu.cfs_quota_us 屬性的值。與記憶體一樣，cpu requests 主要用於在排程時通知排程器節點上至少需要多少個 cpu shares 才可以被排程。
  • 與 記憶體 requests 不同，設定了 cpu requests 會在 cgroup 中設定一個屬性，以確保核心會將該數量的 shares 分配給程序。
  • cpu limits 與 記憶體 limits 也有所不同。如果容器程序使用的記憶體資源超過了記憶體使用限制，那麼該程序將會成為 oom-killing 的候選者。但是容器程序基本上永遠不能超過設定的 CPU 配額，所以容器永遠不會因為嘗試使用比分配的更多的 CPU 時間而被驅逐。系統會在排程程式中強制進行 CPU 資源限制，以確保程序不會超過這個限制。

如果你沒有在容器中設定這些屬性，或將他們設定為不準確的值，會發生什麼呢？與記憶體一樣，如果只設置了 limits 而沒有設定 requests，Kubernetes 會將 CPU 的 requests 設定為 與 limits 的值一樣。如果你對你的工作負載所需要的 CPU 時間瞭如指掌，那再好不過了。如果只設置了 CPU requests 卻沒有設定 CPU limits 會怎麼樣呢？這種情況下，Kubernetes 會確保該 Pod 被排程到合適的節點，並且該節點的核心會確保節點上的可用 cpu shares 大於 Pod 請求的 cpu shares，但是你的程序不會被阻止使用超過所請求的 CPU 數量。既不設定 requests 也不設定 limits 是最糟糕的情況：排程程式不知道容器需要什麼，並且程序對 cpu shares 的使用是無限制的，這可能會對 node 產生一些負面影響。

最後我還想告訴你們的是：為每個 pod 都手動配置這些引數是挺麻煩的事情，kubernetes 提供了 LimitRange 資源，可以讓我們配置某個 namespace 預設的 request 和 limit 值。

預設限制

通過上文的討論大家已經知道了忽略資源限制會對 Pod 產生負面影響，因此你可能會想，如果能夠配置某個 namespace 預設的 request 和 limit 值就好了，這樣每次建立新 Pod 都會預設加上這些限制。Kubernetes 允許我們通過 LimitRange 資源對每個名稱空間設定資源限制。要建立預設的資源限制，需要在對應的名稱空間中建立一個 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

這裡的幾個欄位可能會讓你們有些困惑，我拆開來給你們分析一下。

  • limits 欄位下面的 default 欄位表示每個 Pod 的預設的 limits 配置，所以任何沒有分配資源的 limits 的 Pod 都會被自動分配 100Mi limits 的記憶體和 100m limits 的 CPU。
  • defaultRequest 欄位表示每個 Pod 的預設 requests 配置，所以任何沒有分配資源的 requests 的 Pod 都會被自動分配 50Mi requests 的記憶體和 50m requests 的 CPU。
  • max 和 min 欄位比較特殊，如果設定了這兩個欄位，那麼只要這個名稱空間中的 Pod 設定的 limits 和 requests 超過了這個上限和下限，就不會允許這個 Pod 被建立。我暫時還沒有發現這兩個欄位的用途，如果你知道，歡迎在留言告訴我。
  • LimitRange 中設定的預設值最後由 Kubernetes 中的准入控制器 LimitRanger 外掛來實現。准入控制器由一系列外掛組成，它會在 API 接收物件之後建立 Pod 之前對 Pod 的 Spec - 欄位進行修改。對於 LimitRanger 外掛來說，它會檢查每個 Pod 是否設定了 limits 和 requests，如果沒有設定，就給它配置 LimitRange 中設定的預設值。通過檢查 Pod 中的 annotations 註釋，你可以看到 LimitRanger 外掛已經在你的 Pod 中設定了預設值。例如：
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/limit-ranger: 'LimitRanger plugin set: cpu request for container
      limit-test'
  name: limit-test-859d78bc65-g6657
  namespace: default
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - while true; do sleep 2; done
    image: busybox
    imagePullPolicy: Always
    name: limit-test
    resources:
      requests:
        cpu: 100m

以上就是我對 Kubernetes 資源限制的全部見解，希望能對你有所幫助。如果你想了解更多關於 Kubernetes 中資源的 limits 和 requests、以及 linux cgroup 和記憶體管理的更多詳細資訊，可以檢視我在文末提供的參考連結。

參考文件

相關推薦

深入理解K8s資源限制[轉

寫在前面 當我開始大範圍使用Kubernetes的時候，我開始考慮一個我做實驗時沒有遇到的問題：當叢集裡的節點沒有足夠資源的時

深入理解Kubernetes資源限制：內存

如何實現 遇到 讓我 失敗 我會 當我 關註 壓力 視角 寫在前面當我開始大範圍使用Kubernetes的時候，我開始考慮一個我做實驗時沒有遇到的問題：當集群裏的節點沒有足夠資源的時候，Pod會卡在Pending狀態。你是沒有辦法給節點增加CPU或者內存的，那麽你該怎麽做才

深入理解Kubernetes資源限制：CPU

運行時 man 們的 資源 RoCE 技術 pod 帶寬控制 調度 寫在前面在上一篇關於Kubernetes資源限制的文章我們討論了如何通過ResourceRequirements設置Pod中容器內存限制，以及容器運行時是如何利用Linux Cgroups實現這些限制的。也

深入理解名稱空間【轉】

（轉自：https://blog.csdn.net/LF_2016/article/details/51930792?utm_source=blogxgwz1） 一、為什麼使用名稱空間   一個大型的工程往往是由若干個人獨立完成的，不同的人分別完成不同的部分，最後再組合成一個

深入理解HTTP協議（轉） 瀏覽器和伺服器如何通訊(HTTP協議)

          http協議學習系列 1. 基礎概念篇 1.1 介紹   HTTP是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫。它的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet En

深入理解HTTP協議（轉） 瀏覽器和伺服器如何通訊(HTTP協議)

          http協議學習系列 1. 基礎概念篇 1.1 介紹   HTTP是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫。它的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組

深入理解HTTP協議（轉）

http協議學習系列 1. 基礎概念篇 1.1 介紹   HTTP是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫。它的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組IETF（Inter

深入理解k8s中的訪問控制（認證、鑑權、審計）流程

Kubernetes自身並沒有使用者管理能力，無法像操作Pod一樣，通過API的方式建立/刪除一個使用者例項，也無法在etcd中找到使用者對應的儲存物件。 在Kubernetes的訪問控制流程中，使用者模型是通過請求方的訪問控制憑證（如kubectl使用的kube-config中的證書、Pod中引入的Se

深入理解k8s排程器與排程框架核心原始碼

k8s排程器kube-scheduler的核心實現在pkg/scheduler下     algorithmprovider：排程演算法的註冊與獲取功能，核心資料結構是一個字典類的結構     apis：k8s叢集中的資源版本相關

(轉存 作者未知)深入理解HTML協議

期望 intern 屬於 公告欄 機制 被拒 定向 圖片 工具欄 深入理解HTML協議 http協議學 習系列 1. 基礎概念篇 1.1 介紹 HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。它的發展是萬維網協會（World

(轉)final關鍵字的深入理解

多線程 body error app nds ann this tar order 轉自http://www.importnew.com/7553.html Java中的final關鍵字非常重要，它可以應用於類、方法以及變量。這篇文章中我將帶你看看什麽是final關鍵字？將

深入理解javascript原型和閉包（轉）

原型鏈 面向 type www. 作用域 url tle das 經歷 深入理解javascript原型和閉包（完結） 說明： 　　該教程繞開了javascript的一些基本的語法知識，直接講解javascript中最難理解的兩個部分，也是和其他主流面向對

《深入理解計算機系統》關於csapp.h和csapp.c的編譯問題(轉)

系統 文件中 class net 工作 inux 而且 pan div 編譯步驟如下： 1.我的當前工作目錄為/home/sxh2/clinux,目錄下有3個文件inet_aton.c csapp.h csapp.c。 2.編譯csapp.c文件，命令為gcc -c csa

【轉】深入理解margin

盒模型 mbed 推理 日誌 onf cap limited textarea 效果 由淺入深漫談margin屬性 2007-3-18 上午 - HTML/CSS/XML/XSL - CSS - margin margin 在中文中我們翻譯成外邊距或者外補白（

轉 node.js裏面的http模塊深入理解

abi 處理 -h image -1 dex 比較 nds highlight 問題1：HTTP服務繼承了TCP服務模型，是從connection為單位的服務到以request為單位的服務的封裝，那麽request事件何時觸發? 註意：在開啟keepalive後，一個TCP

深入理解磁盤文件系統之inode（轉）

連續 blog 通過 lan 內容 打開 剩余空間 最大 .html 一、inode是什麽？ 理解inode，要從文件儲存說起。 文件儲存在硬盤上，硬盤的最小存儲單位叫做"扇區"（Sector）。每個扇區儲存512字節（相當於0.5KB）。 操作系統讀取硬盤的時候，不會

轉：深入理解Java G1垃圾收集器

線程數 hot 原因 重要 特性 賦值 圖標 參數 堆內存 java垃圾收集器的歷史 第一階段，Serial（串行）收集器 在jdk1.3.1之前，java虛擬機僅僅能使用Serial收集器。 Serial收集器是一個單線程的收集器，但它的“單線程”的意義並不僅僅是說明它只

javascript深入理解js閉包（轉）

erro 對象 anon 無法找到 否則 src 興趣 名稱 如圖所示 javascript深入理解js閉包 轉載 2010-07-03 作者： 我要評論 閉包（closure）是Javascript語言的一個難點，也是它的特色，很多高級應用都要依靠閉包

深入理解並發/並行，阻塞/非阻塞，同步/異步【轉】

非阻塞 n) 做的 耗時 非阻塞socket 衣服 時間片輪轉 輪轉 理解 1、阻塞，非阻塞 首先，阻塞這個詞來自操作系統的線程/進程的狀態模型中，如下圖： 一個線程/進程經歷的5個狀態，創建，就緒，運行，阻塞，終止。各個狀態的轉換條件如上圖，其中有個阻塞狀態，就是

[轉]深入理解ajax系列——頭部消息

ive -type function ike 成功 form type 5.5 ebp 　　每個HTTP請求和響應都會帶有相應的頭部信息，其中有的對開發人員有用。XHR對象提供了操作頭部信息的方法。本文將詳細介紹HTTP的頭部信息 默認信息 　　默認情況下，在發送XHR