k8s快速通關秘籍（1）

隨著IT技術發展的日新月異，應用程式的工作負載也經歷了4代，從第1代大型機，小型機，到第2代X86伺服器，再到第3代虛擬機，當前又再向第4代容器轉移。

K8s的快速崛起大大加快了應用程式的工作負載從第3代虛擬機向第4代容器的遷移速度，K8s不僅提供容器編排，部署和管理功能，而且也是CNCF基金會第一個畢業的項目，代表其成熟和穩定性已達到生產環境的標準，當前推薦部署在生產環境的k8s版本是1.14.6。

k8s越來越流行，已經成為容器管理與調度編排的首選平臺和事實標準，開發，測試，運維等技術人員，需要快速的學習和掌握k8s相關知識，通關秘籍系列就從k8s架構和組件，k8s的安裝部署，k8s的日常運維等方面介紹k8s，使零基礎的小白技術人員，迅速拿到k8s的通關秘籍。

k8s架構和組件

首先k8s分為Master節點和Node節點

Master節點相當於k8s的大腦，它的主要職能就是負責調度，決定應用在那個Node節點運行。

Node節點是k8s的工作節點，提供計算資源，承擔運行應用的容器。

Master節點主要包含以下組件：

kube-apiserver：是k8s重要的核心組件之一，封裝了 k8s 所有的邏輯，通過REST API 格式供客戶端使用，kubectl 就是最常用到的客戶端程序。

kube-apiserver提供集群管理的認證、授權、準入控制以及集群狀態變更等

kube-controller-manager：負責整個k8s任務的管理工作，保證集群中各種任務的狀態處於期望狀態。

提交到k8s中的任務分位兩大類：Pod和Controller。

Pod是k8s中能夠創建和部署的最小單位，是比容器更高一層的概念，增加了這一層是為了增加靈活性，Pod可以是一個容器或者多個容器。如果是多個容器，這些容器是不可分離，它們不僅要運行在相同的Node上，並且擁有相同的IP位址。

Controller是比Pod更高一層的概念。Controller是由一組Pod組成的，這一組Pod是可以分布在不同的Node節點上。Pod雖然支持多個容器，無法支持跨Node節點分布容器。Controller支持跨Node節點分布容器。

k8s常用的，原生支持的Controller主要有以下幾種：

Deployment，用於管理無狀態應用，是一個更高層次的概念，用來管理ReplicaSet，並提供對pod更新。在升級應用程式時，Deployment會新創建一個ReplicaSet，並控制新舊兩個 ReplicaSet，新ReplicaSet管理Pod會逐漸達到預期的數量，舊ReplicaSet管理的Pod會減少到0，而業務不會中斷，Deployment 將這些運維過程都代碼化，內置為自己的業務邏輯，從而讓升級部署過程變得簡單。

StatefulSet，用於管理有狀態應用， 在Pods管理的基礎上，保證Pods的順序和一致性。StatefulSet創建的Pods在生命周期中會保持持久的標記（例如Pod Name）。

DaemonSet，用來保證在每個Node節點上都運行一個容器副本，常用來部署一些集群的日誌、監控或者其他系統管理應用。

kube-schedule： 負責將pod 調度到最優的Node節點上，會跟蹤集群中所有 Node 節點的資源利用情況，並採取合適的調度策略，確保調度的均衡性，避免集群中的某些節點過載。

etcd：k8s集群中一個十分重要的組件，用於保存集群所有的網絡配置和對象狀態等關鍵數據。在k8s中，數據是隨時發生變化的，比如說增加了新的Pod、增加了新的Node、Node宕機了、容器死掉了等等，都會觸發狀態數據的變更。狀態數據變更之後，都需要及時地通知給k8s每一個組件。etcd有一個特別好用的特性，可以調用它的api監聽其中的數據，一旦數據發生變化了，就會收到通知。有了這個特性之後，k8s中的每個組件只需要監聽etcd中數據，就可以知道自己應該做什麼。

Node節點主要包含以下組件：

kubelet：在k8s集群中，每個Node節點都會啟動kubelet進程，用來處理Master節點下發到本Node節點的任務，管理Pod和其中的容器。kubelet會在API Server上註冊節點信息，定期向Master匯報節點資源使用情況，並通過cAdvisor監控容器和節點資源。可以把kubelet理解成Node節點上的pod管家。

kube-proxy：在k8s集群中，每個Node節點都會運行一個kube-proxy服務進程，這個進程可以看做service的透明代理和負載均衡器。其核心功能是將某個service的訪問請求轉發到後端的某個Pod上。對每一個TCP類型的service，kube-proxy都會在本地Node上建立一個socketserver來負責接收請求，然後按照策略發送到後端某個Pod埠上。這個過程默認採用Round Robin負載均衡算法。