本文由 騰訊雲容器技術團隊 首發於騰訊雲+社群
1、背景
Kubernetes 很火,一大批網際網路公司早已領先一步,搭建起專有的 PaaS平臺,傳統企業們看到的 Kubernetes的趨勢,亦不甘落後,在試水的道上一路狂奔……
雖然,Kubernetes很火,並不代表可以“上手即用”,基於 Kubernetes的容器編排也不是簡單的“拿來主義”。在容器圈,除了 Kubernetes,還存在著 Mesos、Swarm等分屬不同陣營的容器叢集管理工具,以及基於這些工具的多個容器雲提供商。
騰訊雲在 2016年底決定開發容器產品,隨後組建容器技術團隊並進行技術選型,通過對不同編排工具的分析對比,最終選擇 Kubernetes 作為容器編排引擎,並且迅速在 2017 年初推出容器解決方案 CCS,為使用者提供託管 Kubernetes 的一站式服務。
隨著業務量的增加,騰訊雲容器團隊基於 Kubernetes,不停的增加和完善容器監控、日誌處理、容器 Registry 等關鍵特性,來保障使用者業務的平穩執行。在整個 2017 年的運營過程中,管理了數千個叢集、數十萬容器,以及業務高峰期的成倍擴容。
那麼,在 16年底,Kubernetes並未大熱時,騰訊云為何偏偏在諸多主流的編排引擎當中選擇 Kubernetes?騰訊雲 Kubernetes架構和資源排程原理是什麼樣的?在使用者託管服務中,又為何採用 Kubernetes來託管使用者 Kubernetes叢集的 Master?作為國內最大基於 Kubernetes的容器服務提供商,騰訊雲在 Kubernetes上還有哪些應用實踐…… 本文將帶著這些疑問,為你一一揭開騰訊雲基於 Kubernetes的 PaaS平臺神祕面紗。
2、為何選用 Kubernetes?
容器技術無疑是近幾年最熱門的技術之一,很多公司或者行業已經把容器作為自己的測試環境以及正式環境,正式上跑一些業務。騰訊緊隨外界技術發展的潮流,在三年之前,騰訊雲的基礎平臺部門開始容器方面的技術實踐,經過三年時間的積累,騰訊雲目前已經有很多業務跑在容器平臺上。
在最開始的容器產品技術選型階段,騰訊雲也曾對比過 Kubernetes、Docker Swarm、 Mesos:
Kubernetes的核心是如何解決自動部署,擴充套件和管理容器化(containerized)應用程式。它支援資源排程、服務發現、服務編排、資源邏輯隔離、服務自愈、安全配置管理等。
Mesos是一個分散式核心,核心理念是資料中心作業系統(DCOS),為了解決 IaaS層的網路、計算和儲存問題,所以 Mesos的核心是解決物理資源層的問題。它同時支援 Marathon、 Kubernetes 和 Swarm 等多種框架,Mesosphere 也是 Kubernetes 生態的一員。
Swarm:從 Docker1.12版本開始,Swarm隨 Docker一起預設安裝釋出,也由於隨 Docker引擎一起釋出,無需額外安裝,配置簡單。它支援服務註冊、服務發現,內建 Overlay Network以及 Load Balancer。Swarm是與 Docker CLI非常類似的操作命令,對熟悉 Docker的人非常容易上手學習。
綜上來看,每一種工具都有自己的核心理念。
但是,騰訊雲最終選擇了 Kubernetes, 現在看來這個選擇無比正確。 在技術選型上,除了編排引擎自身的核心特性,騰訊雲也主要從以下幾個方面進行了評估。

