【智簡聯接，萬物互聯】華為云·云享專家董昕：Serverless和微服務下， IoT的變革蓄勢待發
870
2025-03-31
Kubernetes手記（19）- 容器資源限制
十九 容器資源限制
在K8s中，運行Pod的節點必須滿足Pod運行所需的基本條件，即有CPU/MEM能滿足Pod運行的所需最小資源限制。
容器沒有內核。默認情況下，容器沒有資源限制，可以使用主機內核調度程序允許的盡可能多的給定資源；如果不對容器資源進行限制，容器之間就會相互影響，一些占用硬件資源較高的容器會吞噬掉所有的硬件資源，從而導致其它容器無硬件資源可用，發生停服狀態。Docker提供了限制內存，CPU或磁盤IO的方法，可以對容器所占用的硬件資源大小以及多少進行限制，我們在使用docker create創建一個容器或者docker run運行一個容器的時候就可以來對此容器的硬件資源做限制。
起始值 requests 最低保障
終結值 limits 硬限制
CPU
1 顆 CPU = 1000 millicores 0.5 顆 CPU = 500 m
內存
Ei、Pi、Ti、Gi、Mi、Ki
19.1 資源限制
清單格式，詳見：kubectl explain pods.spec.Containers.resources
resources
清單示例，node 節點的 CPU 為 12 核心，cpu limits 設置為 1000m 也就是允許
apiVersion: v1 kind: Pod metadata: name: pod-resources-demo namespace: default labels: app: myapp tier: frontend spec: Containers: - name: nginx image: ikubernetes/stress-ng command: - "/usr/bin/stress-ng" #- "-m 1" # 以單線程壓測內存 - "-c 1" # 以單線程壓測CPU - "--metrics-brief" ports: - name: http containerPort: 80 - name: https containerPort: 443 resources: requests: cpu: 1000m # 它決定在預選階段淘汰哪些主機 memory: 512Mi limits: cpu: 1000m # 表示限制容器使用 node 節點的一顆 CPU，無論多少進程，它們最多只能占用 node 節點的可 CPU memory: 512Mi
查看結果
Mem: 855392K used, 139916K free, 10188K shrd, 796K buff, 350368K cached CPU0: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU1: 100% usr 0% sys 0% nic 0% idle 0% io 0% irq 0% sirq # 占滿了一顆 CPU CPU2: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU3: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU4: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU5: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU6: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU7: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU8: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU9: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU10: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq CPU11: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq Load average: 0.84 0.50 0.40 3/485 11 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 6 1 root R 6888 1% 1 8% {stress-ng-cpu} /usr/bin/stress-ng -c 1 --metrics-brief 1 0 root S 6244 1% 10 0% /usr/bin/stress-ng -c 1 --metrics-brief 7 0 root R 1504 0% 11 0% top
19.2 qos 質量管理
GuranteedW
每個容器同時設置了 CPU 和內存的 requests 和 limits，而且 cpu.limits = cpu.requests memory.limits = memory.requests 那么它將優先被調度
Burstable
至少有一個容器設置 CPU 或內存資源的 requests 屬性 那么它將具有中等優先級
BestEffort
沒有任何一個容器設置了 requests 或 limits 屬性 那么它將只有最低優先級，當資源不夠用的時候，這個容器可能最先被終止，以騰出資源來，為 Burstable 和 Guranteed
oom 策略
最先殺死占用量和需求量的比例大的
其他
自己將手記發在：https://github.com/redhatxl/awesome-kubernetes-notes
歡迎一鍵三連
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章