如何在雲上高效地實踐自動化和彈性

本篇作者丨簫竹

前言

在雲計算越來越普及的今天，企業對雲的討論焦點已經從幾年前的「是否上雲」轉換為「如何快速上雲」和上雲之後「如何低成本用雲」等問題。新的焦點問題對雲提出了新的要求：容器化、自動部署、自動發佈、彈性擴縮容、監控告警等雲上業務生命週期的方方面面。除此之外，隨著業務架構的不斷複雜，高可用、多備份、異地多活等方案趨於常態化，由此對多賬號、多 Region 部署的需求越來越強烈。

企業應用上雲，通常都會根據自身的業務架構，首先選擇相關雲產品並完成授權，接著搭建網絡基礎環境、搭建業務架構、配置負載和彈性伸縮策略，最後實現應用上雲。

整個過程即複雜又繁瑣，但當想要藉助編排服務（Terraform，ROS）來簡化流程、實現自動化的時候，又遇到了阻礙自動化流程的各種障礙：

雲產品沒有提前開通，導致 OpenAPI 調用失敗，編排服務無法工作；
RAM 權限策略的編寫過於複雜，編排模板涉及到哪些策略，無處可查，想要做到精細化的授權難度太大；
Kubernetes 集群的搭建依賴多種雲資源優先創建，但云資源之間存在的複雜的關聯和依賴關係卻無處可查；
每個雲賬號對大部分資源的使用都存在配額的限制，彈性伸縮的時候往往因為配額不足而失敗，進而影響應用的快速擴容；
......

一、端到端解決方案

「如何做到自動化上雲」成了應用上雲路上的一道坎，基於這個現狀，阿里雲開放平臺在通過過去一年的努力，提供了一系列的「端到端解決方案」，旨在消除客戶在基於 OpenAPI 上雲過程中影響“自動化”的主要障礙。

本文從一個實際場景出發，基於開源資源編排工具 Terraform、 Kubernetes 作業管理的開源項目 Argo 和阿里雲的多種服務搭建一個自動化彈性樣板間，並利用該樣板間完成了 Kubernetes 應用的自動化部署和伸縮，在雲上實踐“自動化”和“彈性”的同時，切身感受下「端到端解決方案」所帶來的重大成果和客戶價值。

圍繞自動化彈性樣板間的具體內容，本文將介紹三種已經落地的方案：

雲產品自動化開通

什麼是自動化開通？為什麼要自動化開通？如何做到自動化開通？

左手彈性，右手成本

彈性遇到的問題是什麼？如何通過配額服務解決？彈性伸縮過程中如何控制成本？

RAM 權限策略的自動化導出

如何對一個 Terraform 模板中涉及到的資源實現準確、完備和精細化的權限控制？

二、雲產品自動化開通

所謂「雲產品開通」，是指在註冊了一個新的阿里雲賬號後，首次使用某個雲產品服務時，需要閱讀該雲產品的服務等級協議，並通過點擊“開通”按鈕來完成該雲產品的激活。激活之後才能正常地使用該雲產品的控制檯、OpenAPI以及資源編排（Terraform，ROS）等服務。

自動化彈性樣板間總共涉及到 9 款服務，其中有 3 款服務需要手動開通，當需要支持多賬號部署時，需要 3*N 次手動開通操作，費時又費力。同時，對於資源編排服務 Terraform 和 ROS 而言，無疑是致命的，直接阻礙了 Terraform 和 ROS 的成功運行。目前與 Terraform 和 ROS 集成的所有60多款雲產品中，分別有 22 和 25 款雲產品需要在首次使用前進行手動開通，體驗非常差。

為了解決該問題，開放平臺提供了自動化開通的方案。所謂「自動化開通」，是指對外提供開通動作的 OpenAPI，通過調用 OpenAPI 或者基於 API 的編排工具實現雲服務的自動開通，省去手動開通的麻煩。目前，已經有超過 30 款雲產品實現了自動化開通，Terraform 和 ROS 也實現了 100% 全自動化開通的目標，徹底解決了阻礙 Terraform 和 ROS 自動化之路的第一個障礙，也為自動化彈性樣板間的成功提供了支持：

data "alicloud_ack_service" "open" {
  enable = var.enable_service
  type   = "propayasgo"
}
data "alicloud_log_service" "open" {
  enable = var.enable_service
}
data "alicloud_cms_service" "open" {
  enable = var.enable_service
}

如何使用 Terraform 實現自動化開通，詳見文章Terraform 支持自動化開通阿里雲產品。

三、左手彈性，右手成本

在雲上根據業務發展，按需建出資源是雲上資源彈性的重要特徵，相較於傳統IDC機房的機器採購、上架、供應等漫長的週期和運維成本，雲上資源的快速供應是客戶對雲的彈性的最大認可。

為了充分利用和發揮雲平臺的彈性和分佈式特性，必須做到從基礎設施到應用都是彈性可伸縮和運維全自動化，以雲原生的最佳姿勢使用雲。自動化彈性樣板間正是充分利用和發揮阿里雲的彈性優勢，實現了雲資源和雲應用的彈性：

