Kubernetes基礎概念

在部署應用程式的方式上，主要經曆了三個時代：

傳統部署：網際網路早期，會直接将應用程式部署在實體機上

優點：簡單，不需要其它技術的參與

缺點：不能為應用程式定義資源使用邊界，很難合理地配置設定計算資源，而且程式之間容易産生影響

虛拟化部署：可以在一台實體機上運作多個虛拟機，每個虛拟機都是獨立的一個環境

優點：程式環境不會互相産生影響，提供了一定程度的安全性

缺點：增加了作業系統，浪費了部分資源

容器化部署：與虛拟化類似，但是共享了作業系統

優點：

可以保證每個容器擁有自己的檔案系統、CPU、記憶體、程序空間等

運作應用程式所需要的資源都被容器包裝，并和底層基礎架構解耦

容器化的應用程式可以跨雲服務商、跨Linux作業系統發行版進行部署

容器化部署方式給帶來很多的便利，但是也會出現一些問題，比如說：一個容器故障停機了，怎麼樣讓另外一個容器立刻啟動去替補停機的容器，當并發通路量變大的時候，怎麼樣做到橫向擴充容器數量

這些容器管理的問題統稱為容器編排問題，為了解決這些容器編排問題，就産生了一些容器編排的軟體：

Swarm：Docker自己的容器編排工具

Mesos：Apache的一個資源統一管控的工具，需要和Marathon結合使用

Kubernetes：Google開源的的容器編排工具

kubernetes具有以下特性：

服務發現和負載均衡

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

存儲編排

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

自動部署和復原

你可以使用 Kubernetes 描述已部署容器的所需狀态，它可以以受控的速率将實際狀态 更改為期望狀态。例如，你可以自動化 Kubernetes 來為你的部署建立新容器， 删除現有容器并将它們的所有資源用于新容器。

自動完成裝箱計算

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

自我修複

Kubernetes 重新啟動失敗的容器、替換容器、殺死不響應使用者定義的 運作狀況檢查的容器，并且在準備好服務之前不将其通告給用戶端。

密鑰與配置管理

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

控制平面的元件對叢集做出全局決策(比如排程)，以及檢測和響應叢集事件（例如，當不滿足部署的 <code>replicas</code> 字段時，啟動新的 pod）。

控制平面元件可以在叢集中的任何節點上運作。 然而，為了簡單起見，設定腳本通常會在同一個計算機上啟動所有控制平面元件， 并且不會在此計算機上運作使用者容器。 請參閱使用 kubeadm 建構高可用性叢集 中關于多 VM 控制平面設定的示例。

API 伺服器是 Kubernetes 控制面的元件， 該元件公開了 Kubernetes API。 API 伺服器是 Kubernetes 控制面的前端。

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

etcd 是兼具一緻性和高可用性的鍵值資料庫，可以作為儲存 Kubernetes 所有叢集資料的背景資料庫。

您的 Kubernetes 叢集的 etcd 資料庫通常需要有個備份計劃。

要了解 etcd 更深層次的資訊，請參考 etcd 文檔。

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

排程決策考慮的因素包括單個 Pod 和 Pod 集合的資源需求、硬體/軟體/政策限制、親和性和反親和性規範、資料位置、工作負載間的幹擾和最後時限。

在主節點上運作 控制器 的元件。

從邏輯上講，每個控制器都是一個單獨的程序， 但是為了降低複雜性，它們都被編譯到同一個可執行檔案，并在一個程序中運作。

這些控制器包括:

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

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

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

服務帳戶和令牌控制器（Service Account &amp; Token Controllers）: 為新的命名空間建立預設帳戶和 API 通路令牌

雲控制器管理器是指嵌入特定雲的控制邏輯的 控制平面元件。 雲控制器管理器允許您連結叢集到雲提供商的應用程式設計接口中， 并把和該雲平台互動的元件與隻和您的叢集互動的元件分離開。

<code>cloud-controller-manager</code> 僅運作特定于雲平台的控制回路。 如果你在自己的環境中運作 Kubernetes，或者在本地計算機中運作學習環境， 所部署的環境中不需要雲控制器管理器。

與 <code>kube-controller-manager</code> 類似，<code>cloud-controller-manager</code> 将若幹邏輯上獨立的 控制回路組合到同一個可執行檔案中，供你以同一程序的方式運作。 你可以對其執行水準擴容（運作不止一個副本）以提升性能或者增強容錯能力。

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

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

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

服務控制器（Service Controller）: 用于建立、更新和删除雲提供商負載均衡器

節點元件在每個節點上運作，維護運作的 Pod 并提供 Kubernetes 運作環境。

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

kubelet 接收一組通過各類機制提供給它的 PodSpecs，確定這些 PodSpecs 中描述的容器處于運作狀态且健康。 kubelet 不會管理不是由 Kubernetes 建立的容器。

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

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

如果作業系統提供了資料包過濾層并可用的話，kube-proxy 會通過它來實作網絡規則。否則， kube-proxy 僅轉發流量本身。

每個人都有潛在的能量，隻是很容易被習慣所掩蓋，被時間所迷離，被惰性所消磨~