秒級彈性！探索彈性調度與虛擬節點如何迅速響應瞬時算力需求?

前言

在前面的文章《彈性調度助力企業靈活應對業務變化，高效管理雲上資源》中，我們介紹了阿里雲容器服務 ACK 彈性調度爲了幫助客戶解決在使用雲上彈性資源時，面對的“難以差異化控制業務資源使用量，縮容時部分業務 Pod 未釋放”等挑戰，提供了按照多級資源的優先順序進行調度，以及按照定義的優先順序進行縮容的能力。

本文將介紹彈性調度如何使用虛擬節點來滿足您的業務彈性需求。

企業在實施應用彈性過程中，彈性速度和彈性位置是重點關注的兩個核心指標。

對於追求高可用以及穩定性的企業來說，敏捷的彈性能夠在業務流量突增時，保證系統的連續性與穩定性。同時，通過跨多地域部署應用，可以在地域性故障發生時，有效地維持服務的持續可用性。

對於大數據處理任務的企業來說，快速的彈性能夠縮短任務執行時間，加快應用的迭代速度。同時，集中部署在單個地域，則可以減少應用之間的網絡通信時延，從而進一步提升數據處理效率。

顯然，這兩個指標對於確保企業業務的穩定高效運行至關重要。

然而，許多企業在面對快速到來的業務流量高峯和日益增長的大數據算力需求時，現行的分鐘級自動伸縮節點池的彈性響應已經無法滿足需求。並且，通過合理的部署策略，實現預期的彈性位置，也頗具挑戰。

爲此，阿里雲推出彈性容器實例（Elastic Container Instance，ECI），以十秒級的彈性速度，有效應對突發流量的彈性需求。同時，阿里雲容器服務 Kubernetes 版（ACK）利用虛擬節點技術實現與 ECI 彈性資源的無縫集成，使得業務能夠在集羣內靈活動態地調用 ECI 資源，迅速應對彈性挑戰。此外，容器服務 ACK 的彈性調度功能在將業務調度到 ECI 上時，還能維持業務的親和性配置不變，確保應用運行的穩定和高效。

使用虛擬節點實現秒級彈性

爲了在 ACK 中使用 ECI，需要在 ACK 集羣中安裝虛擬節點組件。

在 ACK Pro 版集羣中，可以通過組件管理頁面部署 ack-virtual-node 組件，該組件默認被託管，不佔用 Worker 節點資源。

在 ACK 專有版集羣中，可以通過應用市場頁面部署 ack-virtual-node 組件，安裝成功後會在 kube-system 命名空間下創建一個名爲 ack-virtual-node-controller 的 deployment，該 deployment 會運行在您的 Worker 節點上。

安裝成功後用戶可以通過 kubectl get no 命令在集羣中查看到若干虛擬節點，代表虛擬節點安裝成功。

虛擬節點安裝成功之後，可以使用彈性調度功能配置 ECI 的使用策略，以下是“優先調度 ECS，當 ECS 資源使用完後使用 ECI 資源”的示例。

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: test
spec:
  strategy: prefer
  units:
  - resource: ecs
  - resource: eci

配置了以上 ResourcePolicy 之後，在 default 命名空間下的所有 Pod 都將遵循以下的調度規則：優先使用 ECS，ECS 資源用完後使用 ECI。

需要注意的是：以上配置會使得 ECS 節點上的搶佔功能失效，如果需要同時保持在 ECS 上的搶佔能力，請配置 preemptPolicy=BeforeNextUnit，如果需要限定生效的業務範圍，請按需配置 selector。

以下是實際使用效果：

首先，提交一個 Deployment，8 個業務 Pod 中僅有 7 個業務 Pod 能夠被成功調度。

 

此時，提交 ResourcePolicy，並將 Deployment 的副本數增加到 10，新的副本將全部運行在 ECI 上。

 

通過統計業務 Pod 的創建時間以及 startTime，可以看到這裏新 Pod 的創建時間在 13 秒，遠遠低於自動伸縮節點所需的彈性時間。

 

降低大數據任務通信時延

若您的集羣配置了多個可用區的虛擬節點，在默認情況下，ECI Pod 可能會被調度在多個可用區上。如下圖，在默認情況下，nginx 被調度到了 C 和 D 兩個可用區的 virtual node 上。

 

 

對於大數據型應用，配置可用區親和往往意味着計算 Pod 之間的網絡通信代價更小，進而帶來更高的吞吐量。通過阿里雲彈性調度，您可以通過 Pod 上的節點親和以及 Pod 親和限制業務調度的可用區，從而實現 ECS 上的 Pod 與 ECI 上的 Pod 調度在相同的可用區上。

