27月XNUMX日 會議 作為「DevOps」部分的一部分，給出了「Kubernetes 中的自動擴展和資源管理」報告。 它討論瞭如何使用 K8s 來確保應用程式的高可用性並確保峰值效能。
按照傳統，我們很高興向您展示 （44 分鐘，比文章豐富得多）和文本形式的主要摘要。 去！
我們逐字分析報告的主題，從最後開始。
Kubernetes
假設我們的主機上有 Docker 容器。 為了什麼？ 為了確保可重複性和隔離性，進而實現簡單且良好的部署，CI/CD。 我們有很多這樣的有貨櫃的車輛。
在這種情況下 Kubernetes 提供了什麼？
- 我們不再考慮這些機器，而是開始使用“雲” 容器集群 或 pod（容器群組）。
- 此外，我們甚至不考慮單一 pod，而是管理更多о更大的群體。 這樣的 進階原語 允許我們說有一個用於運行特定工作負載的模板，這裡是運行它所需的實例數量。 如果我們隨後更改模板，所有實例都會更改。
- 同 聲明式API 我們不是執行一系列特定命令，而是描述由 Kubernetes 創建的「世界結構」（在 YAML 中）。 再說一次：當描述發生變化時，其實際顯示也會發生變化。
資源管理
中央處理器
讓我們在伺服器上運行 nginx、php-fpm 和 mysql。 這些服務實際上會運行更多的進程，每個進程都需要計算資源：
（幻燈片上的數字是“鸚鵡”，每個進程對運算能力的抽象需求）
為了更容易使用它，將進程組合成群組是合乎邏輯的（例如，將所有 nginx 進程合併為一組「nginx」）。 一個簡單而明顯的方法是將每個組放入一個容器中：
要繼續，您需要記住容器是什麼（在 Linux 中）。 它們的出現得益於核心中很久以前就實現的三個關鍵功能： , и 。 其他技術（包括像 Docker 這樣方便的「shell」）促進了進一步的開發：
在報告中，我們只感興趣 小組，因為控制組是容器（Docker等）實現資源管理的功能的一部分。 正如我們所希望的，組合成組的過程是對照組。
讓我們回到這些進程以及進程組的 CPU 需求：
（我再說一遍，所有數字都是資源需求的抽象表達）
同時CPU本身俱有一定的有限資源 （在範例中為 1000），每個人都可能缺乏（所有群體的需求總和是150+850+460=1460）。 在這種情況下會發生什麼？
核心開始分配資源並「公平」地進行，為每個群組提供相同數量的資源。 但在第一種情況下，它們的數量超出了所需的數量（333>150），因此多餘的（333-150=183）仍然保留，這也平均分配在其他兩個容器之間：
結果是：第一個容器有足夠的資源，第二個容器沒有足夠的資源，第三個容器沒有足夠的資源。 這是行動的結果 Linux 中的「誠實」調度程序 - 。 可以使用分配來調整其操作 重量 每個容器。 例如，像這樣：
讓我們來看看第二個容器（php-fpm）資源不足的情況。 所有容器資源在進程之間平均分配。 結果，主進程運作良好，但所有工作進程都變慢了，收到的資料還不到他們需要的一半：
這就是 CFS 調度程序的工作原理。 我們將進一步調用分配給容器的權重 要求。 為什麼會這樣 - 進一步了解。
讓我們從另一面來看整個情況。 如您所知，條條大路通羅馬，對於電腦而言，則通往 CPU。 一個 CPU，許多任務 - 你需要一個紅綠燈。 管理資源最簡單的方法是「紅綠燈」：它們為一個進程提供了固定的 CPU 存取時間，然後是下一個進程，依此類推。
這種方法稱為硬配額 （硬限制）。 讓我們簡單地記住它 限制。 但是，如果將限制分配給所有容器，則會出現一個問題：mysql 正在沿路行駛，在某個時刻它對 CPU 的需求結束，但所有其他進程都被迫等待，直到 CPU 耗盡 閒置的.
讓我們回到Linux核心以及它與CPU的交互作用——整體情況如下：
cgroup 有兩個設定 - 本質上這是兩個簡單的“扭曲”，允許您確定：
- 貨櫃重量（請求）是 股份;
- 用於處理容器任務的總 CPU 時間的百分比（限制）為 分享.
如何測量CPU？
有不同的方法：
- 什麼是 鸚鵡，沒有人知道——你每次都需要談判。
- 興趣 更清楚，但相對而言：50 核伺服器和 4 核伺服器的 20% 是完全不同的東西。
- 您可以使用已經提到的那些 重量，Linux 知道，但它們也是相對的。
- 最適合的選擇是測量計算資源 秒。 那些。 以相對於即時秒數的處理器時間秒數為單位：每 1 實際秒給出 1 秒處理器時間 - 這是一個完整的 CPU 核心。
為了讓說話更容易，他們開始直接測量 核心，這意味著它們與真實的 CPU 時間相同。 由於 Linux 理解權重，但不理解那麼多 CPU 時間/內核，因此需要一種機制來從一個權重轉換為另一個權重。
讓我們考慮一個具有3 個CPU 核心的伺服器的簡單範例，其中三個Pod 將被賦予權重（500、1000 和1500），這些權重可以輕鬆轉換為分配給它們的核心的相應部分（0,5、1 和1,5）。
如果您使用第二台伺服器，其中的核心數量是兩倍 (6)，並在那裡放置相同的 Pod，只需乘以 2（分別為 1、2 和 3）即可輕鬆計算核心的分佈。 但是，當第四個Pod 出現在該伺服器上時，一個重要的時刻發生了，為了方便起見，其權重為3000。它佔用了部分CPU 資源（一半核心），並且對於剩餘的Pod，它們被重新計算（減半）：
Kubernetes 和 CPU 資源
在 Kubernetes 中，CPU 資源通常以 米利亞德拉克斯， IE。 以0,001芯為基重。 （Linux/cgroups 術語中的相同事物稱為 CPU 份額，但更準確地說，1000 毫核 = 1024 個 CPU 份額。） K8s 確保伺服器上放置的 pod 數量不會超過所有 pod 權重總和的 CPU 資源數量。
這是怎麼發生的？ 當您將伺服器新增至 Kubernetes 叢集時，會報告它有多少可用 CPU 核心。 當創建一個新的 Pod 時，Kubernetes 調度程式知道這個 Pod 需要多少個核心。 因此，Pod 將被分配到有足夠核心的伺服器。
如果會發生什麼 沒有 請求已指定（即 Pod 沒有定義所需的核心數量）？ 讓我們先來了解一下 Kubernetes 一般是如何統計資源的。
對於 pod，您可以指定請求（CFS 調度程序）和限制（還記得交通號誌嗎？）：
- 如果指定它們相等，則為 pod 指派一個 QoS 類別 保證。 始終可用的核心數量是有保證的。
- 如果請求小於限制 - QoS 等級 可爆裂的。 那些。 例如，我們期望 pod 始終使用 1 個核心，但該值並不是對其的限制： 有時 pod 可以使用更多（當伺服器有可用資源時）。
- 還有一個 QoS 等級 盡力而為 — 它包括那些未指定請求的 pod。 資源最後才提供給他們。
Память
對於記憶體來說，情況類似，但略有不同——畢竟這些資源的性質不同。 一般來說，類別例如下：
讓我們看看請求在記憶體中是如何實現的。 讓 Pod 駐留在伺服器上，改變記憶體消耗，直到其中一個 Pod 變得太大而耗盡記憶體。 在這種情況下，OOM殺手出現並殺死最大的進程：
這並不總是適合我們，因此可以調節哪些進程對我們很重要並且不應該被殺死。 為此，請使用參數 oom_score_adj.
讓我們回到 CPU 的 QoS 等級，並與決定 pod 記憶體消耗優先權的 oom_score_adj 值進行類比：
- pod 的最低 oom_score_adj 值 - -998 - 意味著這樣的 pod 應該最後被殺死，這 保證.
- 最高的 - 1000 - 是 盡力而為，這樣的豆莢首先被殺死。
- 計算剩餘值（可爆裂的）有一個公式，其本質可以歸結為這樣一個事實：Pod 請求的資源越多，它被殺死的可能性就越小。
第二個「轉折」—— 限制位元組數 - 用於限制。 有了它，一切都變得更簡單：我們只需分配最大的已發行內存量，並且這裡（與CPU不同）不存在如何測量它（內存）的問題。
在總
Kubernetes 中的每個 pod 都是給定的 requests и limits - CPU 和記憶體的參數：
- Kubernetes 調度程式根據請求工作，在伺服器之間分配 Pod；
- 根據所有參數，確定 pod 的 QoS 等級；
- 根據CPU請求計算相對權重；
- CFS調度程序根據CPU請求進行配置；
- OOM Killer根據記憶體請求進行配置；
- 根據 CPU 限製配置「紅綠燈」；
- 根據記憶體限制，為 cgroup 設定限制。
總的來說，這張圖回答了有關 Kubernetes 中資源管理的主要部分如何發生的所有問題。
自動縮放
K8s集群自動縮放器
假設整個叢集已經被佔用，需要建立一個新的 Pod。 雖然 pod 無法出現，但它處於掛起狀態 等待處理。 為了讓它出現，我們可以將一台新伺服器連接到集群或...安裝 cluster-autoscaler，這將為我們完成：從雲端提供者訂購虛擬機器（使用 API 請求）並將其連接到集群，之後將添加pod。
這是 Kubernetes 叢集的自動縮放，效果很好（根據我們的經驗）。 然而，與其他地方一樣，這裡也存在一些細微差別...
只要我們增加簇大小，一切都很好，但是當簇大小增加時會發生什麼？ 開始釋放自己？ 問題在於，遷移 Pod（以釋放主機）在技術上非常困難，而且在資源方面也非常昂貴。 Kubernetes 使用完全不同的方法。
考慮具有 Deployment 的 3 個伺服器的叢集。 它有 6 個 pod：現在每台伺服器有 2 個 pod。 由於某種原因，我們想關閉其中一台伺服器。 為此，我們將使用命令 kubectl drain， 哪個：
- 將禁止向該伺服器發送新的 Pod；
- 將刪除伺服器上現有的 Pod。
由於 Kubernetes 負責維護 pod 的數量（6），因此它只是 將重新創建 它們位於其他節點上，但不在被停用的節點上，因為它已被標記為無法託管新的 Pod。 這是 Kubernetes 的基本機制。
然而，這裡也有一個細微差別。 類似的情況，對於StatefulSet（而不是Deployment），操作會有所不同。 現在我們已經有了一個有狀態的應用程式 - 例如，三個帶有 MongoDB 的 Pod，其中一個存在某種問題（資料已損壞或另一個錯誤導致 Pod 無法正確啟動）。 我們再次決定禁用一台伺服器。 會發生什麼事？
MongoDB的 可以 因為它需要法定人數而死亡：對於三個安裝的集群，至少有兩個必須運行。 然而，這 沒有發生 - 謝謝 Pod 中斷預算。 此參數決定了所需的最小工作 Pod 數量。 知道其中一個 MongoDB Pod 不再工作，並看到為 MongoDB 設定了 PodDisruptionBudget minAvailable: 2，Kubernetes 不會允許你刪除 pod。
底線：為了在叢集釋放時 Pod 的移動（實際上是重新建立）能夠正常運作，有必要設定 PodDisruptionBudget。
水平縮放
讓我們考慮另一種情況。 Kubernetes 中有一個作為 Deployment 運行的應用程式。 使用者流量來到它的 pod（例如，有 XNUMX 個），我們測量其中的某個指標（例如 CPU 負載）。 當負載增加時，我們將其記錄在計劃中，並增加 pod 數量來分發請求。
如今，在 Kubernetes 中，這不需要手動完成：根據測量的負載指標的值配置自動增加/減少 pod 數量。
這裡的主要問題是： 到底要測量什麼 и 如何解釋 獲得的值（用於做出更改 pod 數量的決定）。 你可以測量很多：
如何從技術上做到這一點 - 收集指標等。 ——我在報告中詳細談了 。 選擇最佳參數的主要建議是 實驗!
有 （利用率飽和度與誤差），其意義如下。 擴展（例如 php-fpm）的基礎是什麼？ 基於工人即將耗盡的事實，這是 利用率。 如果工人結束了並且不接受新的連接，這已經是 飽和。 必須測量這兩個參數，並根據這些值進行縮放。
取而代之的是結論
該報告還有一個延續部分：關於垂直擴展以及如何選擇正確的資源。 我將在以後的視頻中討論這一點 - 訂閱，這樣您就不會錯過！
影片和幻燈片
表演影片（44分鐘）：
報告介紹：
聚苯乙烯
我們部落格上有關 Kubernetes 的其他報導：
- «» （Andrey Polovov；8 年 2019 月 XNUMX 日，Saint HighLoad++）;
- «» （Dmitry Stolyarov；8 年 2018 月 XNUMX 日，HighLoad++）;
- «» （德米特里·斯托利亞羅夫；28 年 2018 月 XNUMX 日在 RootConf）;
- «» （Dmitry Stolyarov；7 年 2017 月 XNUMX 日，HighLoad++）;
- «» （德米特里·斯托利亞羅夫；6 年 2017 月 XNUMX 日，RootConf）.
來源： www.habr.com