Kubernetes 實戰 （一） -- 泛 kubernates 導論

Kubernetes 是谷歌推出的一個工業級的容器編排平臺,允許自動化部署、管理和擴容容器化應用，它現在已成為容器編排的事實標準， 倉庫地址

目錄

k8s 由來

是什么 -- 分布式集群自動（自助）化運維舵手

需求驅動 -- 微服務化后的分布式部署集群

技術驅動 -- 輕量級容器化技術

高動態集群運維抽象模型 DCOM

應用集群化部署、運維的一般流程

抽象 高動態集群運維模型 DCOM

開源實作

k8s 由來

Kubernetes 是希臘語，中文翻譯是“舵手”或者“飛行員”，其實最常用的是其簡稱 k8s，即將收尾k和s之間的8個字母“ubernete ”替換為“8”而導致的一個縮寫，和編程界最常用的另一個縮寫 i18s - internationalization（國際化）類似，

是什么 -- 分布式集群自動（自助）化運維舵手

k8s 是分布式集群、自動（自助）化運維 舵手，在輕量級容器（如docker）上，實作分布式集群的高動態運維和服務治理功能，完善DevOps體系，模糊了Dev和Ops的界限，誕生于以下2大重要背景

• 需求驅動 -- 微服務化后的分布式部署集群

SOA以及微服務流行的背景下，單體應用被拆分為數十微服務、多機部署數百實體，人工部署和管理既繁重、亦冗余，甚至不可能，因此誕生了以 k8s 為代表的分布式集群自動化運維工具，反之，傳統單體應用、單機部署、運維的場景下，是不會產生、也不需要的k8s等復雜編排工具，無需過度設計，形而上學，

• 技術驅動 -- 輕量級容器化技術

以 Docker 為代表的輕量級容器化技術，實作了單機百/千級數量容器秒級的部署速度和高擴展的api，為上層分布式集群下的容器編排提供了可能，

• Docker本質是什么？

Docker等輕量級容器技術是虛擬化方案，提升虛擬機的有效載荷比和性能，從而榨干 單機部署多服務 的極限，但并不是為了解決多機（分布式集群）運維的，所以才有 k8s、Apache Mesos 等集群容器編排工具的必要，

高動態集群運維抽象模型 DCOM

應用集群化部署、運維的一般流程

在通常的生產場景中，新迭代業務需求經開發、測驗后即交由運維，進入部署、上線流程，大致包括以下環節：

• 交付指定運維人員

一個專案團隊的運維人員往往是固定、關聯的，且其所有的運維作業都需滿足審計要求，標準、安全、留痕，因此運維人員通常由自己的固定賬戶，且最小化權限，降低風險，

• 評估、申請資源

業務團隊根據自身應用的特點，是IO密集型、還是CPU密集型，評估所需的CPU、記憶體、網路、存盤等資源，從而支持應用健康、持續、高效運行，

• 提交配置

各類配置是往往是應用運行的起步依賴，多套環境往往意味著多套配置，因此需要交付給運維人員正確的配置，避免混淆、錯誤運行，

• 部署應用集群

現在的業務應用大多是無狀態的，適合對等集群化部署，既解決了單點故障問題，又可以均衡分擔負載，

• 部署守護任務

監控、日志等提高應用可觀察性的周邊管理類服務往往以 Sidecar 的方式獨立部署，避免擠占核心服務的資源，保障核心服務的穩定，

• 部署負載均衡LB(VIP)

應用的多實體的對等集群，需要使用負載均衡器LB如Nginx統一代理請求、定制負載均衡策略，而非直接的、顯式的某一個具體的實體，否則失去了集群化的價值，同時為了保證LB的高可用，通常會部署多個LB代理，并使用VIP技術實作同一的對外標識，屏蔽內部故障切換細節，

• DNS系結域名

雖然通過 IP:Port 可以靜態訪問到暴露出來的服務（VIP），但 IP 并不是友好的語意化符號，且無法動態適用應用遷移等導致的IP改變情況，因此通常亦需要通過DNS協議系結語意化、識記友好的短符號，并解耦客戶端與服務端的靜態系結關系，

抽象 高動態集群運維模型 DCOM