基礎設施層彈性管理

藉助 Terraform 自動創建託管版Kubernetes集群，並基於彈性伸縮服務 ESS 為其自動創建彈性伸縮節點池，當節點池中節點負載達到閾值時實現自動伸縮，從而達到基礎設施層彈性管理。

業務彈性管理

藉助 Terraform 和 Argo 將業務應用自動部署到容器集群的 Pod，並通過配置由 Kubernetes 的 HPA 策略控制業務層的彈性管理。

圖片來自：https://help.aliyun.com/document_detail/86554.html

resource "alicloud_cs_managed_kubernetes" "this" {
  name                     = local.k8s_name
  pod_cidr                 = var.k8s_pod_cidr
  cluster_spec             = "ack.pro.small"
  worker_number            = var.worker_number
  ...
}
resource "alicloud_cs_kubernetes_node_pool" "autoscaling" {
  name                 = "autoscaling"
  cluster_id           = alicloud_cs_managed_kubernetes.this.id
  # automatic scaling node pool configuration.
  scaling_config {
    min_size                 = var.autoscaling_node_min_number
    max_size                 = var.autoscaling_node_max_number
    ...
  }
  ...
}

在如此全自動化架構下，彈性樣板間所要面臨的挑戰是：

要求基礎資源完全按需使用

包年包月計費類型將無法適用，機器不能隨時釋放，容易造成資源浪費

資源供應需有保障

按量計費的類型，需要確保資源充足和 100% 創建成功；雲資源配額可動態調整

資源成本不能太高，要接近包年包月成本

既要滿足按需使用，又要能享受到類似包年包月的折扣

彈性資源的監控

自動彈出的資源可被監控系統自動發現並處於監控之下

面對如上挑戰，得益於「端到端解決方案」的成果，自動化彈性樣板間採用瞭如下解決方案：

3.1 配額中心解決資源使用限制問題

「配額中心」是阿里雲開放平臺2020年推出的一款新的雲產品，提供了實時查詢配額、在線發起配額申請、資源配額級聯申請、API 流控申請、配額告警等能力，有效地幫助客戶根據業務的需要在線調整多種資源配額，解決資源不足帶來的問題。

自動化彈性樣板間涉及到 9 款雲產品，涉及到可調整的配額包括如實例規格的需求量、可保有的EIP 數量、可保有的 SLB 數量、集群節點的數量等有 6 項之多，並且不同配額項之間還可能存在相互依賴、級聯和地域之分，每一項配額都需要配置告警規則和配額申請，以便當配額不足而發起告警後可以自動發起配額申請。面對這些複雜的關係，彈性樣板間藉助配額中心和 Terraform 集成的能力，完成了對不同配額項申請和告警的自動編排，通過查詢規則（如：特定Region特定Zone下的特定實例規格）動態獲取當前配額值並配置自動告警規則（如：所剩配額不足一半時發起告警）和自動申請規則（如：所剩配額不足一半時發起當前總配額2倍的申請），以實現配額不足時發起自動申請。

3.2 預留實例券解決資源供應和成本問題

預留實例券（Reserved Instance，簡稱RI）是彈性計算團隊推出的一種具有特定屬性的優惠券，可以自動匹配您賬戶下的按量付費實例（不含搶佔式實例）。相比包年包月實例，預留實例券與按量付費實例這種組合模式可以兼顧靈活性和成本。

在阿里雲不支持 RI 之前，客戶通過包年包月、搶佔式實例和按量付費的組合來實現成本節約，即通常會購買一定量的包年包月，然後在業務尖峰的時候購買按量付費資源進行彈性擴展。當 RI 誕生後，本質上在提供了包年包月的能力的同時還提供了基於彈性伸縮獲得比包年包月成本更低的能力。

包年包月+按量付費

按照平時業務購買包年包月，業務尖峰時購買按量付費資源進行彈性擴展；業務穩步上升後，需要新購包年包月資源進行擴展（不是彈性伸縮）。因此企業付出的成本等於包年包月的支出加上按量付費的支出。

預留實例券

最理想的情況下，全部負載都可以使用RI覆蓋，且沒有超買，企業付出的成本等同於陰影部分的面積。

兩種模式對比，陰影面積越小成本越低，顯然RI更能將雲計算的彈性發揮到極致，更省錢。自動化彈性樣板間通過 Terraform 支持對 RI 按可用區和不同規格購買。結合實例規格配額的消耗情況，不斷調整 RI 的購買數量，確保 RI不過量採購或者 RI 不夠用，最大化降低使用成本。

3.3 安裝雲監控插件解決彈性資源可監控問題

資源監控是Kubernetes中最常見的監控方式，通過資源監控可以快速查看負載的CPU、內存、網絡等指標的使用率。在阿里雲容器服務中，資源監控已經與雲監控互通，彈性伸縮的節點池也已支持自動擴展出的 ECS 節點上自動安裝雲監控插件，藉助該插件可實現容器節點的自發現，保障彈性資源納入監控。當然，這一配置也可以通過 Terraform 來實現自動化：

  name                 = "autoscaling"
  cluster_id           = alicloud_cs_managed_kubernetes.this.id
    
  # 自動安裝雲監控插件
  install_cloud_monitor = true
    
  # automatic scaling node pool configuration.
  scaling_config {
    min_size                 = var.autoscaling_node_min_number
    max_size                 = var.autoscaling_node_max_number
    ...
  }
  ...
}

