怎樣總結K8S 知識點

這篇文章給大家介紹怎樣總結K8S 知識點，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

Kubernetes是基于容器的分布式資源管理系統：對容器化的應用自動部署、資源的伸縮和管理。

如果想用k8s管理應用，首先要把應用打包成容器鏡像（比如Docker鏡像），然后再用k8s管理容器。k8s典型應用場景：

• 微服務場景，當請求流量增多，增加后臺服務數，流量減少隨之也減少服務數

• 大數據場景，spark、flink等結合k8s的Namespace，實現多租戶資源隔離，比如白天可以多給在線計算分配工作節點、內存、cpu等資源，離線計算分配的少點；而到了凌晨，離線任務就要拉起來，多給離線計算分配資源，實時計算的就可以少些

1、k8s集群組件

• Control Plane/Master

Kubernetes里的Master指的是集群控制節點，在每個Kubernetes集群里都需要有一個Master來負責整個集群的管理和控制，基本上Kubernetes的所有控制命令都發給它，它負責具體的執行過程。Master通常會占據一個獨立的服務器（高可用部署建議用3臺服務器），主要原因是它太重要了，是整個集群的“首腦”，如果它宕機或者不可用，那么對集群內容器應用的管理都將失效。master上運行的關鍵服務：

◎ Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接口的關鍵服務進程，是Kubernetes里所有資源的增、刪、改、查等操作的唯一入口，也是集群控制的入口進程。

◎Kubernetes Controller Manager（kube-controller-manager）：Kubernetes里所有資源對象的自動化控制中心

◎ Kubernetes Scheduler（kube-scheduler）：負責資源調度（Pod調度）的進程，比如監聽一個新創建的沒有分配節點的Pods，選擇一個節點并且將其運行。

◎etcd：KV數據存儲服務，Kubernetes里的所有資源對象的數據都被保存在etcd中。

• Node

除了Master，Kubernetes集群中的其他機器被稱為Node，Node作為集群中的工作節點，運行真正的應用程序，在Node上Kubernetes管理的最小運行單元是Pod。與Master一樣，Node可以是一臺物理主機，也可以是一臺虛擬機。Node是Kubernetes集群中的工作負載節點，每個Node都會被Master分配一些工作負載（Docker容器），當某個Node宕機時，其上的工作負載會被Master自動轉移到其他節點上。node上運行的關鍵服務：

◎ kubelet：負責Pod對應的容器的創建、啟停等任務，同時與Master密切協作，實現集群管理的基本功能。

◎ kube-proxy：實現Kubernetes Service的通信與負載均衡機制的重要組件。

◎ Docker Engine（docker）：Docker引擎，負責本機的容器創建和管理工作。

Node可以在運行期間動態增加到Kubernetes集群中，前提是在這個節點上已經正確安裝、配置和啟動了上述關鍵進程，在默認情況下kubelet會向Master注冊自己，這也是Kubernetes推薦的Node管理方式。一旦Node被納入集群管理范圍，kubelet進程就會定時向Master匯報自身的情報，例如操作系統、Docker版本、機器的CPU和內存情況，以及當前有哪些Pod在運行等，這樣Master就可以獲知每個Node的資源使用情況，并實現高效均衡的資源調度策略。而某個Node在超過指定時間不上報信息時，會被Master判定為“失聯”，Node的狀態被標記為不可用（Not Ready），隨后Master會觸發“工作負載大轉移”的自動流程。

2、Pod

Pod是Kubernetes管理的最小運行單位，在每個Pod中都運行著一個特殊的被稱為Pause的容器，其他容器則為業務容器，這些業務容器共享Pause容器的網絡棧和Volume掛載卷，因此它們之間的通信和數據交換更為高效，在設計時我們可以充分利用這一特性將一組密切相關的服務進程放入同一個Pod中。

如果兩個或兩個以上的容器為緊耦合的關系，并組成一個整體對外提供服務，應將這兩個容器導報成一個Pod；比如用Flume采集Nginx日志，那么就可以把Nginx容器和Flume容器放到一個Pod中。屬于同一個Pod的多個容器應用之間相互訪問時僅需要通過localhost就可以通信，使得這一組容器被“綁定”在了一個環境中。

