一、什麼是Kubernetes

Kubernetes 是一個可移植、可擴充套件的開源平臺，用於管理容器化工作負載和服務，有助於宣告式配置和自動化。它擁有龐大且快速發展的生態系統。Kubernetes 服務、支援和工具廣泛可用

使用Kubernetes可以：

自動化容器的部署和複製
隨時擴充套件或收縮容器規模
將容器組織成組，並且提供容器間的負載均衡
很容易地升級應用程式容器的新版本
提供容器彈性，如果容器失效就替換它
金鑰和配置管理
儲存編排
批量處理執行
...

傳統虛擬化和容器虛擬化的對比

傳統部署時代：早期，組織在物理伺服器上執行應用程式。無法為物理伺服器中的應用程式定義資源邊界，這會導致資源分配問題。例如，如果多個應用程式在物理伺服器上執行，可能會出現一個應用程式佔用大部分資源的情況，結果，其他應用程式的效能將不佳。一個解決方案是在不同的物理伺服器上執行每個應用程式。但這並沒有擴充套件，因為資源沒有得到充分利用，而且組織維護許多物理伺服器的成本很高。

虛擬化部署時代：作為解決方案，引入了虛擬化。它允許您在單個物理伺服器的 CPU 上執行多個虛擬機器 (VM)。虛擬化允許應用程式在 VM 之間隔離，並提供一定程度的安全性，因為一個應用程式的資訊不能被另一個應用程式自由訪問。

虛擬化允許更好地利用物理伺服器中的資源並允許更好的可擴充套件性，因為可以輕鬆新增或更新應用程式，降低硬體成本等等。通過虛擬化，您可以將一組物理資源呈現為一次性虛擬機器叢集。

每個 VM 都是在虛擬化硬體之上執行所有元件的完整機器，包括它自己的作業系統。

容器部署時代：容器類似於虛擬機器，但它們具有放鬆的隔離屬性，可以在應用程式之間共享作業系統（OS）。因此，容器被認為是輕量級的。與 VM 類似，容器有自己的檔案系統、CPU 份額、記憶體、程序空間等。由於它們與底層基礎架構分離，因此它們可以跨雲和作業系統分佈移植。

容器之所以流行，是因為它們提供了額外的好處，例如：

• 敏捷的應用程式建立和部署：與使用 VM 映像相比，容器映像建立的簡便性和效率更高。
• 持續開發、整合和部署：提供可靠且頻繁的容器映像構建和部署以及快速高效的回滾（由於映像不變性）。
• Dev 和 Ops 的關注點分離：在構建/釋出時而不是部署時建立應用程式容器映像，從而將應用程式與基礎架構解耦。
• 可觀察性：不僅可以顯示作業系統級別的資訊和指標，還可以顯示應用程式執行狀況和其他訊號。
• 開發、測試和生產之間的環境一致性：在膝上型電腦上執行與在雲中執行相同。
• 雲和作業系統分發可移植性：在 Ubuntu、RHEL、CoreOS、本地、主要公共雲和其他任何地方執行。
• 以應用程式為中心的管理：將抽象級別從在虛擬硬體上執行作業系統提高到使用邏輯資源在作業系統上執行應用程式。
• 鬆散耦合、分散式、彈性、自由的微服務：應用程式被分解成更小的、獨立的部分，並且可以動態部署和管理——而不是在一臺大型單一用途機器上執行的單一堆疊。
• 資源隔離：可預測的應用程式效能。
• 資源利用：高效率、高密度。

二、Kubernets架構

三、控制平面元件

控制平面的元件對叢集做出全域性決策（例如，排程），以及檢測和響應叢集事件（例如，啟動一個新的pod當部署的replicas欄位不滿意時）。

控制平面元件可以在叢集中的任何機器上執行。但是，為簡單起見，通常在同一臺機器上啟動所有控制平面元件，並且不在這臺機器上執行業務容器，只執行元件相關容器

kube-apiserver

Kubernetes API，叢集的統一入口各元件的協調者，以RESTful API提供介面服務，所有物件資源的增刪改查和監聽操作都交給APIServer處理後再提交給Etcd儲存。

它是整個kubernetes叢集的大腦，它通過部署更多例項來擴充套件。可以執行多個 kube-apiserver 例項並平衡這些例項之間的流量

kube-scheduler

Kubernetes 控制器管理器是一個守護程序，它們是處理叢集中常規任務的後臺執行緒。內嵌隨 Kubernetes 一起釋出的核心控制迴路。 說白了，Controller Manager 就是叢集內部的管理控制中心，由負責不同資源的多個 Controller 構成，共同負責叢集內的 Node、Pod 等所有資源的管理，比如當通過 Deployment 建立的某個 Pod 發生異常退出時，RS Controller 便會接受並處理該退出事件，並建立新的 Pod 來維持預期副本數，目前，Kubernetes 自帶的控制器例子包括副本控制器、節點控制器、名稱空間控制器和服務賬號控制器等。

從邏輯上講，每個控制器是一個單獨的程序，但為了降低複雜性，它們都被編譯成一個二進位制檔案並在一個程序中執行。

這些控制器的一些型別是：

Node controller：負責在節點宕機時進行通知和響應。
Job controller：監視代表一次性任務的作業物件，然後建立 Pod 以執行這些任務以完成。
Endpoints controller：填充 Endpoints 物件（即加入 Services & Pods）。
Service Account & Token controllers：為新名稱空間建立預設帳戶和 API 訪問令牌

kube-scheduler

scheduler的職責很明確，就是負責排程pod到合適的Node上。Kubernetes目前提供了排程演算法，但是同樣也保留了介面，使用者可以根據自己的需求定義自己的排程演算法

etcd

etcd是一個高可用的鍵值儲存系統，Kubernetes使用它來儲存當前叢集中所有的狀態資料

1)執行的 etcd 叢集個數成員為奇數。
2)etcd 是一個 leader-based 分散式系統。確保主節點定期向所有從節點發送心跳，以保持叢集穩定。
3)確保不發生資源不足。
    叢集的效能和穩定性對網路和磁碟 IO 非常敏感。任何資源匱乏都會導致心跳超時，從而導致叢集的不穩定。不穩定的情況表明沒有選出任何主節點。在這種情況下，叢集不能對其當前狀態進行任何更改，這意味著不能排程新的 pod。
4)保持穩定的 etcd 叢集對 Kubernetes 叢集的穩定性至關重要。因此，請在專用機器或隔離環境上執行 etcd 叢集，以滿足所需資源需求。
5)在生產中執行的 etcd 的最低推薦版本是 3.2.10+。

四、節點元件

kubelet

執行在每個節點上的主要的“節點代理”，管理本機執行容器的生命週期，比如建立容器、Pod掛載資料卷、下載secret、獲取容器和節點狀態等工作。kubelet將每個Pod轉換成一組容器，kubelet 不管理不是由 Kubernetes 建立的容器。

kube-proxy

在Node節點上實現Pod網路代理，維護網路規則和四層負載均衡工作。就是維護節點中的iptables或者ipvs規則，這些網路規則允許從叢集內部或外部的網路會話與 Pod 進行網路通訊。

container-runtime

容器執行時是負責執行容器的軟體

五、pod建立流程

1.kubectl 向 k8s api server 發起一個create pod 請求
2.k8s api server接收到pod建立請求後，不會去直接建立pod；而是生成一個包含建立資訊的yaml，並寫入etcd資料庫
3.API Server告知Schedule為其分配node，在分配完node之後將結果返回API Server，並將結果儲存在etcd上
4.node節點訪問API Server然後讀取etcd拿到分配給當前節點的pod，然後響應給docker建立容器
5.把本節點的pod資訊同步到etcd