這篇文章主要講解了“什么是K8s資源限制”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“什么是K8s資源限制”吧！
10年積累的做網(wǎng)站、成都網(wǎng)站建設經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設流程，更有永吉免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
當我開始大范圍使用Kubernetes的時候，我開始考慮一個我做實驗時沒有遇到的問題：當集群里的節(jié)點沒有足夠資源的時候，Pod會卡在Pending狀態(tài)。你是沒有辦法給節(jié)點增加CPU或者內(nèi)存的，那么你該怎么做才能將這個Pod從這個節(jié)點拿走？最簡單的辦法是添加另一個節(jié)點，我承認我總是這么干。最終這個策略無法發(fā)揮出Kubernetes最重要的一個能力：即它優(yōu)化計算資源使用的能力。這些場景里面實際的問題并不是節(jié)點太小，而是我們沒有仔細為Pod計算過資源限制。
資源限制是我們可以向Kubernetes提供的諸多配置之一，它意味著兩點：工作負載運行需要哪些資源；最多允許消費多少資源。第一點對于調(diào)度器而言十分重要，因為它要以此選擇合適的節(jié)點。第二點對于Kubelet非常重要，每個節(jié)點上的守護進程Kubelet負責Pod的運行健康狀態(tài)。大多數(shù)本文的讀者可能對資源限制有一定的了解，實際上這里面有很多有趣的細節(jié)。在這個系列的兩篇文章中我會先仔細分析內(nèi)存資源限制，然后第二篇文章中分析CPU資源限制。
資源限制是通過每個容器containerSpec的resources字段進行設置的，它是v1版本的ResourceRequirements類型的API對象。每個指定了”limits”和”requests”的對象都可以控制對應的資源。目前只有CPU和內(nèi)存兩種資源。第三種資源類型，持久化存儲仍然是beta版本，我會在以后的博客里進行分析。大多數(shù)情況下，deployment、statefulset、daemonset的定義里都包含了podSpec和多個containerSpec。這里有個完整的v1資源對象的yaml格式配置：
resources: requests: cpu: 50m memory: 50Mi limits: cpu: 100m memory: 100Mi |
這個對象可以這么理解：這個容器通常情況下，需要5%的CPU時間和50MiB的內(nèi)存（requests），同時最多允許它使用10%的CPU時間和100MiB的內(nèi)存（limits）。我會對requests和limits的區(qū)別做進一步講解，但是一般來說，在調(diào)度的時候requests比較重要，在運行時limits比較重要。盡管資源限制配置在每個容器上，你可以認為Pod的資源限制就是它里面容器的資源限制之和，我們可以從系統(tǒng)的視角觀察到這種關系。
通常情況下分析內(nèi)存要比分析CPU簡單一些，所以我從這里開始著手。我的一個目標是給大家展示內(nèi)存在系統(tǒng)中是如何實現(xiàn)的，也就是Kubernetes對容器運行時（docker/containerd）所做的工作，容器運行時對Linux內(nèi)核所做的工作。從分析內(nèi)存資源限制開始也為后面分析CPU打好了基礎。首先，讓我們回顧一下前面的例子：
resources: requests: memory: 50Mi limits: memory: 100Mi |
單位后綴Mi表示的是MiB，所以這個資源對象定義了這個容器需要50MiB并且最多能使用100MiB的內(nèi)存。當然還有其他單位可以進行表示。為了了解如何用這些值是來控制容器進程，我們首先創(chuàng)建一個沒有配置內(nèi)存限制的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最酷的一點是你可以跳到系統(tǒng)以外的角度來觀察每個構成部分，所以我們登錄到運行Pod的節(jié)點，看看Docker是如何運行這個容器的：
$ docker ps | grep busy | cut -d' ' -f1
5c3af3101afb
$ docker inspect 5c3af3101afb -f "{{.HostConfig.Memory}}"
0 |
這個容器的.HostConfig.Memory域對應了docker run時的--memory參數(shù)，0值表示未設定。Docker會對這個值做什么？為了控制容器進程能夠訪問的內(nèi)存數(shù)量，Docker配置了一組control group，或者叫cgroup。Cgroup在2008年1月時合并到Linux 2.6.24版本的內(nèi)核。它是一個很重要的話題。我們說cgroup是容器的一組用來控制內(nèi)核如何運行進程的相關屬性集合。針對內(nèi)存、CPU和各種設備都有對應的cgroup。Cgroup是具有層級的，這意味著每個cgroup擁有一個它可以繼承屬性的父親，往上一直直到系統(tǒng)啟動時創(chuàng)建的root cgroup。
Cgroup可以通過/proc和/sys偽文件系統(tǒng)輕松查看到，所以檢查容器如何配置內(nèi)存的cgroup就很簡單了。在容器的Pid namespace里，根進程的pid為1，但是namespace以外它呈現(xiàn)的是系統(tǒng)級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 |
我列出了內(nèi)存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屬性，它設置了內(nèi)存限制。它等價于Docker命令中的--memory參數(shù)，也就是Kubernetes里的內(nèi)存資源限制。我們看看：
$ sudo cat /sys/fs/cgroup/memory/kubepods/burstable/podfbc202d3-da21-11e8-ab5e-42010a80014b/0a1b22ec1361a97c3511db37a4bae932d41b22264e5b97611748f8b662312574/memory.limit_in_bytes 9223372036854771712 |
這是沒有設置資源限制時我的節(jié)點上顯示的情況。這里有對它的一個簡單的解釋(https://unix.stackexchange.com/questions/420906/what-is-the-value-for-the-cgroups-limit-in-bytes-if-the-memory-is-not-restricte)。 所以我們看到如果沒有在Kubernetes里設置內(nèi)存限制的話，會導致Docker設置HostConfig.Memory值為0，并進一步導致容器進程被放置在默認值為”no limit”的memory.limit_in_bytes內(nèi)存cgroup下。我們現(xiàn)在創(chuàng)建使用100MiB內(nèi)存限制的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。如果你從調(diào)度器的角度看這是非常有意義的。我會在下面進一步討論requests。當這個Pod啟動后，我們可以看到Docker如何配置的容器以及這個進程的內(nèi)存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正確地設置了這個進程的內(nèi)存cgroup。但是這對于運行時意味著什么？Linux內(nèi)存管理是一個復雜的話題，Kubernetes工程師需要知道的是：當一個宿主機遇到了內(nèi)存資源壓力時，內(nèi)核可能會有選擇性地殺死進程。如果一個使用了多于限制內(nèi)存的進程會有更高幾率被殺死。因為Kubernetes的任務是盡可能多地向這些節(jié)點上安排Pod，這會導致節(jié)點內(nèi)存壓力異常。如果你的容器使用了過多內(nèi)存，那么它很可能會被oom-killed。如果Docker收到了內(nèi)核的通知，Kubernetes會找到這個容器并依據(jù)設置嘗試重啟這個Pod。
所以Kubernetes默認創(chuàng)建的內(nèi)存requests是什么？擁有一個100MiB的內(nèi)存請求會影響到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支持通過參數(shù)--memory-reservation進行設置，但Kubernetes并不支持這個參數(shù)。這是否意味著為你的容器指定內(nèi)存requests并不重要？不，不是的。requests要比limits更重要。limits告訴Linux內(nèi)核什么時候你的進程可以為了清理空間而被殺死。requests幫助Kubernetes調(diào)度找到合適的節(jié)點運行Pod。如果不設置它們，或者設置得非常低，那么可能會有不好的影響。
例如，假設你沒有配置內(nèi)存requests來運行Pod，而配置了一個較高的limits。正如我們所知道的Kubernetes默認會把requests的值指向limits，如果沒有合適的資源的節(jié)點的話，Pod可能會調(diào)度失敗，即使它實際需要的資源并沒有那么多。另一方面，如果你運行了一個配置了較低requests值的Pod，你其實是在鼓勵內(nèi)核oom-kill掉它。為什么？假設你的Pod通常使用100MiB內(nèi)存，你卻只為它配置了50MiB內(nèi)存requests。如果你有一個擁有75MiB內(nèi)存空間的節(jié)點，那么這個Pod會被調(diào)度到這個節(jié)點。當Pod內(nèi)存消耗擴大到100MiB時，會讓這個節(jié)點壓力變大，這個時候內(nèi)核可能會選擇殺掉你的進程。所以我們要正確配置Pod的內(nèi)存requests和limits。
希望這篇文章能夠幫助說明Kubernetes容器內(nèi)存限制是如何設置和實現(xiàn)的，以及為什么你需要正確設置這些值。如果你為Kubernetes提供了它所需要的足夠信息，它可以智能地調(diào)度你的任務并最大化使用你的云計算資源。
CPU 資源限制比內(nèi)存資源限制更復雜，原因將在下文詳述。幸運的是 CPU 資源限制和內(nèi)存資源限制一樣都是由 cgroup 控制的，上文中提到的思路和工具在這里同樣適用，我們只需要關注他們的不同點就行了。首先，讓我們將 CPU 資源限制添加到之前示例中的 yaml：
resources: requests: memory: 50Mi cpu: 50m limits: memory: 100Mi cpu: 100m |
單位后綴 m 表示千分之一核，也就是說 1 Core = 1000m。因此該資源對象指定容器進程需要 50/1000 核（5%）才能被調(diào)度，并且允許最多使用 100/1000 核（10%）。同樣，2000m 表示兩個完整的 CPU 核心，你也可以寫成 2 或者 2.0。為了了解 Docker 和 cgroup 如何使用這些值來控制容器，我們首先創(chuàng)建一個只配置了 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 核心數(shù)分成了 1024 個時間片（shares），而 Kubernetes 將它分成了 1000 個 shares。
shares 用來設置 CPU 的相對值，并且是針對所有的 CPU（內(nèi)核），默認值是 1024，假如系統(tǒng)中有兩個 cgroup，分別是 A 和 B，A 的 shares 值是 1024，B 的 shares 值是 512，那么 A 將獲得 1024/(1204+512)=66% 的 CPU 資源，而 B 將獲得 33% 的 CPU 資源。
shares 有兩個特點：
如果 A 不忙，沒有使用到 66% 的 CPU 時間，那么剩余的 CPU 時間將會被系統(tǒng)分配給 B，即 B 的 CPU 使用率可以超過 33%。
如果添加了一個新的 cgroup C，且它的 shares 值是 1024，那么 A 的限額變成了 1024/(1204+512+1024)=40%，B 的變成了 20%。
從上面兩個特點可以看出：
在閑的時候，shares 基本上不起作用，只有在 CPU 忙的時候起作用，這是一個優(yōu)點。
由于 shares 是一個絕對值，需要和其它 cgroup 的值進行比較才能得到自己的相對限額，而在一個部署很多容器的機器上，cgroup 的數(shù)量是變化的，所以這個限額也是變化的，自己設置了一個高的值，但別人可能設置了一個更高的值，所以這個功能沒法精確的控制 CPU 使用率。
與配置內(nèi)存資源限制時 Docker 配置容器進程的內(nèi)存 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，而在上一篇文章中我們設置內(nèi)存 requests 時并沒有將值傳播到 cgroup。這是因為內(nèi)存的 soft limit 內(nèi)核特性對 Kubernetes 不起作用，而設置了 cpu.shares 卻對 Kubernetes 很有用。后面我會詳細討論為什么會這樣。現(xiàn)在讓我們先看看設置 CPU limits 時會發(fā)生什么：
$ 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 得出的呢，他們是如何實現(xiàn)該 limits 的呢？這是因為 cpu requests 和 cpu limits 是使用兩個獨立的控制系統(tǒng)來實現(xiàn)的。Requests 使用的是 cpu shares 系統(tǒng)，cpu shares 將每個 CPU 核心劃分為 1024 個時間片，并保證每個進程將獲得固定比例份額的時間片。如果總共有 1024 個時間片，并且兩個進程中的每一個都將 cpu.shares 設置為 512，那么它們將分別獲得大約一半的 CPU 可用時間。但 cpu shares 系統(tǒng)無法精確控制 CPU 使用率的上限，如果一個進程沒有設置 shares，則另一個進程可用自由使用 CPU 資源。
大約在 2010 年左右，谷歌團隊和其他一部分人注意到了這個問題。為了解決這個問題，后來在 linux 內(nèi)核中增加了第二個功能更強大的控制系統(tǒng)：CPU 帶寬控制組。帶寬控制組定義了一個 周期，通常為 1/10 秒（即 100000 微秒）。還定義了一個 配額，表示允許進程在設置的周期長度內(nèi)所能使用的 CPU 時間數(shù)，兩個文件配合起來設置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（內(nèi)核）（每500ms能使用1000ms的CPU時間，即使用兩個內(nèi)核） $ 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（絕對公平調(diào)度），這是 Linux 系統(tǒng)中默認的 CPU 調(diào)度算法。還有一個實時調(diào)度算法，它也有自己相應的配額值。
現(xiàn)在讓我們來總結一下：
在 Kubernetes 中設置的 cpu requests 最終會被 cgroup 設置為 cpu.shares 屬性的值， cpu limits 會被帶寬控制組設置為 cpu.cfs_period_us 和 cpu.cfs_quota_us 屬性的值。與內(nèi)存一樣，cpu requests 主要用于在調(diào)度時通知調(diào)度器節(jié)點上至少需要多少個 cpu shares 才可以被調(diào)度。
與 內(nèi)存 requests 不同，設置了 cpu requests 會在 cgroup 中設置一個屬性，以確保內(nèi)核會將該數(shù)量的 shares 分配給進程。
cpu limits 與 內(nèi)存 limits 也有所不同。如果容器進程使用的內(nèi)存資源超過了內(nèi)存使用限制，那么該進程將會成為 oom-killing 的候選者。但是容器進程基本上永遠不能超過設置的 CPU 配額，所以容器永遠不會因為嘗試使用比分配的更多的 CPU 時間而被驅逐。系統(tǒng)會在調(diào)度程序中強制進行 CPU 資源限制，以確保進程不會超過這個限制。
如果你沒有在容器中設置這些屬性，或將他們設置為不準確的值，會發(fā)生什么呢？與內(nèi)存一樣，如果只設置了 limits 而沒有設置 requests，Kubernetes 會將 CPU 的 requests 設置為 與 limits 的值一樣。如果你對你的工作負載所需要的 CPU 時間了如指掌，那再好不過了。如果只設置了 CPU requests 卻沒有設置 CPU limits 會怎么樣呢？這種情況下，Kubernetes 會確保該 Pod 被調(diào)度到合適的節(jié)點，并且該節(jié)點的內(nèi)核會確保節(jié)點上的可用 cpu shares 大于 Pod 請求的 cpu shares，但是你的進程不會被阻止使用超過所請求的 CPU 數(shù)量。既不設置 requests 也不設置 limits 是最糟糕的情況：調(diào)度程序不知道容器需要什么，并且進程對 cpu shares 的使用是無限制的，這可能會對 node 產(chǎn)生一些負面影響。
最后我還想告訴你們的是：為每個 pod 都手動配置這些參數(shù)是挺麻煩的事情，kubernetes 提供了 LimitRange 資源，可以讓我們配置某個 namespace 默認的 request 和 limit 值。
通過上文的討論大家已經(jīng)知道了忽略資源限制會對 Pod 產(chǎn)生負面影響，因此你可能會想，如果能夠配置某個 namespace 默認的 request 和 limit 值就好了，這樣每次創(chuàng)建新 Pod 都會默認加上這些限制。Kubernetes 允許我們通過 LimitRange 資源對每個命名空間設置資源限制。要創(chuàng)建默認的資源限制，需要在對應的命名空間中創(chuàng)建一個 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 的內(nèi)存和 100m limits 的 CPU。
defaultRequest 字段表示每個 Pod 的默認 requests 配置，所以任何沒有分配資源的 requests 的 Pod 都會被自動分配 50Mi requests 的內(nèi)存和 50m requests 的 CPU。
max 和 min 字段比較特殊，如果設置了這兩個字段，那么只要這個命名空間中的 Pod 設置的 limits 和 requests 超過了這個上限和下限，就不會允許這個 Pod 被創(chuàng)建。我暫時還沒有發(fā)現(xiàn)這兩個字段的用途，如果你知道，歡迎在留言告訴我。
LimitRange 中設定的默認值最后由 Kubernetes 中的準入控制器 LimitRanger 插件來實現(xiàn)。準入控制器由一系列插件組成，它會在 API 接收對象之后創(chuàng)建 Pod 之前對 Pod 的 Spec - 字段進行修改。對于 LimitRanger 插件來說，它會檢查每個 Pod 是否設置了 limits 和 requests，如果沒有設置，就給它配置 LimitRange 中設定的默認值。通過檢查 Pod 中的 annotations 注釋，你可以看到 LimitRanger 插件已經(jīng)在你的 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 |
感謝各位的閱讀，以上就是“什么是K8s資源限制”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對什么是K8s資源限制這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！
重慶分公司
重慶分公司
