青雲QingCloud 鏡像倉庫上線｜最強 IaaS 驅動下的完整容器平臺

1956 年 4 月 26 日，一架起重機把 58 個鋁製卡車車箱裝到了一艘停泊在港內的老油輪上，誰也不會想到，一場革命就這麼開始。集裝箱的誕生，讓貨物的運輸成本大大下降，也讓本來混亂的運輸環境，變得整潔有序，整個物流體系更加高效，最終改變了世界貿易。

在 IT 世界中，容器也扮演着「集裝箱」的角色，只不過「運輸」內容從貨物換成了應用程序。它比虛擬機更輕量，啓動迅速，佔用資源低。幾乎能夠在任意場景以相同的方式運行，能夠實現開發、測試、生產環境的統一調度，建立相同的運行環境。

若是說，集裝箱提供了一套標準化的物流體系，那麼容器就是提供了一套標準化的應用發佈方式。

圍繞容器，誕生了多種新型架構，從而知足不一樣場景需求。市場中，愈來愈多的企業將容器技術應用到實踐中，而在容器火爆的同時，也曝露出容器技術的種種弊端：

首先，容器技術雖然簡化了產品持續交付的複雜工序，但實現容器化是複雜的，它須要不少技術的支撐，好比說，容器管理、編排、應用打包、容器間的網絡、數據快照等；

其次，當企業想構建一套網絡方案，須要精通 Linux 提供的各類高級網絡功能，這個技術門檻過高了。特別是對專一於業務開發的 Docker 用戶而言，這類操做每每顯得過於複雜。並且，因爲在虛機中部署容器，雲平臺和 Docker 平臺都有本身的虛擬化網絡實現方案，兩者功能重疊，使用時會相互嵌套，致使的其網絡性能損耗很是嚴重，甚至達到 80%。

因此，雖然容器技術正在逐步被你們承認與應用，但其網絡性能以及配置的複雜程度一直都在被你們所詬病。

那麼，這些問題該如何解決？

爲了解決以上問題，青雲QingCloud，從新構建了基礎網絡、存儲層，實現容器和虛擬化的統一架構，基於底層資源作了一層抽象，即 QingCloud Application Framework，隔離了底層硬件資源並提供接口給上層應用，提供了一套同時支持虛擬化和容器化的基礎架構。

而後，借 SDN（軟件定義網絡）及 SDS（軟件定義存儲）爲容器運行環境提供極致的網絡及存儲性能支持。經過 SDN 網絡直通功能（SDN Passthrough），容器直接使用雲平臺的 SDN，避免兩層網絡的重疊帶來的數據包容量損耗，節約本來需經屢次虛擬化損失近 3/4 的性能。

同時，得益於青雲平臺彈性可擴展的特性，部署於虛擬主機之上的容器平臺也將隨之得到靈活伸縮的能力，用戶能夠對整個系統進行橫向及縱向的彈性伸縮操做。 在應用層裏，青雲容器平臺經過 QingCloud AppCenter 框架交付，一鍵完成部署，持續升級，提供建立、擴容、健康監測、用戶管理等應用全生命週期管理功能，並提供完善的服務監控及日誌功能，幫助用戶節省大量的運維成本。

總的來講，當企業在青雲QingCloud 使用容器服務時，他能夠享受到青雲提供的完整企業級容器服務平臺，包含 Kubernetes、etcd、Harbor、公有鏡像倉庫在內的一系列容器應用與服務，覆蓋鏡像倉庫、容器編排及管理，從而進行快速的容器應用開發、部署、升級。

舉幾個例子

打破異構環境，實現應用 CI/CD

傳統 DevOps 架構中，開發、測試和生產環境每每是異構的，服務部署方式沒有統一標準流程，這與實現高效應用持續集成/持續交付直接相互矛盾。基於 Docker 及 Kubernetes 構建的容器編排與調度平臺，實現統一應用的部署環境，提供標準化的部署及更新功能。

Docker 部署、管理與編排

Docker 是很是主流的容器應用，經過 QingCloud 容器平臺，用戶能夠便捷地部署 Docker 實例，管理自有和公有 Docker 鏡像，並經過 Kubernetes on QingCloud 實現 Docker 的調度與編排，從而構建基於 Docker 體系的應用系統。

構建微服務架構

隨着業務的快速增加和團隊規模的擴展，單體應用愈來愈難以知足敏捷開發以及縱向伸縮的需求，須要向微服務架構演進。使用微服務，一些技術債務勢必從開發轉到運維，傳統的人工編排運維模式很難應對服務數量擴張帶來的運維複雜度，這時候容器編排調度系統成爲必然的選擇。並且，微服務與容器結合使用時，微服務架構所具有的優點將被進一步放大。Kubernetes 對服務規範的定義，滾動升級以及自動伸縮能能力，正好知足了微服務架構對運維繫統的要求，下降了企業採用微服務架構的總體成本。