注:表格裡的材料是當初選型時調研的情況,上述編排工具現在的特性已經有了新變化。
從整個行業來看,業界的技術架構正在大規模向微服務遷移,容器技術天生就是部署微服務的最佳方式,騰訊雲擁有海量的業務架構,而 Kubernetes 的使用讓部署大規模的微服務更加容易,這也是騰訊雲選擇 Kubernetes的主要原因,另外騰訊雲選擇 Kubernetes還考慮了其它優勢,如:
出身名門 Google,其開發和設計受到了 Google著名的 Borg系統的影響;
GitHub上關注 Kubernetes專案和提交程式碼的開發者非常多,社群活躍,如果遇到問題,通過社群諮詢和解決 問題速度也會比較快。
Kubernetes可以很好的支援有狀態的服務。
Kubernetes 是近 3 年來社群熱度最高的專案,Linux 基金會也成立了 CNCF來加強社群運作,不僅對 Kubernetes 進行管理,還對相關專案進行有序的運作,保證了整個技術棧穩定和蓬勃的發展。Kubernetes技術相比Docker swarm和Mesos 學習難度更高,騰訊云為此提供了免費容器實驗室, 幫助開發者快速入門學習kubernetes,感性趣的讀者可以點選【閱讀原文】瞭解詳情。
3、騰訊雲目前有哪些容器解決方案?
騰訊雲 PaaS平臺發展至今已有了豐富的容器解決方案, 包括但不限於:騰訊雲 Kubernetes託管服務、單容器例項服務、TencentHub服務、Flow Engine服務、CCI持續整合服務等,以及基於 Kuberentes 的 TensorFlow 和 Spark 解決方案,幫助使用者在使用容器解決方案的同時進行資料計算和模型訓練。

騰訊雲 Kubernetes服務:基於原生 kubernetes 提供以容器為核心的、高度可擴充套件的高效能容器管理服務。騰訊雲容器服務完全相容原生 kubernetes API ,擴充套件了騰訊雲的 CBS、CLB 等 kubernetes 外掛,為容器化的應用提供高效部署、資源排程、服務發現和動態伸縮等一系列完整功能,解決使用者開發、測試及運維過程的環境一致性問題,提高大規模容器叢集管理的便捷性,幫助使用者降低成本,提高效率。
單容器例項服務:基於 Clear Linux 技術提供的單容器例項解決方案,通過單容器例項服務享受容器的便捷、虛擬機器級別的隔離, 像使用虛擬機器一樣如絲般順滑的來使用容器,非常試用於通過容器來進行批量計算、通過容器來快速部署個人站點。不依賴 VM的容器在配置和使用時間上更靈活,提供了一種更低成本的計算資源。目前,但容器例項服務正在內測階段。
TencentHub服務:在雲原生應用盛行的今天,僅僅提供 Git 服務或 Container 映象儲存的 Hub 已經無法滿足使用者在日常開發和運維過程中的種種需求。構造支援多種檔案格式、容器映象格式、編排方案的雲原生 Hub 能更好的降低使用者的架構向雲原生遷移。 TencentHub不僅僅提供一個私有映象的儲存,同時提供了 Helm包、二進位制檔案等檔案儲存。
DevOps 產品:DevOps 任務容器化、資源及執行全託管至 Kubernetes、提供給使用者一個全生命週期的 Workflow,完成容器構建、測試和部署等 DevOps 流程,支援使用者通過介面拖拽定義 Workflow ,支援 Workflow 定義檔案匯入等功能,和騰訊雲已有基礎服務和 DevOps 服務打通。核心引擎開源到容器社群,元件庫作為配套功能同時開源。
4、騰訊雲是如何基於 K8S做容器叢集的管理?
騰訊雲容器服務應用編排
Kubernetes原生的方案中,基於服務粒度對系統元件進行管理,支援服務註冊發現和路由管理。對於一個服務提供多種不同的資源描述型別,比較常用的有 Deployment、Job、CronJob、Stateful、Daemonset。
騰訊雲容器服務參考社群 Helm的實現形式,在容器服務中實現了完整的應用編排管理功能。騰訊雲容器服務編排服務主要分為配置管理,應用模板管理,基於應用的服務組管理幾個主要部分。

