kubernets之帶有limit的資源

一  pod中容器的limits屬性的做用

 

　　1.1  建立一個帶有資源limits的pod

apiVersion: v1
kind: Pod
metadata:
  name: limited-pod
spec:
  containers:
  - image: busybox
    command: ["dd","if=/dev/zero","of=/dev/null"]
    name: main
    resources:
      limits:
        cpu: 1
        memory: 20Mi

• 限制了cpu使用的時間，可使用cpu的全部運行時間
• 限制了內存只能有20Mi
• 與requests資源不一樣limits資源能夠超賣，即節點上面全部的pod的limits屬性之和相加起來能夠大於等於100

      1.2  當容器內的應用超過這個使用配額的時候會發生什麼？

　　　　當容器運行的應用超過這個配額的時候，kubernetes會將這個pod殺掉，而且當這個pod的重啓策略是always的時候，第一次重啓以後，接下來他還會繼續重啓，並且第二次重啓的時間比第一次時間間隔要長，而後一直這樣循環往復下去，直達達到300點這個臨界值，以後會一直以這個時間進行重複啓動，並且pod也會一直處於CrashLoopBackOff狀態查詢日誌或者經過時間能夠知道詳細的緣由

　　

 

 

• 這個例子中，容器由於內存不足而被殺死了

　　

　　1.3 容器中的應用是如何看待limits

　　　　在容器中查看內存的時候，顯示的是容器所在節點上面的數量，而容器沒法感知這個限制，任何利用這個信息來決定使用多少應用來講都具備很是不利的影響，在java應用程序中頗有可能會出現OOMkill

　　　　容器內一樣能夠看到全部的全部節點的cpu內核，與內存徹底一致，當在容器的limits上面限制了1，容器裏面查看的時候也會是64，並且應用可以佔用的cpu時間也只能1/64.而且它還不會只在一個cpu上面進行運行，而是會跑滿全部的cpu，這對實際生產簡直是災難，它會佔用大量的內存

　　　　綜上所示，不可以依賴應用程序從系統裏面或者cpu的數量，而是應該經過downwardAPI的形式將CPU限額傳遞到容器並使用這個值，或者也能夠經過cgroup系統直接獲取配置的CPU限制，查看下面所示文件

• /sys/fs/cgroup/cpu/cpu.cfs_quota_us
• /sys/fs/cgroup/cpu/cpu.cfs_period_us