傳統部署時代：

早期，各個組織機構在物理服務器上運行應用程序。無法爲物理服務器中的應用程序定義資源邊界，這會導致資源分配問題。例如，如果在物理服務器上運行多個應用程序，則可能會出現一個應用程序佔用大部分資源的情況， 結果可能導致其他應用程序的性能下降。一種解決方案是在不同的物理服務器上運行每個應用程序，但是由於資源利用不足而無法擴展， 並且維護許多物理服務器的成本很高。

虛擬化部署時代：

作爲解決方案，引入了虛擬化。虛擬化技術允許你在單個物理服務器的 CPU 上運行多個虛擬機（VM）。虛擬化允許應用程序在 VM 之間隔離，並提供一定程度的安全，因爲一個應用程序的信息 不能被另一應用程序隨意訪問。

虛擬化技術能夠更好地利用物理服務器上的資源，並且因爲可輕鬆地添加或更新應用程序 而可以實現更好的可伸縮性，降低硬件成本等等。

每個 VM 是一臺完整的計算機，在虛擬化硬件之上運行所有組件，包括其自己的操作系統。

容器部署時代：

容器類似於 VM，但是它們具有被放寬的隔離屬性，可以在應用程序之間共享操作系統（OS）。因此，容器被認爲是輕量級的。容器與 VM 類似，具有自己的文件系統、CPU、內存、進程空間等。由於它們與基礎架構分離，因此可以跨雲和 OS 發行版本進行移植。

容器因具有許多優勢而變得流行起來。下面列出的是容器的一些好處：

• 敏捷應用程序的創建和部署：與使用 VM 鏡像相比，提高了容器鏡像創建的簡便性和效率。

• 持續開發、集成和部署：通過快速簡單的回滾（由於鏡像不可變性），支持可靠且頻繁的 容器鏡像構建和部署。

• 關注開發與運維的分離：在構建 / 發佈時而不是在部署時創建應用程序容器鏡像， 從而將應用程序與基礎架構分離。

• 可觀察性：不僅可以顯示操作系統級別的信息和指標，還可以顯示應用程序的運行狀況和其他指標信號。

• 跨開發、測試和生產的環境一致性：在便攜式計算機上與在雲中相同地運行。

• 跨雲和操作系統發行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方運行。

• 以應用程序爲中心的管理：提高抽象級別，從在虛擬硬件上運行 OS 到使用邏輯資源在 OS 上運行應用程序。

• 鬆散耦合、分佈式、彈性、解放的微服務：應用程序被分解成較小的獨立部分， 並且可以動態部署和管理 - 而不是在一臺大型單機上整體運行。

• 資源隔離：可預測的應用程序性能。

• 資源利用：高效率和高密度。

爲什麼需要 Kubernetes，它能做什麼?

容器是打包和運行應用程序的好方式。在生產環境中，你需要管理運行應用程序的容器，並確保不會停機。例如，如果一個容器發生故障，則需要啓動另一個容器。如果系統處理此行爲，會不會更容易？

這就是 Kubernetes 來解決這些問題的方法！Kubernetes 爲你提供了一個可彈性運行分佈式系統的框架。Kubernetes 會滿足你的擴展要求、故障轉移、部署模式等。例如，Kubernetes 可以輕鬆管理系統的 Canary 部署。

Kubernetes 爲你提供：

• 服務發現和負載均衡

  Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器，如果進入容器的流量很大， Kubernetes 可以負載均衡並分配網絡流量，從而使部署穩定。

• 存儲編排

  Kubernetes 允許你自動掛載你選擇的存儲系統，例如本地存儲、公共雲提供商等。

• 自動部署和回滾

  你可以使用 Kubernetes 描述已部署容器的所需狀態，它可以以受控的速率將實際狀態 更改爲期望狀態。例如，你可以自動化 Kubernetes 來爲你的部署創建新容器， 刪除現有容器並將它們的所有資源用於新容器。

• 自動完成裝箱計算

  Kubernetes 允許你指定每個容器所需 CPU 和內存（RAM）。當容器指定了資源請求時，Kubernetes 可以做出更好的決策來管理容器的資源。

• 自我修復

  Kubernetes 重新啓動失敗的容器、替換容器、殺死不響應用戶定義的 運行狀況檢查的容器，並且在準備好服務之前不將其通告給客戶端。

• 密鑰與配置管理

  Kubernetes 允許你存儲和管理敏感信息，例如密碼、OAuth 令牌和 ssh 密鑰。你可以在不重建容器鏡像的情況下部署和更新密鑰和應用程序配置，也無需在堆棧配置中暴露密鑰。

Kubernetes 不是什麼