配置管理
配置管理是指將應用中常變的值以變數的形式替代,配置項支援多版本,方便使用者進行更新和回滾應用。關於配置管理的實現,騰訊雲支援三種實現方式:
Helm的模板檔案支援變數渲染
Kubernetes的 ConfigMap中環境變數方式
Kubernetes的 ConfigMap通過 Volume方式進行資料填充
其主要作用包括:
通過提取出多個環境中不同的部分,支援同一套系統在多個環境中部署。
提取出服務中經常變更的部分,實現服務的靈活變更。並且通過配置檔案的版本管理,可以很好的對變更進行追溯和回滾。
通過配置項,可以隱含的實現多個服務直接依賴關係的管理。例如:服務 A需要訪問服務 B的,一般情況下依賴於服務 B的名稱。這種情況下,將服務 B的名稱提取成為一個配置項,而將配置項傳遞給服務 A。這樣在不同環境中,服務 B名稱的改變,服務 A能自動感知,不需要單獨修改服務 A的引數。
應用模板
應用模板包括多個服務的定義加一個預設配置,通過應用模板 +配置項的組合,方便使用者部署相同應用的不同環境。主要用於描述一個或多個服務的定義,服務的定義支援原生的 Yaml語法,但可以通過 GoTemplate的方式定義對應的變數。其主要作用為:
實現應用的快速克隆。由於應用的相關資訊已經通過對應的 Template檔案進行了描述,複製應用的過程只需要針對性的修改應用的配置,其他結構資訊不需要進行改變。
應用的多環境部署。在多個環境中,實現應用的部署,也不需要關係每個服務具體的部署資訊,只需要在不同環境下修改環境對應的配置,即可以通過應用模板實現在新環境應用的快速部署。
更高階的功能,通過應用市場可以下載通用的模板,快速的部署應用。例如:在 Helm(Charts)的應用市場 https://kubeapps.com/,已經打包好了 100+應用的模板檔案。直接下載對應的應用模板就可以實現應用的部署。
應用
應用包括描述多個服務以及這些服務間的相互呼叫依賴關係 ,方便使用者管理多個服務。應用可以理解為多個服務的組合,多個服務會統一進行展示,服務支援按照應用進行搜尋。多個服務的配置項,統一的通過同一個配置進行管理。通過服務組的方式,管理多個服務。可以簡化多個服務管理的複雜度。
應用中的服務支援單獨編輯,部署和更新。同時服務支援差異化比較,方便使用者檢視兩次修訂之間的差異。在服務編輯時,自動提取出對應的變數,簡化配置的過程。並支援服務回滾功能,支援服務回滾到上一個版本。
用 K8S託管使用者 K8S叢集的 Master
與其他雲服務商不同的是,騰訊云為使用者管理 Master 節點,最重要的挑戰是為了保證使用者 Kubernetes 叢集的高可用,將使用者 Kubernetes 叢集的 Master 節點的程式以容器方式執行,發揮 Kubernetes 的優勢提供穩定保障。
在這個過程中,隨著託管叢集數量的增加,Kubernetes 的 Master 節點的負載也越來越高,騰訊雲提供的 Kubernetes 託管服務面臨巨大的穩定性挑戰:
多叢集共享 ETCD面臨效能瓶頸、運維困難、可用性較難持續保障
大量小叢集產生 master伺服器成本增加,可用性、效能較難保障
用 agent管理節點,隨叢集增加安裝包、證照、配置越發難以維護,更新回滾困難
提供給使用者的監控與後臺使用的監控是完全不同的兩套,監控物件與環境不統一,維護困難
Kubernetes為高效運維而生,為什麼運維起來卻這麼難?騰訊云為使用者提供了高效的 Kubernetes服務,為什麼自己做不到? 通過多次的技術方案碰撞,騰訊雲最終選擇用 Kubernetes來管理 Kubernetes的方案,讓自己成為自己的第一個使用者。

如上圖,騰訊雲將使用者叢集 Master 節點的元件全部使用容器的方式部署在一個 Kubernetes 叢集裡進行管理,最大限度的利用了容器的優勢和 Kubernetes 本身的能力,通過這樣的部署方案:
使用者叢集 Master不再獨佔雲主機,解決成本問題
健康檢查即可實現基本 HA,多副本可提供更高可用性
單個使用者叢集 Master相關資料放在同一個 namespace下
無需額外 db儲存使用者叢集版本資訊
升級時備份 namespace下資料即可快速回滾
無需開發、維護額外的 agent
騰訊雲 Kubernetes高可用託管架構解析
用 K8S管理 K8S方案說起來簡單,但將使用者的所有 Master 節點的元件全部使用容器的方式部署在一個 Kubernetes 叢集裡,其實現過程也並不容易。具體到落地實踐上,騰訊雲是如何做的呢?下圖為騰訊雲的 Kubernetes高可用託管架構。

