Kubernetes 基礎概念

摘要： Kubernetes 是一個跨主機叢集的 開源的容器排程平臺，它可以自動化應用容器的部署、擴充套件和操作 , 提供以容器為中心的基礎架構。 使用 Kubernetes, 可以快速高效地響應客戶需求: 快速、可預測地部署應用程式 擁有即時擴充套件應用程式的能力 不影響...

Kubernetes 是一個跨主機叢集的 開源的容器排程平臺，它可以自動化應用容器的部署、擴充套件和操作 , 提供以容器為中心的基礎架構。

使用 Kubernetes, 可以快速高效地響應客戶需求:

• 快速、可預測地部署應用程式
• 擁有即時擴充套件應用程式的能力
• 不影響現有業務的情況下，無縫地釋出新功能
• 優化硬體資源，降低成本

Kubernetes 元件

Master 元件

master 又由下面重要的元件來實現它的功能：

• kube-apiserver

  k8s API Server提供了k8s各類資源物件（pod,RC,Service等）的增刪改查及watch等HTTP Rest介面，是整個系統的資料匯流排和資料中心。

  kubernetes API Server的功能：

  • 提供了叢集管理的REST API介面(包括認證授權、資料校驗以及叢集狀態變更)；
  • 提供其他模組之間的資料互動和通訊的樞紐（其他模組通過API Server查詢或修改資料，只有API Server才直接操作etcd）;
  • 是資源配額控制的入口；
  • 擁有完備的叢集安全機制.

• kube-controller-manager

  Controller Manager作為叢集內部的管理控制中心，負責叢集內的Node、Pod副本、服務端點（Endpoint）、名稱空間（Namespace）、服務賬號（ServiceAccount）、資源定額（ResourceQuota）的管理，當某個Node意外宕機時，Controller Manager會及時發現並執行自動化修復流程，確保叢集始終處於預期的工作狀態。

  每個Controller通過API Server提供的介面實時監控整個叢集的每個資源物件的當前狀態，當發生各種故障導致系統狀態發生變化時，會嘗試將系統狀態修復到“期望狀態”。

• kube-scheduler

  Scheduler負責Pod排程。在整個系統中起”承上啟下”作用，承上：負責接收Controller Manager建立的新的Pod，為其選擇一個合適的Node；啟下：Node上的kubelet接管Pod的生命週期。

  Scheduler：

  • 通過排程演算法為待排程Pod列表的每個Pod從Node列表中選擇一個最適合的Node，並將資訊寫入etcd中

  • kubelet通過API Server監聽到kubernetes Scheduler產生的Pod繫結資訊，然後獲取對應的Pod清單，下載Image，並啟動容器。

• etcd

  etcd 是 kubernetes 存放叢集狀態和配置的地方，這是叢集狀態同步的關鍵，所有節點都是從 etcd 中獲取叢集中其他機器狀態的；叢集中所有容器的狀態也是放在這裡的。

Node 元件

node 主要組成：

• kubelet

  kubelet是主要的節點代理,它監測已分配給其節點的 Pod(通過 apiserver 或通過本地配置檔案)，提供如下功能:

  • 掛載 Pod 所需要的資料卷(Volume)。
  • 下載 Pod 的 secrets。
  • 通過 Docker 執行(或通過 rkt)執行 Pod 的容器。
  • 週期性的對容器生命週期進行探測。
  • 如果需要，通過建立映象Pod（Mirror Pod)將 Pod 的狀態報告回系統的其餘部分。
  • 將節點的狀態報告回系統的其餘部分。

• kube-proxy

  kube-proxy 為 pod 提供代理服務。service是一組pod的服務抽象，相當於一組pod的LB，負責將請求分發給對應的pod。service會為這個LB提供一個IP，一般稱為cluster IP。 kube-proxy的作用主要是負責service的實現，具體來說，就是實現了內部從pod到service和外部的從node port向service的訪問。

  用下面這張圖來展示 kube-proxy在 k8s 中的作用

  

• docker

  容器的建立, 執行和管理

Kubernetes 基本的服務部署

• Pod

  Pod 是Kubernetes的基本操作單元，也是應用執行的載體。整個Kubernetes系統都是圍繞著Pod展開的，比如如何部署執行Pod、如何保證Pod的數量、如何訪問Pod等。另外，Pod是一個或多個機關容器的集合，這可以說是一大創新點，提供了一種容器的組合的模型。

  在Docker中，容器是最小的處理單元，增刪改查的物件是容器，容器是一種虛擬化技術，容器之間是隔離的，隔離是基於Linux Namespace實現的。而在Kubernetes中，Pod包含一個或者多個相關的容器，Pod可以認為是容器的一種延伸擴充套件，一個Pod也是一個隔離體，而Pod內部包含的一組容器又是共享的（包括PID、Network、IPC、UTS）。除此之外，Pod中的容器可以訪問共同的資料捲來實現檔案系統的共享。

