騰訊雲原生混合雲-第三方叢集彈EKS應對突發流量的利器

騰訊雲原生發表於2021-05-20

作者

何鵬飛，騰訊雲專家產品經理，曾作為容器私有云、TKEStack的產品經理兼架構師，參與騰訊雲內部業務、外部客戶容器化改造方案設計，目前負責雲原生混合雲產品方案設計工作。

胡曉亮，騰訊雲專家工程師，專注雲原生領域。目前負責開源社群TKEStack和混合雲專案的設計和開發工作。

前言

混合雲是一種部署形態，一方面企業可從資產利舊、成本控制、控制風險減少鎖定等角度選擇混合雲。另一方面企業也可以通過混合業務部署獲得不同雲服務商的相對優勢能力，以及讓不同雲服務商的能力差異形成互補。 而容器和混合雲是天作之合，基於容器標準化封裝，大大降低了應用執行環境與混合雲異構基礎設施的耦合性，企業更易於實現多雲/混合雲敏捷開發和持續交付，使應用多地域標準管理化成為可能。
TKE 容器團隊提供了一系列的產品能力來滿足混合雲場景，本文介紹其中針對突發流量場景的產品特性——第三方叢集彈 EKS。

低成本擴容

IDC 的資源是有限的，當有業務突發流量需要應對時，IDC 內的算力資源可能不足以應對。選擇使用公有云資源應對臨時流量是不錯的選擇，常見的部署架構為：在公有云新建一個叢集，將部分工作負載部署到雲上，通過 DNS 規則或負載均衡策略將流量路由到不同的叢集：

此種模式下，業務的部署架構發生了變化，因此在使用前需要充分評估：

  1. 哪些業務工作負載需要在雲上部署，是全部還是部分；
  2. 雲上部署的業務是否有環境依賴，例如 IDC 內網 DNS、DB、公共服務等；
  3. 雲上、雲下業務日誌、監控資料如何統一展示；
  4. 雲上、雲下業務流量排程規則；
  5. CD 工具如何適配多叢集業務部署；

這樣的改造投入對於需要長期維持多地域接入的業務場景來說是值得的，但對於突發流量業務場景來說成本較高。因此我們針對這種場景推出了便捷在單叢集內利用公有云資源應對突發業務流量的能力：第三方叢集彈 EKS，EKS是騰訊雲彈性容器服務，可以秒級建立和銷燬大量 POD 資源，使用者僅需提出 POD 資源需求即可，無需維護叢集節點可用性，對於彈性的場景來說是非常合適的。僅需要在叢集中安裝相關外掛包即可快速獲得擴容到 EKS 的能力。

與直接使用雲上虛擬機器節點相比，此種方式擴縮容更快，並且我們還提供了2種排程機制來滿足客戶的排程優先順序需求：

全域性開關： 在叢集層面，當叢集資源不足時，任何需要新建立Pod的工作負載都可以將副本建立到騰訊雲 EKS 上；

區域性開關： 在工作負載層面，使用者可指定單個工作負載在本叢集保留N個副本後，其他副本在騰訊雲 EKS 中建立；

為了確保所有工作負載在本地 IDC 均有足夠的副本數，當突發流量過去，觸發縮容時，支援優先縮容騰訊雲上 EKS 副本（需要使用 TKE 發行版叢集，關於 TKE 發行版的詳細介紹，請期待後續釋出的該系列文章）。

這種模式下，業務部署架構沒有發生變化，在單叢集中即可彈性使用雲上資源，避免了引入業務架構改造、CD流水線改造、多叢集管理、監控日誌統等一系列衍生問題，並且雲上資源的使用是按需使用，按需計費，大大降低了使用者使用成本。但為了保障工作負載的安全性和穩定性，我們要求使用者的 IDC 與騰訊雲公有云 VPC 專線互通，並且使用者也需要從儲存依賴、延時容忍度等多方面評估適用性。

