Kubernetes 是谷歌推出的一個工業級的容器編排平台,允許自動化部署、管理和擴容容器化應用，它現在已成為容器編排的事實标準。
- 完整腦圖
- 倉庫 awesome-kubernetes
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 内置服務發現
分布式/微服務流行的背景下，服務化 Service 已是标準和共識，Service的本質是為一組動态的對等或相關程序集合提供對外一緻的服務标記（服務名），進而在叢集内天然實作服務發現（微服務的核心）的能力。
開源實作
kubernates 并非唯一、也非最早的分布式叢集應用編排工具，在整個應用架構的第四層容器編排層有衆多開源的實作，但都可以抽象看做 高動态叢集運維模型 DCOM 的實作。
- Apache Mesos
最早、也是最強大的叢集容器編排系統，為後面 Docker Swarm、甚至 kubernates 等後期之秀提供了叢集應用編排的有效解決方案。但本身由Mesos 和 Marathon 兩套獨立 API，學習複雜，難于推廣和流行，2019年 Twitter 宣布不再支援。
- Docker Swarm
- Kubernates - 事實标準 👍