Kubernetes知識小普及

時間 2019-11-05

標籤 kubernetes 知識普及简体版

原文原文鏈接

　　大部分概念Kubernetes官網都有詳細介紹，Kubernetes中文官網 https://kubernetes.io/zh/docs/tutorials/kubernetes-basics/ 前端

　　官網還提供一個比較好的功能是能在線互動，見互動教程，相似實操命令初步感覺。node

Kubernetes主要功能

基於容器的應用部署、維護和滾動升級
負載均衡和服務發現
跨機器和跨地區的集羣調度
自動伸縮
無狀態服務和有狀態服務
普遍的 Volume 支持
插件機制保證擴展性

Kubernetes是谷歌開源的容器集羣管理系統

　　Kubernetes 提供了不少的功能，它能夠簡化應用程序的工做流，加快開發速度。使用Kubernetes只需一個部署文件，使用一條命令就能夠部署多層容器（前端，後臺等）的完整集羣。docker

核心概念

Kubernetes 主要由如下幾個核心組件組成：編程

etcd 保存了整個集羣的狀態；
apiserver 提供了資源操做的惟一入口，並提供認證、受權、訪問控制、API 註冊和發現等機制；
controller manager 負責維護集羣的狀態，好比故障檢測、自動擴展、滾動更新等；
scheduler 負責資源的調度，按照預約的調度策略將 Pod 調度到相應的機器上；
kubelet 負責維護容器的生命週期，同時也負責 Volume（CVI）和網絡（CNI）的管理；
Container runtime 負責鏡像管理以及 Pod 和容器的真正運行（CRI）；
kube-proxy 負責爲 Service 提供 cluster 內部的服務發現和負載均衡

典型的Kubernetes架構圖後端

上圖能夠看到以下組件，使用特別的圖標表示Service和Label：api

Pod
Container（容器）
Label()（標籤）
Replication Controller（複製控制器）
Service（）（服務）
Node（節點）
Kubernetes Master（Kubernetes主節點）

Pod

　　Pod在節點上，包含一組容器和卷。同一個Pod裏的容器共享同一個網絡命名空間，可使用localhost互相通訊。Pod是短暫的，不是持續性實體。若是Pod是短暫的，那麼我怎麼才能持久化容器數據使其可以跨重啓而存在呢？ Kubernetes支持卷的概念，所以可使用持久化的卷類型。若是Pod是短暫的，那麼重啓時IP地址可能會改變，那麼怎麼才能從前端容器正確可靠地指向後臺容器呢？這時可使用Service。服務器

Lable

　　一些Pod有Label。一個Label是attach到Pod的一對鍵/值對，用來傳遞用戶定義的屬性。好比，你可能建立了一個"tier"和「app」標籤，經過Label（tier=frontend, app=myapp）來標記前端Pod容器，使用Label（tier=backend, app=myapp）標記後臺Pod。而後可使用Selectors選擇帶有特定Label的Pod，而且將Service或者Replication Controller應用到上面。網絡

Replication Controller

　　Replication Controller確保任意時間都有指定數量的Pod「副本」在運行。若是爲某個Pod建立了Replication Controller而且指定3個副本，它會建立3個Pod，而且持續監控它們。若是某個Pod不響應，那麼Replication Controller會替換它，保持總數爲3.以下面的動畫所示：架構

　　若是以前不響應的Pod恢復了，如今就有4個Pod了，那麼Replication Controller會將其中一個終止保持總數爲3。若是在運行中將副本總數改成5，Replication Controller會馬上啓動2個新Pod，保證總數爲5。還能夠按照這樣的方式縮小Pod，這個特性在執行滾動升級時頗有用。
　　當建立Replication Controller時，須要指定兩個東西：app

Pod模板：用來建立Pod副本的模板
Label：Replication Controller須要監控的Pod的標籤。

　　如今已經建立了Pod的一些副本，那麼在這些副本上如何均衡負載呢？咱們須要的是Service。