• RelicaSet

  在說 ReplicaSet 之前我們先要介紹一下 Replication Controller(RC). RC 是Kubernetes中的另一個核心概念，應用託管在Kubernetes之後，Kubernetes需要保證應用能夠持續執行，這是RC的工作內容，它會確保任何時間Kubernetes中都有指定數量的Pod在執行。在此基礎上，RC還提供了一些更高階的特性，比如滾動升級、升級回滾等。

  RC與Pod的關聯是通過Label來實現的。Label機制是Kubernetes中的一個重要設計，通過Label進行物件的弱關聯，可以靈活地進行分類和選擇。對於Pod，需要設定其自身的Label來進行標識，Label是一系列的Key/value對，在Pod–>metadata–>labeks中進行設定。

  RelicaSet 是 RC的升級，它與當前RC的唯一區別在於Replica Set支援基於集合的Label Selector(Set-based selector)，而舊版本RC只支援基於等式的Label Selector(equality-based selector)。 Kubernetes1.2以上版本通過Deployment來維護Replica Set而不是單獨使用Replica Set。即控制流為：Delpoyment→Replica Set→Pod。即新版本的Deployment+Replica Set替代了RC的作用。

• Deployment

  Kubernetes提供了一種更加簡單的更新RC和Pod的機制，叫做Deployment。通過在Deployment中描述你所期望的叢集狀態，Deployment Controller會將現在的叢集狀態在一個可控的速度下逐步更新成你所期望的叢集狀態。Deployment主要職責同樣是為了保證pod的數量和健康，90%的功能與Replication Controller完全一樣，可以看做新一代的Replication Controller。但是，它又具備了Replication Controller之外的新特性：

  • Replication Controller全部功能

    Deployment繼承了上面描述的Replication Controller全部功能。

  • 事件和狀態檢視

    可以檢視Deployment的升級詳細進度和狀態。

  • 回滾

    當升級pod映象或者相關引數的時候發現問題，可以使用回滾操作回滾到上一個穩定的版本或者指定的版本。

  • 版本記錄

    每一次對Deployment的操作，都能儲存下來，給予後續可能的回滾使用。

  • 暫停和啟動

    對於每一次升級，都能夠隨時暫停和啟動。

  • 多種升級方案

    Recreate—-刪除所有已存在的pod,重新建立新的; RollingUpdate—-滾動升級，逐步替換的策略，同時滾動升級時，支援更多的附加引數，例如設定最大不可用pod數量，最小升級間隔時間等等。

• Service

  在Kubernetes中，在受到RC調控的時候，Pod副本是變化的，對於的虛擬IP也是變化的，比如發生遷移或者伸縮的時候。這對於Pod的訪問者來說是不可接受的。Kubernetes中的Service是一種抽象概念，它定義了一個Pod邏輯集合以及訪問它們的策略，Service同Pod的關聯同樣是居於Label來完成的。Service的目標是提供一種橋樑， 它會為訪問者提供一個固定訪問地址，用於在訪問時重定向到相應的後端，這使得非 Kubernetes原生應用程式，在無須為Kubemces編寫特定程式碼的前提下，輕鬆訪問後端。

  Service同RC一樣，都是通過Label來關聯Pod的。當你在Service的yaml檔案中定義了該Service的selector中的label為app:my-web，那麼這個Service會將Pod–>metadata–>labeks中label為app:my-web的Pod作為分發請求的後端。當Pod發生變化時（增加、減少、重建等），Service會及時更新。這樣一來，Service就可以作為Pod的訪問入口，起到代理伺服器的作用，而對於訪問者來說，通過Service進行訪問，無需直接感知Pod。

  需要注意的是，Kubernetes分配給Service的固定IP是一個虛擬IP，並不是一個真實的IP，在外部是無法定址的。真實的系統實現上，Kubernetes是通過Kube-proxy元件來實現的虛擬IP路由及轉發。所以在之前叢集部署的環節上，我們在每個Node上均部署了Proxy這個元件，從而實現了Kubernetes層級的虛擬轉發網路。

  我們用下面這張圖來說明 service 的作用