Kubernetes 不是傳統的、包羅萬象的 PaaS（平臺即服務）系統。由於 Kubernetes 在容器級別而不是在硬件級別運行，它提供了 PaaS 產品共有的一些普遍適用的功能， 例如部署、擴展、負載均衡、日誌記錄和監視。但是，Kubernetes 不是單體系統，默認解決方案都是可選和可插拔的。Kubernetes 提供了構建開發人員平臺的基礎，但是在重要的地方保留了用戶的選擇和靈活性。

Kubernetes：

• 不限制支持的應用程序類型。Kubernetes 旨在支持極其多種多樣的工作負載，包括無狀態、有狀態和數據處理工作負載。如果應用程序可以在容器中運行，那麼它應該可以在 Kubernetes 上很好地運行。

• 不部署源代碼，也不構建你的應用程序。持續集成 (CI)、交付和部署（CI/CD）工作流取決於組織的文化和偏好以及技術要求。

• 不提供應用程序級別的服務作爲內置服務，例如中間件（例如，消息中間件）、 數據處理框架（例如，Spark）、數據庫（例如，mysql）、緩存、集羣存儲系統 （例如，Ceph）。這樣的組件可以在 Kubernetes 上運行，並且 / 或者可以由運行在 Kubernetes 上的應用程序通過可移植機制（例如， 開放服務代理）來訪問。

• 不要求日誌記錄、監視或警報解決方案。它提供了一些集成作爲概念證明，並提供了收集和導出指標的機制。

• 不提供或不要求配置語言 / 系統（例如 jsonnet），它提供了聲明性 API， 該聲明性 API 可以由任意形式的聲明性規範所構成。

• 不提供也不採用任何全面的機器配置、維護、管理或自我修復系統。

• 此外，Kubernetes 不僅僅是一個編排系統，實際上它消除了編排的需要。編排的技術定義是執行已定義的工作流程：首先執行 A，然後執行 B，再執行 C。相比之下，Kubernetes 包含一組獨立的、可組合的控制過程， 這些過程連續地將當前狀態驅動到所提供的所需狀態。如何從 A 到 C 的方式無關緊要，也不需要集中控制，這使得系統更易於使用 且功能更強大、系統更健壯、更爲彈性和可擴展。

• Kubernetes 組件

• 當你部署完 Kubernetes, 即擁有了一個完整的集羣。

• 一個 Kubernetes 集羣由一組被稱作節點的機器組成。這些節點上運行 Kubernetes 所管理的容器化應用。集羣具有至少一個工作節點。

• 工作節點託管作爲應用負載的組件的 Pod 。控制平面管理集羣中的工作節點和 Pod 。爲集羣提供故障轉移和高可用性，這些控制平面一般跨多主機運行，集羣跨多個節點運行。

• 本文檔概述了交付正常運行的 Kubernetes 集羣所需的各種組件。

• 這張圖表展示了包含所有相互關聯組件的 Kubernetes 集羣。

• 雲控制器管理器是指嵌入特定雲的控制邏輯的 控制平面組件。雲控制器管理器使得你可以將你的集羣連接到雲提供商的 API 之上， 並將與該雲平臺交互的組件同與你的集羣交互的組件分離開來。

• 控制平面組件（Control Plane Components） 

• 控制平面的組件對集羣做出全局決策 (比如調度)，以及檢測和響應集羣事件（例如，當不滿足部署的 replicas 字段時，啓動新的 pod）。

• 控制平面組件可以在集羣中的任何節點上運行。然而，爲了簡單起見，設置腳本通常會在同一個計算機上啓動所有控制平面組件， 並且不會在此計算機上運行用戶容器。請參閱使用 kubeadm 構建高可用性集羣 中關於多 VM 控制平面設置的示例。

• kube-apiserver

• API 服務器是 Kubernetes 控制面的組件， 該組件公開了 Kubernetes API。API 服務器是 Kubernetes 控制面的前端。

• Kubernetes API 服務器的主要實現是 kube-apiserver。kube-apiserver 設計上考慮了水平伸縮，也就是說，它可通過部署多個實例進行伸縮。你可以運行 kube-apiserver 的多個實例，並在這些實例之間平衡流量。

• etcd

• etcd 是兼具一致性和高可用性的鍵值數據庫，可以作爲保存 Kubernetes 所有集羣數據的後臺數據庫。

• 您的 Kubernetes 集羣的 etcd 數據庫通常需要有個備份計劃。

• 要了解 etcd 更深層次的信息，請參考 etcd 文檔。

• kube-scheduler

• 控制平面組件，負責監視新創建的、未指定運行節點（node）的 Pods，選擇節點讓 Pod 在上面運行。

• 調度決策考慮的因素包括單個 Pod 和 Pod 集合的資源需求、硬件 / 軟件 / 策略約束、親和性和反親和性規範、數據位置、工作負載間的干擾和最後時限。

• kube-controller-manager

• 運行控制器進程的控制平面組件。

• 從邏輯上講，每個控制器都是一個單獨的進程， 但是爲了降低複雜性，它們都被編譯到同一個可執行文件，並在一個進程中運行。

• 這些控制器包括:

• 節點控制器（Node Controller）: 負責在節點出現故障時進行通知和響應

• 任務控制器（Job controller）: 監測代表一次性任務的 Job 對象，然後創建 Pods 來運行這些任務直至完成

• 端點控制器（Endpoints Controller）: 填充端點 (Endpoints) 對象(即加入 Service 與 Pod)

• 服務帳戶和令牌控制器（Service Account & Token Controllers）: 爲新的命名空間創建默認帳戶和 API 訪問令牌

• cloud-controller-manager

• cloud-controller-manager 僅運行特定於雲平臺的控制迴路。如果你在自己的環境中運行 Kubernetes，或者在本地計算機中運行學習環境， 所部署的環境中不需要雲控制器管理器。

• 與 kube-controller-manager 類似，cloud-controller-manager 將若干邏輯上獨立的 控制迴路組合到同一個可執行文件中，供你以同一進程的方式運行。你可以對其執行水平擴容（運行不止一個副本）以提升性能或者增強容錯能力。

• 下面的控制器都包含對雲平臺驅動的依賴：

• 節點控制器（Node Controller）: 用於在節點終止響應後檢查雲提供商以確定節點是否已被刪除

• 路由控制器（Route Controller）: 用於在底層雲基礎架構中設置路由

• 服務控制器（Service Controller）: 用於創建、更新和刪除雲提供商負載均衡器

• Node 組件 

• 節點組件在每個節點上運行，維護運行的 Pod 並提供 Kubernetes 運行環境。

• kubelet

• 一個在集羣中每個節點（node）上運行的代理。它保證容器（containers）都 運行在 Pod 中。

• kubelet 接收一組通過各類機制提供給它的 PodSpecs，確保這些 PodSpecs 中描述的容器處於運行狀態且健康。kubelet 不會管理不是由 Kubernetes 創建的容器。

• kube-proxy

• kube-proxy 是集羣中每個節點上運行的網絡代理， 實現 Kubernetes 服務（Service） 概念的一部分。

• kube-proxy 維護節點上的網絡規則。這些網絡規則允許從集羣內部或外部的網絡會話與 Pod 進行網絡通信。

• 如果操作系統提供了數據包過濾層並可用的話，kube-proxy 會通過它來實現網絡規則。否則， kube-proxy 僅轉發流量本身。

• 容器運行時（Container Runtime） 

• 容器運行環境是負責運行容器的軟件。

• Kubernetes 支持多個容器運行環境: Docker、 containerd、CRI-O 以及任何實現 Kubernetes CRI (容器運行環境接口)。

• 插件（Addons） 

• 插件使用 Kubernetes 資源（DaemonSet、 Deployment 等）實現集羣功能。因爲這些插件提供集羣級別的功能，插件中命名空間域的資源屬於 kube-system 命名空間。

• 下面描述衆多插件中的幾種。有關可用插件的完整列表，請參見 插件（Addons）。

• DNS 

• 儘管其他插件都並非嚴格意義上的必需組件，但幾乎所有 Kubernetes 集羣都應該 有集羣 DNS， 因爲很多示例都需要 DNS 服務。

• 集羣 DNS 是一個 DNS 服務器，和環境中的其他 DNS 服務器一起工作，它爲 Kubernetes 服務提供 DNS 記錄。

• Kubernetes 啓動的容器自動將此 DNS 服務器包含在其 DNS 搜索列表中。

• Web 界面（儀表盤）

• Dashboard 是 Kubernetes 集羣的通用的、基於 Web 的用戶界面。它使用戶可以管理集羣中運行的應用程序以及集羣本身並進行故障排除。

• 容器資源監控

• 容器資源監控 將關於容器的一些常見的時間序列度量值保存到一個集中的數據庫中，並提供用於瀏覽這些數據的界面。

• 集羣層面日誌

• 集羣層面日誌 機制負責將容器的日誌數據 保存到一個集中的日誌存儲中，該存儲能夠提供搜索和瀏覽接口。

• Kubernetes API

• Kubernetes 控制面 的核心是 API 服務器。API 服務器負責提供 HTTP API，以供用戶、集羣中的不同部分和集羣外部組件相互通信。

• Kubernetes API 使你可以查詢和操縱 Kubernetes API 中對象（例如：Pod、Namespace、ConfigMap 和 Event）的狀態。

• 大部分操作都可以通過 kubectl 命令行接口或 類似 kubeadm 這類命令行工具來執行， 這些工具在背後也是調用 API。不過，你也可以使用 REST 調用來訪問這些 API。

• 如果你正在編寫程序來訪問 Kubernetes API，可以考慮使用 客戶端庫之一。

• 準備環境

• kubeadmin 部署

• 常用命令：

• 如何使用：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Fq6Zr-_rDSmp7InJAkApSg