高動態集群運維模型是對上述應用集群化部署、運維的一般流程抽象，以標準化、程式化的方式準確界定每一個環節，從而為可編程的分布式集群自助化部署和運維提供了理論支撐，主流開源的 kubernates、Apache Mesos 等均可看作其實作，

• Namespace （應用）命名空間

應用部署的第一步，本質是為某些應用或專案從整個集群上劃分、隔離出的子集群，一套龐大的分布式集群并不是為了部署某一個應用，而是多個應用共享的，因此進行應用級的劃分，讓應用安全、穩定運行在邏輯沙箱中，對應用本身、以及整個集群來說都是必須的，

• Authentication 認證 與 Authentization 鑒權

是對運維人員以及各類管理行程的抽象，以安全、受控的方式去實作審計要求的操作留痕、最小權限等原則，

• Resource 一切皆資源

分布式集群本身是由cpu、記憶體、網路、存盤等軟硬體資源的集合，而應用集群化部署和運維的本質是對集群各類資源如CPU、記憶體的動態規劃和治理，因此非常適合將各類資源抽象化，并使用REST風格API管理，

• Config 配置中心

常規的配置適合應用本身靜態相關的，并不具備集群化管理的特征，也無法動態關聯多個相關應用，集群化的動態配置Config，要求部署配置和應用配置解耦，從而實跨應用、跨實體的動態配置共享，即微服務中的 配置中心，

• Deploy 部署

部署的本質是在集群上安裝和運行一個需要占用一定集群資源（如cpu、記憶體）、提供某種服務的應用行程，也是最核心的環節，

部署本身不僅僅是應用行程本身，更包括和集群關聯的各類資源和策略，因此不能狹義的將部署與具體的應用形式對等，

部署應該屏蔽具體的應用形式，無論是各類程式包，如Java jar/war包，還是各類輕量級容器（如docker），甚至是虛擬機，對集群來說都是上層的、一致化的部署Deploy，

• Service 服務發現 & Gateway 服務網關

服務化 Service

分布式/微服務流行的背景下，服務化 Service 已是標準和共識，Service的本質是為一組動態的對等或相關行程集合提供對外一致的服務標記（服務名），從而在集群內天然實作服務發現（微服務的核心）的能力，

• 服務網關 Gateway

應用服務化、動態化后，需要一個統一的基于服務名的對外暴露能力，即服務網關 Gateway，該組件也是微服務的基礎設定，單個服務 Service 不應該直接通過暴露主機埠的形式暴露出去，既會擠占公共集群的主機埠，造成不必要的污染與浪費，也增加了直接對外暴露的風險，通過應用級的服務網關統一管理和暴露服務，內部規則透明、動態切換，更符合微服務動態化、而非靜態關聯的特征，

總結：從 Service 和 Gateway 可以看出 DCOM 天然是面向微服務的、高動態集群，而盡量避免上游生產和下游消費的直接關聯，中間增加動態的解耦機制，即 命名服務

開源實作

kubernates 并非唯一、也非最早的分布式集群應用編排工具，在整個應用架構的第四層容器編排層有眾多開源的實作，但都可以抽象看做 高動態集群運維模型 DCOM 的實作，

• Apache Mesos – 全而雜

最早、也是最強大的集群容器編排系統，為后面 Docker Swarm、甚至 kubernates 等后期之秀提供了集群應用編排的有效解決方案，但本身由Mesos 和 Marathon 兩套獨立 API，學習復雜，難于推廣和流行，2019年 Twitter 宣布不再支持，

• Docker Swarm - 簡陋

由 Docker 官方推出的容器編排系統，特征是開箱即用，可以滿足小規模集群、簡單部署場景，但本身功能過于簡陋，且不支持超大規模集群，因此并未在企業級市場成為主流，同樣是2019 年阿里云宣布不再支持，

• Kubernates - 事實標準 👍

Google 出品，必屬精品， kubernates 作為谷歌推出的后起之秀，吸收了 Apache Mesos 和 Docker Swarm 優點，客服了其缺點，并完美實作了 高動態集群運維模型 DCOM ，從市占率看已成為分布式集群容器編排工具的事實標準，并以成為 DevOps 趨勢下的必備技術堆疊，