Service

　　Service是定義一系列Pod以及訪問這些Pod的策略的一層抽象。Service經過Label找到Pod組。由於Service是抽象的，因此在圖表裏一般看不到它們的存在，這也就讓這一律念更難以理解。

　　假定有2個後臺Pod，而且定義後臺Service的名稱爲‘backend-service’，lable選擇器爲（tier=backend, app=myapp）。backend-service 的Service會完成以下兩件重要的事情：

會爲Service建立一個本地集羣的DNS入口，所以前端Pod只須要DNS查找主機名爲 ‘backend-service’，就可以解析出前端應用程序可用的IP地址。
如今前端已經獲得了後臺服務的IP地址，可是它應該訪問2個後臺Pod的哪個呢？Service在這2個後臺Pod之間提供透明的負載均衡，會將請求分發給其中的任意一個（以下面的動畫所示）。經過每一個Node上運行的代理（kube-proxy）完成。這裏有更多技術細節。

　　若是不進入網絡配置，那麼達到透明的負載均衡目標所涉及的底層網絡和路由相對先進。

　　有一個特別類型的Kubernetes Service，稱爲'LoadBalancer'，做爲外部負載均衡器使用，在必定數量的Pod之間均衡流量。好比，對於負載均衡Web流量頗有用。

Pod與Service

　　每一個Pod都提供了一個獨立的Endpoint（Pod IP+ContainerPort）以被客戶端訪問，多個Pod副本組成了一個集羣來提供服務，通常的作法是部署一個負載均衡器來訪問它們，爲這組Pod開啓一個對外的服務端口如8000，而且將這些Pod的Endpoint列表加入8000端口的轉發列表中，客戶端能夠經過負載均衡器的對外IP地址+服務端口來訪問此服務。運行在Node上的kube-proxy其實就是一個智能的軟件負載均衡器，它負責把對Service的請求轉發到後端的某個Pod實例上，而且在內部實現服務的負載均衡與會話保持機制。Service不是共用一個負載均衡器的IP地址，而是每一個Servcie分配一個全局惟一的虛擬IP地址，這個虛擬IP被稱爲Cluster IP。

Node IP

　　Node節點的IP地址，是Kubernetes集羣中每一個節點的物理網卡的IP地址，是真是存在的物理網絡，全部屬於這個網絡的服務器之間都能經過這個網絡直接通訊；

Pod IP

　　Pod的IP地址，是Docker Engine根據docker0網橋的IP地址段進行分配的，一般是一個虛擬的二層網絡，位於不一樣Node上的Pod可以彼此通訊，須要經過Pod IP所在的虛擬二層網絡進行通訊，而真實的TCP流量則是經過Node IP所在的物理網卡流出的；

Cluster IP

Service的IP地址。特性以下：
僅僅做用於Kubernetes Servcie這個對象，並由Kubernetes管理和分配IP地址；
沒法被Ping，由於沒有一個「實體網絡對象」來響應；
只能結合Service Port組成一個具體的通訊端口；
Node IP網、Pod IP網域Cluster IP網之間的通訊，採用的是Kubernetes本身設計的一種編程方式的特殊的路由規則，與IP路由有很大的不一樣；

Node

　　節點（上圖橘色方框）是物理或者虛擬機器，做爲Kubernetes worker，一般稱爲Minion。每一個節點都運行以下Kubernetes關鍵組件：

Kubelet：是主節點代理。
Kube-proxy：Service使用其將連接路由到Pod，如上文所述。
Docker或Rocket：Kubernetes使用的容器技術來建立容器。

Kubernetes Master

　　集羣擁有一個Kubernetes Master。Kubernetes Master提供集羣的獨特視角，而且擁有一系列組件，好比Kubernetes API Server。API Server提供能夠用來和集羣交互的REST端點。master節點包括用來建立和複製Pod的Replication Controller。