k8s快速通關祕籍

隨著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架構和組件

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

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

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

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

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

k8s快速通關秘籍

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

k8s快速通關秘籍

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 將這些運維過程都代碼化,內置為自己的業務邏輯,從而讓升級部署過程變得簡單。

k8s快速通關秘籍

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負載均衡算法。


分享到:


相關文章: