kubernetes /瞭解CPU資源限制

來自多年來在裸機上運行節點/軌應用的應用程序;我曾經能夠在單臺機器上運行儘可能多的應用程序（比如說，數字海洋上的2Go可以輕鬆處理10個應用程序，而無需擔心，基於正確的優化或相當低的通信量）kubernetes /瞭解CPU資源限制

事情是，使用kubernetes，遊戲聽起來完全不同。我已經用2個標準vm（3.75Go）設置了一個「入門」集羣。

分配限制在部署有以下幾點：

 resources: 
      requests: 
      cpu: "64m" 
      memory: "128Mi" 
      limits: 
      cpu: "128m" 
      memory: "256Mi"

然後看到以下內容：

Namespace  Name   CPU Requests CPU Limits Memory Requests Memory Limits 
---------  ----   ------------ ---------- --------------- ------------- 
default   api    64m (6%)  128m (12%) 128Mi (3%)  256Mi (6%)

是什麼6％指的是？

試圖降低CPU限制，喜歡，20Mi ...應用程序啓動（顯然，沒有足夠的資源）。文檔說它是CPU的百分比。那麼，3.75Go機器的20％？那麼這6％來自哪裏呢？

然後將節點池的大小增加到n1-standard-2，同一個pod有效地跨越節點的3％。這聽起來合乎邏輯，但它實際上指的是什麼？

不知道這部分的指標是什麼。

該應用似乎需要大量的啓動內存，但它只使用這個6％的一小部分。然後我覺得我誤解的東西，或者濫用這一切

感謝任何經驗的提示/建議有節點CPU有更好的瞭解最佳

來源

2017-02-19 Ben

如果你也發佈'kubectl describe節點...'的表頭，這將會很有幫助。 – svenwltr

@svenwltr那裏是https://gist.github.com/bbnnt/36c1bfa463a9b03bad7f0ec2c945424c – Ben

CPU的6％，意味着6％（CPU請求）時間是爲這個吊艙預留的。所以它保證它總是能夠達到這個數量的CPU時間。如果仍有CPU時間，它仍然可以突發高達12％（CPU限制）。

這意味着如果限制非常低，您的應用程序將需要更多時間來啓動。因此，liveness probe可能會在準備就緒之前終止該容器，因爲該應用程序耗時過長。要解決此問題，您可能需要增加活動探測的initialDelaySeconds或timeoutSeconds。

另請注意，資源請求和限制定義了您的pod分配的資源量，而不是實際使用量。

資源請求是您的pod保證在節點上獲得的內容。這意味着所請求資源的總和不得高於該節點上的CPU /內存總量。
資源限制是允許您使用pod的上限。這意味着這些資源的總和可以高於實際可用的CPU /內存。

因此，百分比會告訴您在pod分配的資源總量中有多少CPU和內存。

鏈接到文檔：https://kubernetes.io/docs/user-guide/compute-resources/

其他一些值得注意的事項：

如果您的吊艙使用比限制規定更多的內存，它就會OOMKilled（內存不足）。
如果你的pod使用比請求中定義的內存更多的內存，並且節點運行我們的內存，那麼該POD可能會獲得OOMKilled，以保證其他的POD能夠存活，而使用該請求的內存少於其請求的內存。
如果您的應用程序需要比請求更多的CPU，它可以突破最大限度。
你的pod永遠不會被殺死，因爲它使用了太多的CPU。

來源

2017-02-19 12:28:44 svenwltr

我本來可以更準確。在所示的例子中，CPU的6％，這有效地意味着什麼？關於碼頭容器和運行應用程序，它是如何涉及的？如上所述，我降低到分配給cpu試用。它並不是很專業（正如我預料的那樣），但是它一直在重新啓動而沒有有效地提升 – Ben

這是我聽起來非常棘手的地方。只是再次降低了CPU（從64到20Mi，限制爲40Mi）。 *沒有oomkilled *。它只是重新啓動，從來沒有準備好。再次將它增加到我的問題中顯示的值，就像它馬上準備好的魅力一樣。這對我來說是雙倍的偏見，因爲同樣的情況發生在目前的 – Ben

的一半大小的機器上，除此之外，我如何評估應用程序的需求，然後相應地分配CPU？目前我只是不明白它與何處有關 – Ben

按照docs，CPU請求（和限制），總是存在吊艙被調度上的節點上可用的CPU內核的級分（用resources.requests.cpu的"1"含義預留用於一個吊艙僅僅一個CPU核的）。分數是允許的，因此CPU請求"0.5"將爲一個吊艙保留一半的CPU。

爲了方便起見，Kubernetes允許在millicores指定CPU的資源請求/限制：

表達0.1相當於表達100m，其可以被讀作「百個millicpu」（一些可能會說「一百毫克」，而在談到Kubernetes時，這被理解爲同樣的意思）。帶有小數點的請求（如0.1）會被API轉換爲100m，並且不允許使用精度高於1m的精度。

正如在其他答案中已經提到的，資源請求是保證。這意味着Kubernetes將按照所有請求的總和不會超過節點上實際可用資源數量的方式安排窗格。

因此，通過在您的部署中請求64m CPU時間，您實際上請求節點的一個CPU核心時間的64/1000 = 0,064 = 6.4％。這就是你的6％來自哪裏。當升級到具有更多CPU核心的虛擬機時，可用CPU資源的數量會增加，因此在具有兩個可用CPU核心的計算機上，CPU時間的6.4％的請求將佔用CPU的3.2％時間爲兩個 CPU。

來源

2017-02-19 13:37:34 helmbert

kubernetes /瞭解CPU資源限制

回答

相關問題