kubernetes(k8s)與其架構


1. kubernetes簡介

       kubernetes,簡稱K8s,是用8代替8個字符“ubernete”而成的縮寫。是一個開源的,用於管理雲平台中多個主機上的容器化的應用,Kubernetes的目標是讓部署容器化的應用簡單並且高效(powerful),Kubernetes提供了應用部署,規划,更新,維護的一種機制。

  傳統的應用部署方式是通過插件或腳本來安裝應用。這樣做的缺點是應用的運行、配置、管理、所有生存周期將與當前操作系統綁定,這樣做並不利於應用的升級更新/回滾等操作,當然也可以通過創建虛擬機的方式來實現某些功能,但是虛擬機非常重,並不利於可移植性。

  新的方式是通過部署容器方式實現,每個容器之間互相隔離,每個容器有自己的文件系統 ,容器之間進程不會相互影響,能區分計算資源。相對於虛擬機,容器能快速部署,由於容器與底層設施、機器文件系統解耦的,所以它能在不同雲、不同版本操作系統間進行遷移。

  容器占用資源少、部署快,每個應用可以被打包成一個容器鏡像,每個應用與容器間成一對一關系也使容器有更大優勢,使用容器可以在build或release 的階段,為應用創建容器鏡像,因為每個應用不需要與其余的應用堆棧組合,也不依賴於生產環境基礎結構,這使得從研發到測試、生產能提供一致環境。類似地,容器比虛擬機輕量、更“透明”,這更便於監控和管理。

——摘自百度百科

 

       Kubernetes (K8s) 是 Google 在 2014 年發布的一個開源項目。據說 Google 的數據中心里運行着超過 20 億個容器,而且 Google 十年前就開始使用容器技術。最初,Google 開發了一個叫 Borg 的系統(現在命令為 Omega)來調度如此龐大數量的容器和工作負載。在積累了這么多年的經驗后,Google 決定重寫這個容器管理系統,並將其貢獻到開源社區,讓全世界都能受益。

  這個項目就是 Kubernetes。簡單的講,Kubernetes 是 Google Omega 的開源版本。

  從 2014 年第一個版本發布以來,Kubernetes 迅速獲得開源社區的追捧,包括 Red Hat、VMware、Canonical 在內的很多有影響力的公司加入到開發和推廣的陣營。目前 Kubernetes 已經成為發展最快、市場占有率最高的容器編排引擎產品。 Kubernetes 一直在快速地開發和迭代。

2. kubernetes的重要概念

在實踐之前,必須先學習 Kubernetes 的幾個重要概念,它們是組成 Kubernetes 集群的基石。

1> Cluster 

  Cluster 是計算、存儲和網絡資源的集合,Kubernetes 利用這些資源運行各種基於容器的應用。

 

2> Master 

  Master 是 Cluster 的大腦,它的主要職責是調度,即決定將應用放在哪里運行。Master 運行 Linux 操作系統,可以是物理機或者虛擬機。為了實現高可用,可以運行多個 Master。

 

3> Node 

  Node 的職責是運行容器應用。Node 由 Master 管理,Node 負責監控並匯報容器的狀態,並根據 Master 的要求管理容器的生命周期。Node 運行在 Linux 操作系統,可以是物理機或者是虛擬機。

 

4> Pod 

  Pod 是 Kubernetes 的最小工作單元。每個 Pod 包含一個或多個容器。Pod 中的容器會作為一個整體被 Master 調度到一個 Node 上運行。

Kubernetes 引入 Pod 主要基於下面兩個目的:

1) 可管理性。

  有些容器天生就是需要緊密聯系,一起工作。Pod 提供了比容器更高層次的抽象,將它們封裝到一個部署單元中。Kubernetes 以 Pod 為最小單位進行調度、擴展、共享資源、管理生命周期。

2) 通信和資源共享

  Pod 中的所有容器使用同一個網絡 namespace,即相同的 IP 地址和 Port 空間。它們可以直接用 localhost 通信。同樣的,這些容器可以共享存儲,當 Kubernetes 掛載 volume 到 Pod,本質上是將 volume 掛載到 Pod 中的每一個容器。

 

Pods 有兩種使用方式:

1) 運行單一容器。

  one-container-per-Pod 是 Kubernetes 最常見的模型,這種情況下,只是將單個容器簡單封裝成 Pod。即便是只有一個容器,Kubernetes 管理的也是 Pod 而不是直接管理容器。

2) 運行多個容器。

  哪些容器應該放到一個 Pod 中? 這些容器聯系必須 非常緊密,而且需要 直接共享資源

  舉個例子,下面這個 Pod 包含兩個容器:一個 File Puller,一個是 Web Server。

  File Puller 會定期從外部的 Content Manager 中拉取最新的文件,將其存放在共享的 volume 中。Web Server 從 volume 讀取文件,響應 Consumer 的請求。

  這兩個容器是緊密協作的,它們一起為 Consumer 提供最新的數據;同時它們也通過 volume 共享數據。所以放到一個 Pod 是合適的。

  再來看一個反例:是否需要將 Tomcat 和 MySQL 放到一個 Pod 中?

  Tomcat 從 MySQL 讀取數據,它們之間需要協作,但還不至於需要放到一個 Pod 中一起部署,一起啟動,一起停止。同時它們是之間通過 JDBC 交換數據,並不是直接共享存儲,所以放到各自的 Pod 中更合適。

 