Kubernetes為每個Pod都分配了唯一的IP地址，稱之為PodIP，一個Pod里的多個容器共享Pod IP地址；當Pod重啟后，Pod IP地址會發生變化。

Pod定義文件的重要參數：

◎ spec.resources.limits.cpu、spec.resources.limits.memory：該資源最大允許使用的量，不能被突破，當容器試圖使用超過這個量的資源時，可能會被Kubernetes“殺掉”并重啟

◎ spec.resources.requests.cpu、spec.resources.requests.memory：該資源的最小申請量

◎ nodeSelector：設置Node的Label，Pod將被調度上具有這些Lable的Node是上。如果期望某種Pod的副本全部在指定的一個或者一些節點上運行，比如希望將MySQL數據庫調度到一個具有SSD磁盤的目標節點上，此時Pod模板中的NodeSelector屬性就開始發揮作用了：1）把具有SSD磁盤的Node都打上自定義標簽“disk=ssd” （2）在Pod模板中設定NodeSelector的值為“disk: ssd”。

kube-controller進程通過在資源對象RC上定義的LabelSelector來篩選要監控的Pod副本數量，使Pod副本數量始終符合預期設定的全自動控制流程。

3、Label

Label相當于我們熟悉的“標簽”。給某個資源對象定義一個Label，就相當于給它打了一個標簽，隨后可以通過LabelSelector（標簽選擇器）查詢和篩選擁有某些Label的資源對象。

Label可以被附加到各種資源對象上，例如Node、Pod、Service、RC等，一個資源對象可以定義任意數量的Label，同一個Label也可以被添加到任意數量的資源對象上。我們可以通過給指定的資源對象捆綁一個或多個不同的Label來實現多維度的資源分組管理功能，以便靈活、方便地進行資源分配、調度、配置、部署等管理工作。例如，部署不同版本的應用到不同的環境中；監控和分析應用（日志記錄、監控、告警）等；比如期望某種Pod的副本在k8s集群指定的某些節點上運行。Label使用場景：

◎ kube-controller進程通過在資源對象RC上定義的LabelSelector來篩選要監控的Pod副本數量，使Pod副本數量始終符合預期設定的全自動控制流程。

◎ kube-proxy進程通過Service的Label Selector來選擇對應的Pod，自動建立每個Service到對應Pod的請求轉發路由表，從而實現Service的智能負載均衡機制。

◎ 通過對某些Node定義特定的Label，并且在Pod定義文件中使用NodeSelector這種標簽調度策略，kube-scheduler進程可以實現Pod定向調度的特性。

Label和LabelSelector共同構成了Kubernetes系統中核心的應用模型，使得被管理對象能夠被精細地分組管理，同時實現了整個集群的高可用性。

4、Replication Controller

RC資源對象定義了一個期望的場景，即聲明某種Pod的副本數量在任意時刻都符合某個預期值，所以RC的定義包括如下幾個部分：

1、 Pod期待的副本數量

2、 用于篩選目標Pod的Label Selector

3、當Pod的副本數量小于預期數量時，用于創建新Pod的Pod模板（template）。在RC定義文件里，對應的配置項：

◎ spec.selector：是RC的Pod標簽選擇器，即監控和管理擁有這些標簽的Pod實例，確保在當前集群中始終有且僅有replicas個Pod實例在運行。當在集群中運行的Pod數量少于replicas時，RC會根據在spec.template定義的Pod模板來生成一個新的Pod實例

◎ spec.replicas：Pod副本的期待值

在我們定義了一個RC并將其提交到Kubernetes集群中后，Master上的Controller Manager組件里的Replication Controller（副本控制器）就得到通知，定期巡檢系統中當前存活的目標Pod，并確保目標Pod實例的數量剛好等于此RC的期望值，如果有過多的Pod副本在運行，系統就會停掉一些Pod，否則系統會再自動創建一些Pod。可以說，通過RC，Kubernetes實現了用戶應用集群的高可用性，并且大大減少了系統管理員在傳統IT環境中需要完成的許多手工運維工作（如主機監控腳本、應用監控腳本、故障恢復腳本等）；在運行時，我們可以通過修改RC的副本數量，來實現Pod的彈性縮放（Scaling）；通過逐個替換Pod的方式來輔助服務的滾動更新。

最好不要越過RC直接創建Pod，因為Replication Controller（副本控制器）會通過RC管理Pod副本，實現自動創建、補足、替換、刪除Pod副本，這樣能提高系統的容災能力，減少由于節點崩潰等意外狀況造成的損失。即使應用程序只用到一個Pod副本，也強烈建議使用RC來定義Pod。

5、Replica Set

Replica Set與RC當前的唯一區別是，Replica Sets支持基于集合的Label selector（Set-based selector），而RC只支持基于等式的Label Selector（equality-based selector），這使得Replica Set的功能更強。

6、Deployment

Deployment在內部使用了Replica Set來實現，無論從Deployment的作用與目的、YAML定義，還是從它的具體命令行操作來看，我們都可以把它看作RC的一次升級，兩者的相似度超過90%。我們不應該使用底層的Replica Set來控制Pod副本，而應該使用管理Replica Set的Deployment對象來控制副本。

Deployment或RC的主要功能之一就是自動部署一個容器應用的多份副本，以及持續監控副本的數量，在集群內始終維持用戶指定的副本數量。

如果Pod是通過Deployment創建的，則用戶可以在運行時修改Deployment的Pod定義（spec.template）或鏡像名稱，并應用到Deployment對象上，系統即可完成Deployment的自動更新操作。如果在更新過程中發生了錯誤，則還可以通過回滾操作恢復Pod的版本。

一旦鏡像名（或Pod定義）發生了修改，則將觸發系統完成Deployment所有運行Pod的滾動升級操作。Deployment滾動升級Pod的過程是：初始創建Deployment時，系統創建了一個ReplicaSet，并按用戶的需求創建了n個Pod副本。當更新Deployment時，系統創建了一個新的ReplicaSet，并將其副本數量擴展到1，然后將舊的ReplicaSet縮減為n-1。之后，系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。最后，新的ReplicaSet運行了n個新版本Pod副本，舊的ReplicaSet副本數量則縮減為0。

7、資源隔離

• Pod

每個Pod都可以對其能使用的服務器上的計算資源設置限額，當前可以設置限額的計算資源有CPU與Memory兩種，其中CPU的資源單位為CPU（Core）的數量，是一個絕對值而非相對值，Memory配額也是一個絕對值，它的單位是內存字節數。在Kubernetes里，一個計算資源進行配額限定時需要設定以下兩個參數：

◎ Requests：該資源的最小申請量，系統必須滿足要求。

◎ Limits：該資源最大允許使用的量，不能被突破，當容器試圖使用超過這個量的資源時，可能會被Kubernetes“殺掉”并重啟。

• Namespace

在一個組織內部，不同的工作組可以在同一個Kubernetes集群中工作，Kubernetes通過命名空間和Context的設置對不同的工作組進行區分，使得它們既可以共享同一個Kubernetes集群的服務，也能夠互不干擾，組合組之間創建的Pod、RC互不可見。Namespace在很多情況下用于實現多租戶的資源隔離。

對于Kubernetes集群管理而言，配置每一個Pod的Requests和Limits是煩瑣的，更多時候，我們需要對集群內的租戶Requests和Limits的配置做一個全局限制。Namespace通過將集群內部的資源對象“分配”到不同的Namespace中，形成邏輯上分組的不同項目、小組或用戶組，便于不同的分組在共享使用整個集群的資源的同時還能被分別管理。當給每個租戶創建一個Namespace來實現多租戶的資源隔離時，還能結合Kubernetes的資源配額管理，限定不同租戶能占用的資源，例如CPU使用量、內存使用量等。

關于怎樣總結K8S 知識點就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。