談到Kubernetes就不得不談到容器。幾年前容器技術大熱，現在基本歸於平淡，之前大家提到的容器通常是指Docker容器，甚至很多人認爲容器就等同於Docker，還有很多人像操作虛擬機一樣使用容器。
Kubernetes是Google基於其內部使用的Borg改造而成的一個通用容器編排調度器，於2014年被髮布到開源社區，並於2015年被捐贈給Linux基金會下屬的雲原生計算基金會（CNCF），Kubernetes也是GIFEE（Google Infrastructure For Everyone Else）中的一員，GIFEE中的其他成員還有HDFS、HBase、ZooKeeper等。
CNCF中託管的項目一般會遵循一套完善的成長流程，畢竟經過沙盒、孵化和畢業這三個階段。Kubernetes是CNCF託管的所有項目中第一個成功畢業的項目，整個CNCF技術棧都是圍繞它而建立的。Kubernetes是雲原生項目中最重要的組件，其目標不僅僅是成爲一個編排系統，更是爲用戶提供一個規範，讓用戶可以描述集羣的架構，定義服務的最終狀態，並讓系統自動維持在這個狀態。
現如今，雲服務已經可以爲我們提供非常穩定的基礎設施了，但是業務上雲卻成了一個難題。Kubernetes的出現與其說是爲了提供最初的容器編排解決方案，倒不如說是爲了解決應用上雲（即實現雲原生應用）這個難題。CNCF中託管的一系列項目致力於對雲原生應用的整個生命週期進行管理，通過開源軟件爲用戶提供部署平臺、日誌收集、Service Mesh（服務網格）、服務發現、分佈式追蹤、監控、安全等各個領域的解決方案。
1. Kubernetes架構
談到雲計算就必然談到分佈式，Kubernetes作爲雲原生計算的基礎組件，本身也採用了分佈式架構。圖7-1展示了Kubernetes的架構。
Kubernetes主要由以下幾個核心組件構成。
- etcd：協同存儲，負責保存整個集羣的狀態，通常會部署奇數個節點以保證高可用性。
- API：提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制。
- controller manager：負責維護集羣的狀態，執行故障檢測、自動擴展、滾動更新等操作。
- Scheduler：負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上。
- Kubelet：作爲工作節點負責維護容器的生命週期，同時也負責對容器存儲接口（CSI）和容器網絡接口（CNI）進行管理。
- 容器運行時（對應圖7-1中的Docker）：負責鏡像管理，實現Pod和容器的真正運行。
- Proxy：負責提供集羣內部的服務發現和負載均衡。
除了核心組件，Kubernetes中還有一些推薦使用的插件，其中有的已經成爲CNCF中的託管項目，具體如下。 - CoreDNS：負責爲整個集羣提供DNS服務。
- Ingress Controller：負責爲服務提供外網入口。
- Prometheus：負責資源監控。
- Dashboard：負責提供GUI。
- Federation：負責提供跨可用區的集羣。
2.分層設計理念及架構模型
Kubernetes的架構設計理念與Linux的分層架構設計理念類似，圖7-2展示了Kubernetes分層架構模型。
如圖7-2所示，Kubernetes分層架構中包含以下幾部分。
- 核心層：Kubernetes的核心，負責對外提供API構建高層應用，對內提供插件式應用執行環境。
- 應用層：負責部署和路由，可部署的應用包括無狀態應用、有狀態應用、批處理任務、集羣應用等，路由的類型主要有服務發現、DNS解析等。
- 管理層：負責自動化（如自動擴展、動態部署等），以及策略（RBAC、ResourceQuota、NetworkPolicy等）管理。
- 接口層：主要包括kubectl命令行工具、客戶端SDK等用於客戶端操作的庫，以及集羣聯邦等實用工具。
- 雲原生生態系統：接口層之上的負責容器集羣管理調度的生態系統，該系統可以劃分爲兩個範疇。
- Kubernetes內部：包括CRI（容器運行時接口）、CNI（容器網絡接口）、CSI（容器存儲接口）、鏡像倉庫、雲供應商、身份供應商等。
整個雲原生的生態都是以Kubernetes爲基石構建的，Kubernetes自誕生以來便迅速發展，正在向原有的非雲原生領域擴張。
3.設計哲學
Kubernetes之所以能夠如此快速地發展，不僅是因爲其背後有Google公司的大力支持和繁榮社區的全力協助，更是因爲它本身蘊含着優秀的設計哲學。Kubernetes並未採用常見的命令式設計模式，而是採用了聲明式設計模式。
由於雲原生應用程序是面向在雲環境中運行的應用程序而設計的，因此，雲原生應用及其基礎設施，與傳統應用的交互方式並不相同。在雲原生應用程序中，與任何事物進行通信都是通過網絡實現的，用戶編寫YAML格式的應用程序編排文件，然後Kubernetes將其轉換爲JSON格式，並通過RESTful HTTP的方式與API Server進行通信。Kubernetes組件本身則通過gRPC進行通信。
傳統的應用程序通常通過消息隊列、共享存儲或觸發shell命令的本地腳本來自動執行任務，通過對發生的事件做出響應（例如，用戶點擊【提交】按鈕或是運行部署腳本）來完成交互。
Kubernetes的控制器一直監聽API Server。一旦發現有應用狀態變更，就會聲明一個新的狀態，並相信API Server和kubelet會進行必要的操作來調整應用狀態，直至與聲明的狀態一致爲止。
聲明式通信規範了通信模型，一系列API聲明規範了應用程序的部署原語，並且將功能實現從應用程序中轉移到了遠程API或服務端點上，從而讓應用程序達到預期狀態。這樣有助於簡化應用程序，並使它們的行爲更具可預測性。
運行雲原生應用程序的基礎設施與傳統應用程序的基礎設施不同。基礎設施不僅僅提供了應用運行所需的資源，還承擔了許多對應用程序進行生命週期管理時的責任。
Kubernetes優秀的分佈式架構設計，給用戶提供了衆多可擴展的接口，可以讓用戶很方便地擴展自己的運行時、網絡和存儲插件，同時還可以讓用戶通過CRD管理自己的分佈式應用。採用CRD聲明式配置方式時，用戶可以利用Kubernetes的原語快速編排出一個雲原生應用。
雲原生應用程序通過將應用分解爲更小的服務來降低代碼複雜性，並且可以藉助統一的日誌、監控、審計平臺加強應用程序的可觀察性，Kubernetes僅實現了應用程序的部署和資源調度，因此還需要一些新的工具來自動管理激增的服務和應用生命週期中的其他階段，例如，使用Ballerina、Pulumi這樣的雲原生編程語言便可以簡化基於Kubernetes平臺的微服務應用的集成。
相關文章：
架構新紀元（一）：從分佈式架構到雲原生架構
架構新紀元（二）：什麼是雲原生？
架構新紀元（三）：雲原生的生態圈
架構新紀元（四）：觀察分佈式服務
本文節選自圖書《未來架構：從服務化到雲原生》。本書對快速演進中的雲原生數據架構、典型分佈式數據庫中間件進行了剖析，重點介紹 Service Mesh 等新興概念，創新性地提出了 Database Mesh 的理念，深度揭祕 Apache 項目——ShardingSphere。
購買鏈接： https://u.jd.com/sbmG4Y
作者簡介：
張亮
京東數科數據研發負責人，Apache ShardingSphere 發起人兼 PPMC 成員。熱愛分享，擁抱開源，主張代碼優雅化，擅長以 Java 爲主的分佈式架構以及以 Kubernetes 和 Mesos 爲主的雲平臺的構建。ShardingSphere 已進入 Apache 軟件基金會，是京東集團首個進入 Apache 的開源項目，也是 Apache 首個分佈式數據庫中間件。
吳晟
Apache SkyWalking 創始人及 PPMC 成員，Apache ShardingSphere 原型作者及 PPMC 成員，Apache Zipkin 貢獻者，Apache 孵化器導師，CNCF 基金會 OpenTracing 標準化委員會成員，W3C Trace Context 規範貢獻者。擅長分佈式架構、性能監控與診斷、分佈式追蹤、雲原生監控等領域。
敖小劍
具有十七年軟件開發經驗，資深碼農，微服務專家，Cloud Native 擁護者，敏捷實踐者，Service Mesh 佈道師，ServiceMesher 中文社區聯合創始人。專注於基礎架構建設，對微服務、雲計算等相關技術有着深入研究和獨到見解。
宋淨超
螞蟻金服雲原生布道師，ServiceMesher 中文社區聯合創始人，Kubernetes 社區成員，Istio 社區成員，《Cloud Native Go》《Python 雲原生》《雲原生 Java》等圖書譯者。