5> Controller 

  Kubernetes 通常不會直接創建 Pod,而是通過 Controller 來管理 Pod 的。Controller 中定義了 Pod 的部署特性,比如有幾個副本,在什么樣的 Node 上運行等。為了滿足不同的業務場景,Kubernetes 提供了多種 Controller,包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等,我們逐一討論。

 

1) Deployment 

  是最常用的 Controller,比如前面在線教程中就是通過創建 Deployment 來部署應用的。Deployment 可以管理 Pod 的多個副本,並確保 Pod 按照期望的狀態運行。

 

2) ReplicaSet 

  實現了 Pod 的多副本管理。使用 Deployment 時會自動創建 ReplicaSet,也就是說 Deployment 是通過 ReplicaSet 來管理 Pod 的多個副本,我們通常不需要直接使用 ReplicaSet。

 

3) DaemonSet 

  用於每個 Node 最多只運行一個 Pod 副本的場景。正如其名稱所揭示的,DaemonSet 通常用於運行 daemon。

4) StatefuleSet 

  能夠保證 Pod 的每個副本在整個生命周期中名稱是不變的。而其他 Controller 不提供這個功能,當某個 Pod 發生故障需要刪除並重新啟動時,Pod 的名稱會發生變化。同時 StatefuleSet 會保證副本按照固定的順序啟動、更新或者刪除。

5) Job 

  用於運行結束就刪除的應用。而其他 Controller 中的 Pod 通常是長期持續運行。

6> Service 

  Deployment 可以部署多個副本,每個 Pod 都有自己的 IP, Kubernetes Service 定義了外界訪問一組特定 Pod 的方式。Service 有自己的 IP 和端口,Service 為 Pod 提供了負載均衡。Kubernetes 運行容器(Pod)與訪問容器(Pod)這兩項任務分別由 Controller 和 Service 執行。

 

7> Namespace

  如果有多個用戶或項目組使用同一個 Kubernetes Cluster,如何將他們創建的 Controller、Pod 等資源分開呢?用Namespace。

  Namespace 可以將一個物理的 Cluster 邏輯上划分成多個虛擬 Cluster,每個 Cluster 就是一個 Namespace。不同 Namespace 里的資源是完全隔離的。

  Kubernetes 默認創建了三個 Namespace。

  default -- 創建資源時如果不指定,將被放到這個 Namespace 中。

  kube-system -- Kubernetes 自己創建的系統資源將放到這個 Namespace 中。

  kube-public -- Kubernetes 公共的系統資源將放到這個 Namespace 中。

3. kubernetes架構

  Kubernetes Cluster 由 Master 和 Node 組成,節點上運行着若干 Kubernetes 服務。

1> Master 節點

  Master 是 Kubernetes Cluster 的大腦,運行着如下 Daemon 服務:kube-apiserver、kube-scheduler、kube-controller-manager、etcd 和 Pod 網絡(例如 flannel)。

API Server(kube-apiserver

  API Server 提供 HTTP/HTTPS RESTful API,即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口,各種客戶端工具(CLI 或 UI)以及 Kubernetes 其他組件可以通過它管理 Cluster 的各種資源。

 

Scheduler(kube-scheduler

  Scheduler 負責決定將 Pod 放在哪個 Node 上運行。Scheduler 在調度時會充分考慮 Cluster 的拓撲結構,當前各個節點的負載,以及應用對高可用、性能、數據親和性的需求。

 

Controller Manager(kube-controller-manager

  Controller Manager 負責管理 Cluster 各種資源,保證資源處於預期的狀態。Controller Manager 由多種 controller 組成,包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。

不同的 controller 管理不同的資源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期,namespace controller 管理 Namespace 資源。

 

etcd(數據庫)

  etcd 負責保存 Kubernetes Cluster 的配置信息和各種資源的狀態信息。當數據發生變化時,etcd 會快速地通知 Kubernetes 相關組件。

 

Pod 網絡

  Pod 要能夠相互通信,Kubernetes Cluster 必須部署 Pod 網絡,flannel 是其中一個可選方案。

 

2> node節點

  Node 是 Pod 運行的地方,Kubernetes 支持 Docker、rkt 等容器 Runtime。 Node上運行的 Kubernetes 組件有 kubelet、kube-proxy 和 Pod 網絡(例如 flannel)。

kubelet

  kubelet 是 Node 的 agent,當 Scheduler 確定在某個 Node 上運行 Pod 后,會將 Pod 的具體配置信息(image、volume 等)發送給該節點的 kubelet,kubelet 根據這些信息創建和運行容器,並向 Master 報告運行狀態。

 

kube-proxy

  service 在邏輯上代表了后端的多個 Pod,外界通過 service 訪問 Pod。service 接收到的請求是如何轉發到 Pod 的呢?這就是 kube-proxy 要完成的工作。

  每個 Node 都會運行 kube-proxy 服務,它負責將訪問 service 的 TCP/UPD 數據流轉發到后端的容器。如果有多個副本,kube-proxy 會實現負載均衡。

 

Pod 網絡

  Pod 要能夠相互通信,Kubernetes Cluster 必須部署 Pod 網絡,flannel 是其中一個二層可選方案,三層的為calico。

完整的架構圖

結合實驗環境,我們得到了如下的架構圖:

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM