[發明專利]避免容器集群啟動擁塞的調度方法和容器集群管理平臺

有效

• 申請號: 202011188530.5
• 申請日: 2020-10-30
• 公開（公告）號: CN112328359B
• 公開（公告）日: 2022-06-17
• 發明（設計）人: 陳凱;王成龍;郭子敏
• 申請（專利權）人: 烽火通信科技股份有限公司
• 主分類號: G06F9/455
• 分類號: G06F9/455;G06F9/50;H04L67/10;H04L67/1008;H04L67/60
• 代理公司: 深圳市六加知識產權代理有限公司 44372
• 代理人: 宋建平

本發明公開了一種避免容器集群啟動擁塞的調度方法和容器集群管理平臺，該調度方法包括：計算節點在啟動Pod的過程中，如果滿足預設的抑制條件，則根據Pod的啟動順序從啟動Pod池中選取部分Pod，并將被選取的Pod添加到抑制Pod池中，以對被選取的Pod進行抑制；如果滿足預設的恢復條件，則根據Pod的啟動順序、Pod的資源占用量和該計算節點所能提供的資源容量確定本次計劃恢復的Pod，將本次計劃恢復的Pod添加至啟動Pod池中，以重新啟動本次計劃恢復的Pod，直至完成所有Pod的啟動。在本發明中，有序調度應用容器的啟動，提高了容器啟動效率，節約了啟動時間，防止啟動死鎖。

技術領域

本發明屬于容器調度領域，更具體地，涉及一種避免容器集群啟動擁塞的調度方法和容器集群管理平臺。

背景技術

隨著虛擬化技術的不斷發展，越來越多的企業將應用部署到了云平臺上。云平臺主要提供虛擬機和容器這兩種方式部署應用，其中容器的發展尤其迅速，容器內由于沒有客戶操作系統，相對于虛擬機而言更輕量級、資源占用更小、啟動更迅速、也更易于部署，并且對于應用來說屏蔽了各操作系統的差異性。

容器的優勢吸引大量的應用采取容器方式部署，激發了容器集群統一管理平臺的需求。目前，業內普遍采用google的開源項目kubernetes容器集群管理平臺，以及在此項目的基礎上開發出自有的容器集群管理平臺。kubernetes平臺實現了容器的規模化統一部署、資源及狀態監控、跨節點的靈活調度、應用容器的平滑升級、擴縮容、負載均衡、故障檢測和自我修復等，讓開發者更專注于業務本身，平臺部署的相關工作交給容器管理平臺。

kubernetes平臺采用基于容器技術的分布式架構，包括控制節點(master node)和計算節點(work node)。各節點可以是物理服務器，也可以是虛擬機，控制節點的容器組調度模塊根據各計算節點的資源剩余容量和容器對資源的需求(包括CPU資源、內存資源)，調度目標容器到合適的計算節點創建并運行。計算節點是容器的運行載體，負責容器的生命周期管理、狀態監控等。在計算節點上kubernetes為了便于容器管理，增加了Pod的概念，Pod是kubernetes管理的最小單元，一個應用的所有容器集合，它由多個容器組成，kubernetes平臺以Pod為單位進行部署調度。本發明同樣采用以Pod為粒度進行容器的調度。

目前，現在越來越多的云平臺采用一體機柜方式部署，存在異常掉電的情況，或者一體機柜進行地理位置的遷移，以及一體機在出廠前進行預先部署應用的情況。由于容器管理平臺缺少Pod啟動優先級管理和啟動順序管理，各個節點上電后，已部署的應用Pod會無序的同時啟動。Pod啟動過程中同時搶占計算節點的資源，導致計算節點資源利用率沖高，各個Pod可用資源變少，啟動時間變長。容器集群管理平臺的Pod健康檢查模塊判定Pod啟動超時，根據策略重啟Pod下的容器。

此外，如果應用Pod間存在部署依賴，還可能導致依賴死鎖，服務無法啟動，例如，Pod A的服務依賴Pod B，Pod B的服務依賴Pod C，Pod A、Pod B和Pod C會同時啟動一起搶占節點資源。如果Pod A先完成容器級別啟動，需要等待Pod B完成。當Pod A等待超時后，會重啟Pod A，這樣Pod A又會搶占計算節點的資源，導致Pod B和Pod C資源變少，延長了應用的整體啟動時間。參考圖1展示了計算節點中運行Pod數量與其資源占用情況的變化圖，當運行Pod數量大時，它們之間會搶占計算節點的資源。

發明內容

針對現有技術的以上缺陷或改進需求，本發明提供了一種避免容器集群啟動擁塞的調度方法和容器集群管理平臺，其目的在于增加應用容器的部署順序和優先級管理，有序調度應用容器的啟動，提高了容器啟動效率，節約了啟動時間，防止啟動死鎖，由此解決容器集群管理平臺在面對大量容器同時啟動時，對計算節點資源的搶占，導致計算節點資源利用率沖高，各個Pod可用資源變少，啟動時間變長的技術問題。