託管服務中將整個平臺分為控制面和資料面兩層。控制面節點中駐留的是使用者 Kubernetes 叢集的 Master 相關容器和騰訊雲容器服務的服務管理服務節點;資料面的節點是客戶執行業務的節點。
服務管理節點是由一組高可用的 Kubernetes Master 節點組成,同時包括一組高可用的 etcd 叢集。服務管理節點外的其它機器都屬於該 Kubernetes 的 Node 節點。當使用者在騰訊雲的控制檯申請一個 Kubernetes 叢集時,在這些 Node 節點上把 etcd/api-server/controller/scheduler 等 Kuberneter Master 必須元件以 Kubernetes Controller 的方式部署在叢集內,並且通過 ingress 暴露到 VPC 。使用者 Node 節點在初始化時指定要加入的 Kubernetes 叢集。
採用以上架構方案,當使用者叢集負載升高的時候,可以快速啟動更多的容器應對訪問壓力。同時無需開發額外的 agent 管理 Master 節點,減少管理環節有效的降低運維難度。騰訊雲可以通過容器的滾動升級,快速為使用者升級到最新的 Kubernetes 版本,享用最新的特性。可以方便的為客戶部署多種版本的 Kubernetes ,甚至是使用者的定製版本。
5、如何用騰訊雲容器解決方案部署微服務?
騰訊雲 CCS解決方案介紹
微服務架構適用於構建複雜的應用,騰訊雲 CCS容器解決方案將單體式應用從不同緯度拆分成多個微服務,每個微服務的內容使用一個 Docker 映象管理。在功能不變的情況,應用拆分成了多個可管理的服務,使得每個單體的服務更容易理解、開發和維護。

不同的微服務也可以由不同的團隊來開發,開發團隊可自由選擇開發技術和程式語言等,每個服務又可獨立部署、獨立擴充套件。例如 Web 應用程式可以分割成一組更簡單的外部服務及多組內部服務。
小紅書基於騰訊雲的微服務改造實踐
小紅書是一家發展非常快速的公司,技術團隊在急劇增加的同時技術棧也在不斷變遷。以前小紅書的研發團隊採用的是純 Python 的技術環境,隨著業務的發展,不同的團隊在做 Java、Go、Node等不同方向嘗試 ,同時在每年電商大促時,擴容在現有模式也很耗時耗力。為了為了支撐業務的發展, 小紅書利用騰訊雲的 CCS解決方案對業務系統進行微服務化改造。
在微服務改造的過程中,小紅書基於騰訊雲容器服務搭配 Jenkins、GitLab、Prometheus 和 Spinnaker等開源元件,以最小的投入,最低的開發量快速的實現容器化微服務架構。

上圖是小紅書之前的應用上線的過程,開發向運維提需求,需要多少臺伺服器,運維依據需求去做初始化並交付給開發。現在小紅書有一個運維平臺,所有伺服器的部署都是由這個平臺來完成的,平臺呼叫騰訊雲 API 生成伺服器,做環境初始化,配置監控和報警,交付給開發的是一個標準化好的伺服器。
如上圖,開發者拿到伺服器準備線上釋出時用 Jenkins 觸發指令碼的方式:用 Jenkins 的指令碼做測試,執行程式碼推送。當需要新加一臺伺服器或者下線一臺伺服器,要去修改這個釋出指令碼。 釋出流程大概為:Jenkins 指令碼先往 beta 環境發,開發者在 beta 環境裡做自測,自測環境沒有問題就全量發。
經過架構的系列微服務改造實踐,小紅書的資源利用率提高了 100%, 計算資源減少將近 1倍,穩定支撐了雙 11等大型促銷活動。除了應用於微服務架構改造,CCS解決方案也能夠根據業務執行情況,提供叢集和服務兩個層級的彈性伸縮能力,併為持續整合與持續交付提供的高效的 DevOps 環境。
6、未來規劃
在 PaaS平臺的未來規劃上,騰訊雲將會提供更多的容器基礎解決方案,支援包括 Docker、OCI、Kata 等容器引擎和映象格式。同時推出更多配套的 DevOps 服務,為使用者提供完整的 PaaS + DevOps 開發部署環境。
據悉,騰訊雲單容器例項解決方案 CIS計劃在 5 月底釋出公測,使用者可以通過 CIS從容器 Image 當中快速建立容器例項。同時提供 DevOps 編排引擎的 Tencent Hub 的一部分已經上線,計劃將在 5 月底正式釋出公測,而在黑石上部署的 CCS 解決方案已上線。
問答
如何在已存在的Docker容器上執行命令?
相關閱讀
Docker容器技術
容器時代的DevOps部署
打破神話:容器vs虛擬機器
此文已由作者授權騰訊雲+社群釋出,原文連結:https://cloud.tencent.com/developer/article/1077383?fromSource=waitui