阿里雲ECI如何6秒擴容3000容器例項？
簡介：2021年雲棲大會現場，阿里雲工程師演示了在6秒時間內成功啟動3000個ECI，並全部進入到Running狀態。本文將為你揭開阿里雲ECI是如何做到極速擴容的。
引言
根據最新CNCF報告，有超過90%的使用者在生產環境使用容器，並且有超過80%的使用者通過Kubernetes管理容器。是不是我們的生產環境上了K8s就完美解決了應用部署的問題？IT界有句俗語，沒有什麼是萬能的，K8s也不是萬能的，K8s解決了應用的編排和排程，但沒有解決資源容量的限制、沒有解決容器的安全隔離，以及高昂的運維成本。
傳統K8s的問題和困境
- 資源效率低
- 資源隔離弱
容器使用系統核心的namespace進行資源隔離，但核心僅支援UTS、IPS等6種namespace隔離。我們遇到過一個客戶，需要在測試環境修改某個業務Docker的時間，結果導致一臺機器上所有的容器時間都被修改。還有定製核心引數、IO公平分享等場景，也有相同的問題。
同時，容器安全也一直被大家詬病，例如特權容器直接可以看到機器上所有的磁碟資料。
- 運維成本高
雲原生為IT帶來了很多便利，但同時雲原生也讓整個IT運維變得越來越複雜。一個K8S容器叢集，至少需要部署高可用Master、網路外掛、映象倉庫、日誌服務，以及監控元件。即便辛苦把這些元件安裝完成，也要面對後續每天各種運維、告警的處理，運維每天是各種的救火。
阿里雲彈性容器例項ECI應運而生
有沒有一種免運維、並且能夠按需使用的安全的容器解決方案呢？阿里雲彈性容器例項應運而生了。
阿里雲彈性容器例項（簡稱ECI，Elastic Container Instance）是阿里雲結合容器和Serverless技術提供的容器執行服務。通過使用ECI，在阿里雲上部署容器時，無需購買和管理雲伺服器ECS，可以直接在阿里雲上執行Pod和容器，省去了底層伺服器的運維和管理工作。簡單來說，一個ECI就是一個Pod，可以被K8s編排和排程。
- 底層資源由阿里雲託管，使用者不再需要管理底層VM（虛擬機器）。
- 複用整個阿里雲的彈性計算資源池，保證充足的庫存。
- 低成本，按秒計費，從Pod開始建立時收費。
- 啟動快，秒級啟動底層安全沙箱。
- 相容性強，完全相容K8s。
阿里雲彈性容器例項採用社群的Virtual Kubelet方案與K8s整合，當叢集內有Pod建立並排程到Virtual Kubelet時，Kubelet就會呼叫ECI介面，啟動ECI。
ECI與業務系統的對接方式包括：
- （推薦）通過阿里雲容器服務Serverless Kubernetes（ASK）部署業務，提供無需運維的Kubernetes叢集能力，底層Pod資源全部使用ECI承載。
- （推薦）通過阿里雲容器服務Kubernetes（ACK）部署業務，為ACK叢集提供額外的海量彈效能力。
- 通過Virtual Node對接使用者在ECS上自建的Kubernetes叢集，提供方便快捷的彈性計算資源。
- 通過Virtual Node對接使用者線上下IDC自建的Kubernetes叢集，提供雲上的無限彈性計算能力。
- 通過OpenAPI直接對接業務系統，低成本的隨時建立或釋放ECI業務容器。
在2021年雲棲大會現場，阿里雲Serverless容器服務彈性容器例項釋出了極速啟動例項新特性。彈性容器例項在解決上述應用部署問題的基礎上，創新的提供極速啟動的產品特性。現場演示了在6秒時間內成功啟動3000個ECI，並全部進入到Running狀態。
阿里雲是如何做到6秒鐘啟動3000個容器例項？
一方面，通過大量使用者級別的建立歷史資料，應用機器學習找出使用者建立Pod的規律，通過預測預排程、資源複用等手段，節省ECI的排程、建立時間，同時使用了阿里雲袋鼠沙箱容器作為引擎，輔以overlay網路、儲存方案，將單ECI例項冷啟動時間壓縮到了3秒以下，針對袋鼠引擎後續會有專門文章進行詳細的介紹，也敬請大家期待。
另一方面，在映象拉取維度，通過映象快取把容器映象做成快照，免去每次啟動Pod拉取容器映象的動作，例如阿里雲的達摩院AI團隊部分映象可以達到幾百G，如果按照傳統方式拉取需要十幾分鍾，通過ECI的映象快取方案可以實現Pod秒級啟動。
阿里雲彈性容器例項提供了從Runtime、GuestOS、底層計算、網路、儲存資源的免運維全託管服務，並在2021年雲棲大會上釋出了極速的例項啟動速度，幫助客戶快捷的完成業務系統擴縮容。
隨著雲廠商服務邊界的進一步上移，ECI期望通過規模化、集約化的資源排程和端到端的Runtime設計，提供相比客戶自建容器資源池更好的彈性、效能和成本能力，這將是未來1-2年阿里雲彈性容器例項持續探索的方向。
原文連結
本文為阿里雲原創內容，未經允許不得轉載。