## K8S是什麼？發展歷史 Kubernetes （簡稱 k8s）是 Google 在2014年開源的，對容器生命週期管理的開源平臺，致力於對容器叢集提供易於管理、高可用、彈性負載與故障轉移的能力，提高服務運維自動化的能力。 最初，Google 開發了一個叫 Borg 的系統（現在命名為Omega）來排程據說有20多億個容器和工作負載。在積累了 10 餘年經驗後，Google 決定重寫這個容器管理系統，並將其命名為 Kubernetes 貢獻給開源社群，讓全世界都能因此受益。 自從開源以來，K8S迅速獲得開源社群的追捧，包括RedHat、VMware、Canonical在內的有很大影響力公司加入到開發與推廣的陣營。 2017年是容器生態發展歷史中具有里程碑意義的一年。 在這一年，長期作為Docker競爭對手的[RKT容器](https://coreos.com/rkt/docs/latest/)一派的領導者CoreOS宣佈放棄自己的容器管理系統Fleet，未來將會把所有容器管理的功能移至Kubernetes之上去實現。 在這一年，容器管理領域的獨角獸Rancher Labs宣佈放棄其內建了數年的容器管理系統Cattle，提出了“All-in-Kubernetes”戰略，從2.0版本開始把1.x版本能夠支援多種容器管理工具的Rancher，“升級”為只支援Kubernetes一種容器管理系統。 在這一年，Kubernetes的主要競爭者Apache Mesos在9月正式宣佈了“[Kubernetes on Mesos](https://k8smeetup.github.io/docs/getting-started-guides/mesos/)”整合計劃，由競爭關係轉為對Kubernetes提供支援，使其能夠與Mesos的其他一級框架（如[HDFS](https://docs.mesosphere.com/latest/usage/service-guides/hdfs/)、[Spark](https://docs.mesosphere.com/latest/usage/service-guides/spark/) 和[Chronos](https://mesos.github.io/chronos/docs/getting-started.html)，等等）進行叢集資源動態共享、分配與隔離。 在這一年，Kubernetes的最大競爭者Docker Swarm的母公司Docker，終於在10月被迫宣佈Docker要同時支援Swarm與Kubernetes兩套容器管理系統，事實上承認了Kubernetes的統治地位。這場已經持續了三、四年時間，以Docker Swarm、Apache Mesos與Kubernetes為主要競爭者的“容器戰爭”終於有了明確的結果。 時至今日，K8S 已經是發展最快、市場佔有率最高的容器編排系統，是業界標杆。 小結：Kubernetes是Google公司2014年開源的容器編排產品，經過多年的發展，已經成為容器編排領域的佼佼者，擁有最廣大的使用者群體 ## 應用部署容器化的發展歷程 要說K8S的作用，得先從容器的發展與優勢講起，大致可分為 傳統部署時代、虛擬化部署時代、容器部署時代  **傳統部署時代：** 早期，在物理伺服器上執行應用程式。無法為物理伺服器中的應用程式定義資源邊界，這會導致資源分配困難與資源浪費的問題。例如，如果在物理伺服器上執行多個應用程式，則可能會出現一個應用程式佔用大部分資源的情況，結果可能導致其他應用程式的效能下降。一種解決方案是在不同的物理伺服器上執行每個應用程式，但是由於資源利用不足而無法擴充套件，並且組織維護許多物理伺服器的成本很高。 **虛擬化部署時代：** 作為解決方案，引入了虛擬化功能，它允許您在單個物理伺服器的 CPU 上執行多個虛擬機器（VM）。虛擬化功能允許應用程式在 VM 之間隔離，並提供安全級別，因為一個應用程式的資訊不能被另一應用程式自由地訪問。 因為虛擬化可以輕鬆地新增或更新應用程式、降低硬體成本等等，所以虛擬化可以更好地利用物理伺服器中的資源，並可以實現更好的可伸縮性。 每個 VM 是一臺完整的計算機，在虛擬化硬體之上執行所有元件，包括其自己的作業系統，這勢必也會造成資源的浪費、效能的下降 **容器部署時代：** 容器類似於 VM，但是它們具有輕量級的隔離屬性，可以在應用程式之間共享作業系統（OS）。因此，容器被認為是輕量級的。容器與 VM 類似，具有自己的檔案系統、CPU、記憶體、程序空間等。由於它們與基礎架構分離，因此可以跨雲和 OS 分發進行移植。 容器因具有許多優勢而變得流行起來。下面列出了容器的一些**好處**： - **敏捷應用程式的建立和部署**：與使用 VM 映象相比，提高了容器映象建立的簡便性和效率。 - **持續開發、整合和部署**：通過快速簡單的回滾(由於映象不可變性)，提供可靠且頻繁的容器映象構建和部署。 - **關注開發與運維的分離**：在構建/釋出時而不是在部署時建立應用程式容器映象，從而將應用程式與基礎架構分離。 - **可觀察性**：不僅可以顯示作業系統級別的資訊和指標，還可以顯示應用程式的執行狀況和其他指標訊號。 - **跨開發、測試和生產的環境一致性**：在行動式計算機上與在雲中相同地執行。 - **雲和作業系統分發的可移植性**：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方執行。 - **以應用程式為中心的管理**：提高抽象級別，從在虛擬硬體上執行 OS 到使用邏輯資源在 OS 上執行應用程式。 - **鬆散耦合、分散式、彈性、解放的微服務**：應用程式被分解成較小的獨立部分，並且可以動態部署和管理 - 而不是在一臺大型單機上整體執行。 - **資源隔離**：可預測的應用程式效能。 - **資源利用**：高效率和高密度。 小結：相對於傳統物理機部署方式，虛擬機器部署將資源更好的隔離開來，使資源分配與隔離的問題解決，提高了資源使用率，但是由於其虛擬了硬體與OS，會浪費不必要的資源；容器部署繼承了虛擬機器部署的資源隔離優勢的同時，使用共享宿主機的硬體與OS的方式，資源消耗更少，由於與基礎架構進行了分離，可以做到良好的移植性 ## 為什麼需要 Kubernetes，它能做什麼? 容器是打包和執行應用程式的好方式。在生產環境中，如果一個容器發生故障，則啟動另一個容器。如此處理會不會更簡單？ K8s就是這麼做的！K8s 為您提供了一個可彈性執行分散式系統的框架，能滿足您的擴充套件要求、故障轉移、部署模式等。 Kubernetes 為您提供： - **服務發現和負載均衡** Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器，如果到容器的流量很大，Kubernetes 可以負載均衡並分配網路流量，從而使部署穩定。 - **儲存編排** Kubernetes 允許您自動掛載您選擇的儲存系統，例如本地儲存、公共雲提供商等。 - **自動部署和回滾** 您可以使用 Kubernetes 描述已部署容器的所需狀態，它可以以受控的速率將實際狀態更改為所需狀態。例如，您可以自動化 Kubernetes 來為您的部署建立新容器，刪除現有容器並將它們的所有資源用於新容器。 - **自動二進位制打包** Kubernetes 允許您指定每個容器所需 CPU 和記憶體（RAM）。當容器指定了資源請求時，Kubernetes 可以做出更好的決策來管理容器的資源。 - **自我修復** Kubernetes 重新啟動失敗的容器、替換容器、殺死不響應使用者定義的執行狀況檢查的容器，並且在準備好服務之前不將其通告給客戶端。 - **金鑰與配置管理** Kubernetes 允許您儲存和管理敏感資訊，例如密碼、OAuth 令牌和 ssh 金鑰。您可以在不重建容器映象的情況下部署和更新金鑰和應用程式配置，也無需在堆疊配置中暴露金鑰。 小結：K8S 提供了服務發現和負載均衡、儲存編排、自動部署和回滾、自動二進位制打包、自我修復、金鑰與配置管理等功能，能滿足您的擴充套件要求、故障轉移、部署模式等需求 ## Kubernetes 不是什麼 Kubernetes 不是傳統的、包羅永珍的 PaaS（平臺即服務）系統。它只提供了 PaaS 產品共有的一些普遍適用的功能，例如部署、擴充套件、負載均衡、日誌記錄和監視。但是，Kubernetes 不是單一的，預設解決方案是可選和可插拔的。Kubernetes 提供了構建開發人員平臺的基礎，但是在重要的地方保留了使用者的選擇和靈活性。 Kubernetes： - **不限制支援的應用程式型別**。Kubernetes 旨在支援極其多種多樣的工作負載，包括無狀態、有狀態和資料處理工作負載。如果應用程式可以在容器中執行，那麼它應該可以在 Kubernetes 上很好地執行。 - **不部署原始碼，也不構建您的應用程式**。持續整合(CI)、交付和部署（CI/CD）工作流取決於組織的文化和偏好以及技術要求。 - **不提供應用程式級別的服務作為內建服務**，例如中介軟體（例如，訊息中介軟體）、資料處理框架（例如，Spark）、資料庫（例如，mysql）、快取、叢集儲存系統（例如，Ceph）。這樣的元件可以在 Kubernetes 上執行，並且/或者可以由執行在 Kubernetes 上的應用程式通過可移植機制（例如，[開放服務代理](https://openservicebrokerapi.org/)）來訪問。 - **不指定日誌記錄、監視或警報解決方案**。它提供了一些整合作為概念證明，並提供了收集和匯出指標的機制。 - **不提供或不要求配置語言/系統**（例如 jsonnet），它提供了宣告性 API，該宣告性 API 可以由任意形式的宣告性規範所構成。 - **不提供也不採用任何全面的機器配置、維護、管理或自我修復系統**。 - 此外，**Kubernetes 不僅僅是一個編排系統，實際上它消除了編排的需要**。編排的技術定義是執行已定義的工作流程：首先執行 A，然後執行 B，再執行 C。相比之下，Kubernetes 包含一組獨立的、可組合的控制過程，這些過程連續地將當前狀態驅動到所提供的所需狀態。從 A 到 C 的方式無關緊要，也不需要集中控制，這使得系統更易於使用且功能更強大、健壯、彈性和可擴充套件性。 小結：K8S 提供了基礎的容器編排平臺，但並不是大而全地將所有可能的功能都直接整合進來，而是做成可插拔的形式，可以做到因地適宜地組織與管理叢集，擁有很高的靈活性。 ## Kubernetes 架構與元件  K8s的架構如上圖，左邊虛線框的部分稱為 控制平面（Control Plane），右側為 叢集節點（Nodes） 控制平面所在的主機稱為 Master 節點，其餘稱為 Nodes 執行節點 簡單按這兩種角色來講，Master節點負責發號施令（下發命令、監控節點與容器狀態），而 Nodes 節點負責幹活 ### 控制平面（Control Plane）元件 控制平面的元件對叢集做出全域性決策(比如排程)，以及檢測和響應叢集事件 控制平面元件可以在叢集中的任何節點上執行。簡單起見，通常會將控制平臺配置在一臺主機上，也可以配置高可用形式。 下邊我們介紹下 控制平面中的幾大元件： - **kube-apiserver**：Master節點上負責提供 Kubernetes API 服務的元件；它是 Kubernetes 控制面的前端，由它來接收來自 CLI 與 UI 的指令 - **etcd**：是兼具一致性和高可用性的鍵值資料庫，可以作為儲存 Kubernetes 所有叢集資料的後臺資料庫。 - **kube-scheduler**：Master節點上的元件，該元件監視那些新建立的未指定執行節點的 Pod，並選擇節點讓 Pod 在上面執行。 - **kube-controller-manager**：控制器通過 apiserver 監控叢集的公共狀態，並致力於將當前狀態轉變為期望的狀態。從邏輯上講，每個[控制器](https://kubernetes.io/docs/admin/kube-controller-manager/)都是一個單獨的程序，但是為了降低複雜性，它們都被編譯到同一個可執行檔案，並在一個程序中執行。包含以下幾種控制器： - 節點控制器（Node Controller）: 負責在節點出現故障時進行通知和響應。 - 副本控制器（Replication Controller）: 負責為系統中的每個副本控制器物件維護正確數量的 Pod。 - 端點控制器（Endpoints Controller）: 填充端點(Endpoints)物件(即加入 Service 與 Pod)。 - 服務帳戶和令牌控制器（Service Account & Token Controllers）: 為新的名稱空間建立預設帳戶和 API 訪問令牌 - **cloud-controller-manager**：雲控制器管理器負責與基礎雲提供商互動，以下控制器具有云提供商依賴性: - 節點控制器（Node Controller）: 用於檢查雲提供商以確定節點是否在雲中停止響應後被刪除 - 路由控制器（Route Controller）: 用於在底層雲基礎架構中設定路由 - 服務控制器（Service Controller）: 用於建立、更新和刪除雲提供商負載均衡器 - 資料卷控制器（Volume Controller）: 用於建立、附加和裝載卷、並與雲提供商進行互動以編排卷 ### 節點（Node） 元件 節點元件在每個節點上執行，維護執行的 Pod 並提供 Kubernetes 執行環境 節點元件包含兩大元件： - **kubelet**：一個在叢集中每個節點上執行的代理。它保證容器都執行在 Pod 中。 kubelet 接收一組通過各類機制提供給它的 PodSpecs，確保這些 PodSpecs 中描述的容器處於執行狀態且健康。kubelet 不會管理不是由 Kubernetes 建立的容器。 - **kube-proxy**：是叢集中每個節點上執行的網路代理，實現 Kubernetes [Service](https://kubernetes.io/docs/concepts/services-networking/service/) 概念的一部分。 kube-proxy 維護節點上的網路規則。這些網路規則允許從叢集內部或外部的網路會話與 Pod 進行網路通訊。 如果作業系統提供了資料包過濾層並可用的話，kube-proxy會通過它來實現網路規則。否則，kube-proxy 僅轉發流量本身 - **容器執行環境(Container Runtime)**：容器執行環境是負責執行容器的軟體。K8s支援多種容器執行環境：Docker、containerd、cri-o、rklet 以及任何實現K8s容器執行環境介面的技術。 ### 外掛(Addons) - DNS：所有 Kubernetes 叢集都應具有 DNS。叢集 DNS 還是一個 DNS 伺服器，它為 Kubernetes 服務提供 DNS 記錄。 - 使用者介面(Dashboard)：Kubernetes 叢集基於 Web 的 UI。它使使用者可以管理叢集中執行的應用程式以及叢集本身並進行故障排除。 [Dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) 是 Kubernetes 叢集的通用基於 Web 的 UI。它使使用者可以管理叢集中執行的應用程式以及叢集本身並進行故障排除。 - 容器資源監控：將關於容器的一些常見的時間序列度量值儲存到一個集中的資料庫中，並提供用於瀏覽這些資料的介面。 - 叢集層面日誌：負責將容器的日誌資料儲存到一個集中的日誌儲存中，該儲存能夠提供搜尋和瀏覽介面。 小結：K8s架構分為控制平臺位於的Master節點與執行節點Node
控制平臺包含：

kube-apiserver（訪問入口，接收命令）

etcd（KV資料庫，儲存叢集狀態與資料）

kube-scheduler（監控節點狀態，排程容器部署）

kube-controller-manager（監控叢集狀態，控制節點、副本、端點、賬戶與令牌）

cloud-controller-manager（控制與雲互動的節點、路由、服務、資料卷）

執行節點包含：

kubelet（監控與實際操作容器）

kube-proxy（每個節點上執行的網路代理，維護網路轉發規則，實現了Service）

容器執行時環境CRI（支援多種實現K8s CRI的容器技術）

## 本文總結 Kubernetes 作為容器編排的領航者，將容器化的優勢發揮得淋漓盡致，排除了容器難於管理的問題。 按角色來看，K8s可以分為兩部分，控制平面與執行節點，控制平臺通過一系列接收指令、監控、部署排程等功能的元件組成，最主要的有kube-apiserver、etcd、kube-scheduler、kube-controller-manager；執行節點包含負責監控與具體幹活的kubelet和維護網路規則的kube-proxy ### 參考文章 - https://kubernetes.io/docs/concepts/overview/comp