以下是兩種在 ECI 上配置相同可用區調度的示例，分別使用了指定可用區調度以及不指定可用區調度兩種方式，在以下的兩個例子中，已提前提交了 ResourcePolicy：

手動指定可用區

原生 Kubernetes 提供了節點親和調度語義來控制 Pod 的調度位置，以下的例子中我們指定 nginx 服務僅在可用區 C 上進行調度。您唯一需要進行的修改是在工作負載的 PodTemplate 或 PodSpec 中添加節點親和約束。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment-basic
spec:
  replicas: 9
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                      - cn-hongkong-c
      containers:
        - image: 'nginx:1.7.9'
          imagePullPolicy: IfNotPresent
          name: nginx
          resources:
            limits:
              cpu: 1500m
            requests:
              cpu: 1500m
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File

同樣將業務 Pod 擴容到 9，此時能夠觀察到業務 Pod 全部運行在可用區 C 上，由於集羣中 ECS 節點均爲可用區 D 上的機器，因此所有業務 Pod 全部運行在 ECI 上。

最優可用區感知調度

爲應對大數據計算需求，通常需要部署大量的 Pod，這時候確保 ECI 提供充足的算力資源成爲關鍵。爲確保選擇到具有充足剩餘算力的可用區，可以在指定可用區親和時使用 Pod 親和。在 ECI 調度過程中，調度器會參考 ECI 提供的可用區建議，選擇一個可用算力更多的可用區，從而實現自動選擇更優位置的效果。以下例子中我們將限制 Pod 僅在 ECI 上調度，並通過 Pod 親和限制 Pod 必須被調度到同一個可用區。

注：Pod 親和會使得後續 Pod 與第一個被調度的 Pod 親和在相同可用區，當採用 ECS+ECI 彈性調度時，由於第一個被調度的 Pod 通常爲 ECS Pod，會使得後續 ECI Pod 親和在 ECS 相同的可用區，此時建議您使用 preferredDuringSchedulingIgnoredDuringExecution。

提交的 ResourcePolicy 爲：

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: test
spec:
  strategy: prefer
  units:
  - resource: eci

提交的工作負載爲：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment-basic
spec:
  replicas: 9
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - nginx
              topologyKey: topology.kubernetes.io/zone
      containers:
        - image: 'nginx:1.7.9'
          imagePullPolicy: IfNotPresent
          name: nginx
          resources:
            limits:
              cpu: 1500m
            requests:
              cpu: 1500m
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File

提交後可用發現，此時 Pod 依然均調度在相同的可用區，此時調度到的可用區將會是 ECI 推薦的更優可用區。

保證在線業務高可用

對於在線業務而言，配置業務多可用區部署是保證業務高可用的一種有效手段。通過阿里雲彈性調度，您可以通過 Pod 上的拓撲分佈約束來實現 ECS 上的 Pod 與 ECI 上的 Pod 遵循相同的拓撲分佈約束，從而實現業務的高可用。

以下是一個在 ECI 上配置業務高可用的示例，指定了業務 Pod 在多個可用區上均勻分佈，並且在 ECS 資源不足時使用 ECI。

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: test
spec:
  strategy: prefer
  units:
  - resource: ecs
  - resource: eci
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment-basic
spec:
  replicas: 9
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      topologySpreadConstraints:
        - labelSelector:
            matchLabels:
              app: nginx
          maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
      containers:
        - image: 'nginx:1.7.9'
          imagePullPolicy: IfNotPresent
          name: nginx
          resources:
            limits:
              cpu: 1500m
            requests:
              cpu: 1500m
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File

提交上述資源清單後，Pod 最終的可用區和節點分佈如下，由於可用區 D 上存在三個 ECS 節點，因此最終 Pod 在可用區 D 上存在 5 個 Pod，在可用區 C 上存在 4 個 Pod。能夠滿足約束中最大傾斜度爲 1 的要求。

What's Next

阿里雲容器服務 Kubernetes 版（ACK）在標準 K8s 調度框架的基礎上擴展了彈性調度功能，致力於提高應用性能和集羣整體資源的利用率，保障企業業務的穩定高效運行。

在前期文章《彈性調度助力企業靈活應對業務變化，高效管理雲上資源》中，我們已經探討了如何通過阿里雲容器服務 ACK 的彈性調度有效管理各類彈性資源，以幫助企業優化資源配置，實現降本增效。

在本文中，我們又深入解析了 ACK 彈性調度如何與彈性容器實例（ECI）這一關鍵彈性資源結合，憑藉 ECI 快速彈性、秒級計費和即時釋放的優勢，顯著提升企業業務的穩定性和效率。

在即將推出的調度系列文章中，我們將詳細介紹如何在 ACK 上管理和調度 AI 任務，助力企業 AI 業務在雲端快速落地。

作者：吳昆

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。