EKS pod 可與 underlay 網路模式的本地叢集 pod、node 互通(需要在騰訊雲VPC中新增本地pod cidr的路由，參考路由配置)，第三方叢集彈 EKS 已在 TKEStack中開源，詳細使用方式和示例見 使用文件

實戰演示

步驟

獲取 tke-resilience helm chart

git clone https://github.com/tkestack/charts.git

配置 VPC 資訊：

編輯 charts/incubator/tke-resilience/values.yaml，填寫以下資訊：

cloud:
appID: "{騰訊雲賬號APPID}" 
ownerUIN: "{騰訊雲使用者賬號ID}"
secretID: "{騰訊雲賬號secretID}"
secretKey: "{騰訊雲賬號secretKey}"
vpcID: "{EKS POD放置的VPC ID}"
regionShort: {EKS POD 放置的region簡稱}
regionLong: {EKS POD 放置的region全稱}
subnets:
- id: "{EKS POD 放置的子網ID}"
zone: "{EKS POD 放置的可用區}"
eklet:
podUsedApiserver: {當前叢集的API Server地址}

安裝 tke-resilience helm chart

helm install tke-resilience --namespace kube-system ./charts/incubator/tke-resilience/

確認 chart pod 工作正常

建立 demo 應用 nginx：ngx1

效果演示：

全域性排程

由於此特性預設已開啟，我們先將kube-system 中 的 AUTO_SCALE_EKS 設定為 false
預設情況下，ngx1 副本數為1

將ngx1副本數調整為50

可以看到有大量 POD 因為資源不足，處於 pending 狀態
將 kube-system 中 的 AUTO_SCALE_EKS 設定為 true 後，短暫等待後，觀察pod狀態，原本處於 pend的pod，被排程到了 EKS 虛擬節點：eklet-subnet-167kzflm 上。

指定排程

我們再次將 ngx1 的副本數調整為1

編輯 ngx1 yaml，設定開啟區域性開關

spec:
    template:
        metadata:
            annotations:
            # 開啟區域性開關
                AUTO_SCALE_EKS: "true"
            # 設定需要在本地叢集建立的副本個數
                LOCAL_REPLICAS: "2""
        spec:
            # 使用tke排程器
               schedulerName: tke-scheduler

將 ngx1 副本數改為3，儘管本地叢集沒有出現資源不足，但可以看到，超過2個本地副本後，第三個副本被排程到了EKS上

解除安裝 tke-resilience 外掛

helm uninstall tke-resilience -n=kube-system

此外 TKEStack 已整合 tke-resilience，使用者可以在 TKEStack 的應用市場中介面化安裝 tke-resilience

應用場景

雲爆發

電商促銷、直播等需要在短時間擴容大量臨時工作負載的場景，這種場景下，資源需求時間非常短，為了應對這種短週期需求而在日常儲備大量資源，勢必會有比較大的資源浪費，且資源需求量隨每次活動變化難以準確評估。使用此功能，您無需關注於資源籌備，僅需依靠K8S的自動伸縮功能，即可快速為業務建立出大量工作負載為業務保駕護航，流量峰值過去後，雲上POD會可優先銷燬，確保無資源浪費的情況。

離線計算

大資料、AI業務場景下，計算任務對算力亦有高彈性要求。為保障任務快速計算完成，需要在短時間能有大量算力支撐，而計算完成後，算力同樣處於低負載狀態，計算資源利用率呈高波動型，形成了資源浪費。並且由於GPU資源的稀缺性，使用者自己囤積大量GPU裝置不僅成本非常高，還會面臨資源利用率提升，新卡適配，老卡利舊，異構計算等多種資源管理問題，而云上豐富的GPU卡型可為使用者提供更多樣的選擇，即用即還的特性也確保了資源零浪費，每一分錢都真正化在真實的業務需求上。

未來演進

  1. 多地域支援，支援應用部署到雲上多個區域，應用與地域關聯部署等特性
  2. 雲邊結合，結合 TKE-Edge，針對弱網路場景提供應用部署、排程策略，擺脫專線依賴

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！

相關文章