四、RAM 權限策略的自動化導出

前兩部分內容重點介紹瞭如何藉助「端到端解決方案」的成果和 Terraform 編寫一個全自動化的彈性樣板間模板，接下來就是如何正確地運行這個模板來實現樣板間的快速搭建。但是，樣板間成功運行的前提是用戶必須擁有模板中所有資源的操作權限。

對任何一個 Terraform 模板而言，實現對模板精細化權限策略管理的挑戰主要包含以下幾個方面：

無法自動地獲取模版中所包含的所有資源

雖然可以通過人工Review模板代碼或者解析 Terraform 的預覽結果來間接地獲取模板中所包含的資源，但人工成本將隨著資源模板複雜度的增加而增加；

無法根據資源準確地推斷資源所使用的OpenAPI有哪些

Terraform 是聲明式的工具，每個資源所調用的 OpenAPI 對資源模板而言完全是黑盒，即使有資源也無法獲取到準確的 OpenAPI 信息

無法根據OpenAPI寫出完整的、細粒度的權限策略

每個 OpenAPI 的鑑權還需要考慮不同的級別，如產品級、資源級以及 API 級；同時最終生成的每一條權限策略中還包含 Region 信息、賬號信息和父子資源關係等信息

面對RAM 權限策略的生成問題和挑戰，開放平臺在2020年推出了一款新的服務「IaC Service」，這款服務可以識別任一 Terraform 模板中定義的資源，解析每個資源在 CURD 階段使用到的 OpenAPI，最後根據解析後的結果自動導出 RAM Policy 的內容，提供給最終客戶使用。

有了 RAM 權限策略自動化導出的能力，針對 Terrafrom 模板的鑑權，將會大大減少手動編寫 RAM Policy 的工作，只需要將 Terraform 模板上傳到 IaC Service 上，即可快速得到一個精準的、模板相關的 RAM Policy，也為整個彈性樣板間的順利執行提供了支持。

五、結果展示

藉助自動化開通、配額中心的告警和Quota申請、預留實例券與Terraform的集成、容器服務與Terraform的集成和彈性伸縮的支持、RAM Policy 的自動化導出等多種能力，目前自動化彈性樣板間已經全面落地，並且已經開源到 Terraform Registry： terraform-alicloud-modules/automation-elastic-landing.

自動化彈性樣板間的運行方式有兩種：

Terraform 命令行

可以按照樣板間倉庫中的 README 的指引，依次執行 terraform apply ， source .bash_profile和terraform apply 即可。

IaC Service 在線運行

IaC Service 目前已經提供了可以在線運行 Terraform 的工作流，首先將彈性樣板間 GitHub 倉庫 Fork 一份到自己的賬號下，然後登錄 IaC Service 控制檯，創建一個新的工作空間，選擇 Fork 後的倉庫，然後點擊“發起新計劃”即可執行樣板間。

相比與 Terraform 命令行的方式，IaC Service 可以省去本地安裝和運行 Terraform 的麻煩，同時藉助 GitOps 的能力，可以實現修改應用文件後自動觸發新的工作流、持續部署的能力。

自動化彈性樣板間在運行成功之後，登錄容器服務控制檯，選擇新建的集群，進入節點池，選擇 autoscaling 節點池，即可看到當前集群下所有的伸縮活動：

登錄 Agro UI 也可以如期地看到擴展出的應用正在部署和同步中：

應用的自動彈性擴展將會帶動資源層面的彈性伸縮，當應用數的增加並且 Pod 負載超過閾值時，將自動擴展新節點；當應用下線後，隨著 Pod 負載的降低將收回彈出的節點，完全做到的全自動化伸縮。

六、總結

總結一下，阿里雲開放平臺的「端到端解決方案」的價值和成果：

與編排工具 Terraform 和 ROS 集成的雲產品實現了 100% 自動化開通或者免開通，全面解決了客戶在使用編排工具時的一大障礙；

配額中心支持對 30+雲產品配額項的管理，同時具備了配額告警、配額自動申請的能力；

與Terraform 集成的雲產品從原來的 43 款提升到了 61 款，並且還在持續集成中；

IaC Service 不但提供了在線執行 Terraform 的能力，還支持對 Terraform 模板的自動解析和對應的 RAM Policy 的自動化導出，大大降低了客戶使用 Terraform 的成本。

自動化彈性樣板間的成功落地是對「端到端解決方案」價值和成果的直接體現，但並不是唯一受益方，解決客戶在自動化和彈性流程中的痛點問題，解決雲產品在對接橫向產品中的痛點問題，做到真正的“降本提效”才是對該方案最大的反饋。後續我們也將繼續在自動化、彈性等領域釋放更多能量。

前言