Kubernetes的概念是什么

這篇文章主要介紹“Kubernetes的概念是什么”，在日常操作中，相信很多人在Kubernetes的概念是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kubernetes的概念是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

在開始使用之前，應當先了解一下關于Kubernetes的相關概念術語，對后續(xù)的學習、使用將有很大的幫助。（Kubernetes的概念比較多，建議加強理解，并清楚各種所處位置及關聯(lián)?。?/p>

Kubernetes中的大部分概念，如：Node、Pod、Replication Controller、Service等都可以看作是一種資源對象，幾乎所有資源對象都可以通過Kubernetes提供的kubectl工具（或者API接口）執(zhí)行增、刪、改、查等操作并將其保存在etcd中持久化存儲。

從這個角度來看，Kubernetes其實是一個高度自動化的資源控制系統(tǒng)，它通過跟蹤對比etcd庫里保存的“資源期望狀態(tài)”與當前環(huán)境中的“實際資源狀態(tài)”的差異來實現(xiàn)自動控制和自動糾錯的高級功能。

本文將介紹Kubernetes中重要的資源對象，即：Kubernetes的基本概念和術語。

1、Master

Master是指Kubernetes集群中的控制節(jié)點（Master Node），在每個Kubernetes集群里都需要有一個Master來負責整個集群的管理和控制，基本所有的控制命令都發(fā)給它，它負責具體的執(zhí)行過程，后續(xù)執(zhí)行的所有命令基本都是在Master上運行。

Master提供集群的獨特視角，并且擁有一系列組件，比如Kubernetes API Server。API Server提供可以用來和集群交互的REST端點?？梢酝ㄟ^命令行或圖形化界面來維護pod、副本和服務。

在Master上包括以下組件：

• etcd： 分布式key-value存儲，保存集群的狀態(tài)數(shù)據(jù)、資源對象數(shù)據(jù)。

• API Server(kube-api-server)： Kubernetes提供的HTTP Rest接口，是所有資源的增、刪、改、查等操作的唯一入口，也是集群控制的入口進程。

• Controllers(kube-controller-manager)： Kubernetes里所有資源對象的自動化控制中心。

• Scheduler(kube-scheduler)： 負責資源調(diào)度（Pod調(diào)度）的進程，相當于公交公司的"調(diào)度室"。

2、Node

除了Master，Kubernetes集群中的其他集群被稱為Node，即：Worker Node（工作節(jié)點）。與Master一樣，Node可以是一臺物理主機，也可以是一臺虛擬機。

Node是Kubernetes集群中的工作負載節(jié)點，每個Node都會被Master分配一些工作負載，當某個Node宕機時，其上的工作負載會被Master自動轉(zhuǎn)移到其他節(jié)點上。

每個Node上都運行著以下關鍵組件：

• kubelet： 負責Pod對應的容器創(chuàng)建、啟停等任務，同時與Master密切協(xié)作，實現(xiàn)集群管理的基本功能。

• kube-proxy： 實現(xiàn)Kubernetes Service的通信與負載均衡機制的重要組件。

• Container Runtime： 下載鏡像、運行容器。如Docker引擎，負責本機的容器創(chuàng)建和管理工作。

Node可以再運行期間動態(tài)增加調(diào)整到Kubernetes集群中，默認情況下kubelet會向Master注冊自己。一旦Node被納入集群管理范圍，kubelet進程就會定時向Master上報自己的信息，如操作系統(tǒng)、Docker版本、機器CPU和內(nèi)存、以及當前有哪些Pod在運行等，這樣Master就可以獲知每個Node的資源使用情況，并實現(xiàn)高效均衡的資源調(diào)度策略。而某個Node在超過指定時間不上報信息時，會被Master判定為“失聯(lián)”狀態(tài)，標記為不可用（Not Ready）,隨后Master會觸發(fā)“工作負載大轉(zhuǎn)移”的自動流程。

執(zhí)行命令kubectl get nodes可以查看在集群中有多少個Node：

[xcbeyond@localhost ~]$ kubectl get nodes
NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    master   17d   v1.19.0

然后通過kubectl describe node <node_name>查看某個Node的詳細信息：

[xcbeyond@localhost ~]$ kubectl describe node minikube
Name:               minikube
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    ……

3、Pod

Pod是Kubernetes中的原子對象，是基本構(gòu)建單元。

Pod表示集群上一組正在運行的容器。通常創(chuàng)建Pod是為了運行單個主容器。Pod 還可以運行可選的sidecar容器，以實現(xiàn)諸如日志記錄之類的補充特性。（如：在Service Mesh中，和應用一起存在的istio-proxy、istio-init容器）

通常用Deployment來管理Pod。

一個Pod中可以包含多個容器（其他容器作為功能補充），負責處理容器的數(shù)據(jù)卷、秘鑰、配置。

如下圖所示是Pod的組成示意圖，我們可以看到每個Pod都有一個特殊的被稱為“根容器”的Pause容器。Pause容器對應的鏡像屬于Kubernetes平臺的一部分，除了Pause容器，每個Pod還包含一個或多個緊密相關的用戶業(yè)務容器。

為什么Kubernetes會設計出一個全新的Pod概念，并且Pod要有這樣特殊的組成結(jié)構(gòu)？

• 在一組容器作為一個單元整體的情況下，我們難以對“整體”簡單地進行判斷及有效地進行控制。比如，一個容器死亡了，此時算是整體死亡么？引入業(yè)務無關并且不易死亡的Pause容器作為Pod的根容器，以它的狀態(tài)代表整體容器組的狀態(tài)，就簡單、巧妙地解決了這個難題。

• Pod里的多個業(yè)務容器共享Pause容器的IP，共享Pause容器掛接的Volume，這樣既簡化了密切關聯(lián)的業(yè)務容器之間的通信問題，也很好地解決了它們之間的文件共享問題。

Kubernetes為每個Pod都分配了唯一的IP地址，稱之為Pod IP，一個Pod里的多個容器共享Pod IP地址。

Kubernetes要求底層網(wǎng)絡支持集群內(nèi)任意兩個Pod之間的TCP/IP直接通信，這通常采用虛擬二層網(wǎng)絡技術來實現(xiàn)，例如Flannel、Open vSwitch等，因此我們需要牢記一點：在Kubernetes里，一個Pod里的容器與另外主機上的Pod容器能夠直接通信。

Pod有兩種類型：

• 普通的Pod

• 靜態(tài)Pod（Static Pod）

后者比較特殊，它并不存放在Kubernetes的etcd存儲里，而是存放在某個Node上的一個有個文件中，并且只在此Node上啟動運行。而普通的Pod一旦被創(chuàng)建，就會被放入到etcd中存儲，隨后會被Kubernetes Master調(diào)度到某個具體的Node上并進行綁定（Binding），隨后該Pod被對應的Node上的kubelet進程實例化成一組相關的Docker容器并且啟動起來。

在默認情況下，當Pod里的某個容器停止時，Kubernetes會自動檢測到這個問題并且重新啟動這個Pod（重啟Pod里的所有容器），如果Pod所在的Node宕機，則會將這個Node上的所有Pod重新調(diào)度到其他節(jié)點上。Pod、容器與Node的關系圖如下圖所示。

Pod 的生命周期是不確定的，可能非常短暫，但 Pod 具有很強的再生能力，在死后可以自動重新啟動（重啟機制）。Pod生命周期整個過程中，通?？赡芴幱谝韵挛鍌€階段之一：

• Pending： Pod定義正確，提交到Master，但其所包含的容器鏡像還未完全創(chuàng)建。通常，Master對Pod進行調(diào)度需要一些時間，Node進行容器鏡像的下載也需要一些時間，啟動容器也需要一定時間。

• Running： Pod已經(jīng)被分配到某個Node上，并且所有的容器都被創(chuàng)建完畢，至少有一個容器正在運行中，或者有容器正在啟動或重啟中。

• Succeeded： Pod中所有的容器都成功運行結(jié)束，并且不會被重啟。這是Pod的一種最終狀態(tài)。

• Failed： Pod中所有的容器都運行結(jié)束了，其中至少有一個容器是非正常結(jié)束的（exit code不是0）。這也是Pod的一種最終狀態(tài)。

• Unknown： 無法獲得Pod的狀態(tài)，通常是由于無法和Pod所在的Node進行通信。

4、Label

Label（標簽）是Kubernetes中另外一個核心概念。一個Label是一個key=value的鍵值對，其中key與value由用戶自己指定。Label可以被附加到各種資源對象上，例如Node、Pod、Service、RC等，一個資源對象可以定義任意數(shù)量的Label，同一個Label也可以被添加到任意數(shù)量的資源對象上。Label通常在資源對象定義時確定，也可以在對象創(chuàng)建后動態(tài)添加或刪除。

一般來說，我們會給指定的資源對象定義多個label，來實現(xiàn)多維度的資源分組管理，以便靈活、方便地進行資源分配、調(diào)度、配置、部署等管理工作。例如：部署不同版本的應用到不同的環(huán)境中，或者監(jiān)控和分析應用（日志記錄，監(jiān)控，報警等）。一些常用的Label示例如下：

• 版本標簽：release：stable、release: canary

• 環(huán)境標簽：environment: dev、environemnt: qa、environment: production

• 架構(gòu)標簽：tier: frontend、tier: backend、tier: middleware

• ……

某個資源對象定義了Label后，可以通過Label Selector（標簽選擇器）查詢和篩選Label的資源對象，Kubernetes通過這種方式實現(xiàn)了類似SQL的對象查詢機制。

通常我們通過描述文件中的spec.selector字段來指定Label，從而Kubernetes尋找到所有包含你指定Label的對象，進行管理。

Kubernetes目前支持兩種類型的Label Selector：

• 基于等式的Selector（Equality-based）：等式雷表達式匹配標簽。

• 基于集合的Selector（Set-based）：集合操作類表達式匹配標簽。

使用Label可以給對象創(chuàng)建一組或多組標簽，Label和Label Selector共同構(gòu)成了Kubernetes系統(tǒng)中最核心的應用模型，使得對象能夠精細分組、管理，同時實現(xiàn)了集群的高可用性。

5、Replication Controller

Replication Controller，簡稱RC，是Kubernetes中核心概念之一，定義了一個期望的場景，即：聲明某種Pod的副本數(shù)量在任意時刻都符合某個預期值。

RC的定義包括以下幾個部分：

• Pod預期的副本數(shù)量。

• 用于篩選目標Pod的Label Selector。

• 當Pod的副本數(shù)量小于預期數(shù)量時，用于創(chuàng)建新Pod的Pod模板。

下面以有3個Node的集群為例進行，說明Kubernetes如何通過RC來實現(xiàn)Pod副本數(shù)量自動控制的機制。

假如在我們的RC里定義redis-slave這個Pod需要保持2個副本，系統(tǒng)將可能在其中的兩個Node創(chuàng)建Pod，如下圖所示：

假如Node 2上的Pod意外終止，則根據(jù)RC定義的replicas數(shù)量2，Kubernetes將自動創(chuàng)建并啟動一個新的Pod，以保證整個集群中始終有兩個redis-slave運行。如下圖所示，Kubernetes可能選擇Node 3或者Node 1來創(chuàng)建一個新的Pod。

此外，在運行時，我們可以通過修改RC的副本數(shù)量，來實現(xiàn)Pod的動態(tài)縮放（Scaling），可通過執(zhí)行kubectl scale rc redis-slave --replicas=3命令一鍵完成。執(zhí)行結(jié)果示意如下圖所示：

注意：刪除RC并不會影響通過該RC創(chuàng)建好的Pod。 刪除所有Pod，可以設置replicas的值為0，然后更新該RC。另外，kubectl也提供了stop和delete命令來一次性刪除RC和RC控制的全部Pod。

最后，總結(jié)一下RC的特性和作用：

• 大多數(shù)情況下，通過自定義一個RC實現(xiàn)Pod的創(chuàng)建過程及副本數(shù)量的自動控制。

• RC里包含完整的pod定義模板。

• RC通過label selector機制實現(xiàn)對pod副本的自動控制。

• 通過改變RC里的Pod副本數(shù)量，實現(xiàn)對Pod的擴容和縮容功能。

• 通過改變RC里Pod模板中的鏡像版本，可以實現(xiàn)Pod的滾動升級功能。

6、Deployment

Deployment是Kubernetes在1.2版本中引入的新概念，用于更好地解決Pod的編排問題。為此，Deployment在內(nèi)部使用了Replica Set來實現(xiàn)，無論從Deployment的作用、YAML定義，還是從它的具體命令行操作來看，我們都可以把它看作是RC的一次升級。

Deployment相對于RC的一個最大升級是我們可以隨時知道當前Pod部署的進度。

典型使用場景：

• 創(chuàng)建Deployment對象來生成對應的Replica set并完成Pod副本的創(chuàng)建。

• 檢查Deployment的狀態(tài)來看部署動作是否完成（Pod副本數(shù)是否達到預期值）。

• 更新Deployment來創(chuàng)建新的Pod。

• 如果當前Deployment不穩(wěn)定，則回滾到一個先前的Deployment版本。

• 暫停Deployment以便于一次性修改多個PodTemplateSpec的配置項，之后再恢復Deployment，進行新的發(fā)布。

• 擴展Deployment以應對高負載。

• 查看Deployment狀態(tài)，以此作為發(fā)布是否成功的指標。

7、StatefulSet

在Kubernetes中，Pod的管理對象RC、Deployment、DaemonSet和Job都是面向無狀態(tài)的服務。但現(xiàn)實中有很多服務是有狀態(tài)的，特別是一些復雜的中間件集群，例如MySQL集群、MongoDB集群、Kafka集群、Zookeeper集群等，這些應用集群有以下一些共同點。

• 每個節(jié)點都有固定的身份ID，通過這個ID，集群中的成員可以相互發(fā)現(xiàn)并且通信。

• 集群的規(guī)模是比較固定的，集群規(guī)模不能隨意變動。

• 集群里的每個節(jié)點都是有狀態(tài)的，通常會持久化數(shù)據(jù)到永久存儲中。

• 如果磁盤損壞，則集群里的某個節(jié)點無法正常運行，集群功能受損。

如果用RC或Deployment控制Pod副本數(shù)的方式來實現(xiàn)上述有狀態(tài)的集群，則我們會發(fā)現(xiàn)第一點是無法滿足的，因為Pod的名字是隨機產(chǎn)生的，Pod的IP地址也是在運行期才確定且可能有變動的，我們事先無法為每個Pod確定唯一不變的ID，為了能夠在其他節(jié)點上恢復某個失敗的節(jié)點，這種集群中的Pod需要掛接某種共享存儲，為了解決這個問題，Kubernetes從v1.4版本開始引入了PetSet這個新的資源對象，并且在v1.5版本時更名為StatefulSet，StatefulSet從本質(zhì)上來說，可以看作Deployment/RC的一個特殊變種，它有如下一些特性。

• StatefulSet里的每個Pod都有穩(wěn)定、唯一的網(wǎng)絡標識，可以用來發(fā)現(xiàn)集群內(nèi)的其他成員。假設StatefulSet的名字叫kafka，那么第一個Pod叫kafak-0，第二個Pod叫kafak-1，以此類推。

• StatefulSet控制的Pod副本的啟停順序是受控的，操作第n個Pod時，前n-1個Pod已經(jīng)時運行且準備好的狀態(tài)。

• StatefulSet里的Pod采用穩(wěn)定的持久化存儲卷，通過PV/PVC來實現(xiàn)，刪除Pod時默認不會刪除與StatefulSet相關的存儲卷（為了保證數(shù)據(jù)的安全）。

StatefulSet除了要與PV卷捆綁使用以存儲Pod的狀態(tài)數(shù)據(jù)，還要與Headless Service配合使用，即在每個StatefulSet的定義中要聲明它屬于哪個Headless Service。Headless Service與普通Service的關鍵區(qū)別在于，它沒有Cluster IP，如果解析Headless Service的DNS域名，則返回的是該Service對應的全部Pod的Endpoint列表。StatefulSet在Headless Service的基礎上又為StatefulSet控制的每個Pod實例創(chuàng)建了一個DNS域名，這個域名的格式為：

$(podname).$(headless service name)

比如一個3節(jié)點的Kafka的StatefulSet集群，對應的Headless Service的名字為kafka，StatefulSet的名字為kafka，則StatefulSet里面的3個Pod的DNS名稱分別為kafka-0.kafka、kafka-1.kafka、kafka-3.kafka，這些DNS名稱可以直接在集群的配置文件中固定下來。

8、Service

Service也是Kubernetes里的最核心的資源對象之一，Kubernetes里的每個Service其實就是我們經(jīng)常提起的微服務架構(gòu)中的一個“微服務”，上面我們所說的Pod、RC等資源對象其實都是為講解Kubernetes Service做鋪墊的。下圖顯示了Pod、RC與Service的邏輯關系。

從圖中我們看到，Kubernetes的Service定義了一個服務的訪問入口地址，前端的應用（Pod）通過這個入口地址訪問其背后的一組由Pod副本組成的集群實例，Service與其后端Pod副本集群之間則是通過Label Selector來實現(xiàn)“無縫對接”的。而RC的作用實際上是保證Service的服務能力和服務質(zhì)量始終處于預期的標準。

9、Job

Job（批處理任務）通過并行或串行啟動多個進程去處理一批工作，在處理完成后，整個批處理任務結(jié)束。從Kubernetes 1.2版本開始，支持批處理類型的應用，可以通過Kubernetes Job這種新的資源對象定義并啟動一個批處理任務Job。與RC、Deployment、ReplicaSet類似，Job也是用來控制一組Pod容器。

Job負責批量處理短暫的一次性任務 ，即僅執(zhí)行一次的任務，它保證批處理任務的一個或多個Pod成功結(jié)束。

10、Volume

Volume（存儲卷）是Pod中能夠被多個容器訪問的共享目錄。Kubernetes的Volume概念、用途和目的與Docker的Volume比較類似，但兩者不能等價。首先，Kubernetes中的Volume定義在Pod上，然后被一個Pod里的多個容器掛載到具體的文件目錄下；其次，Kubernetes中的Volume中的數(shù)據(jù)也不會丟失。最后，Kubernetes支持多種類型的Volume，例如Gluster、Ceph等先進的分布式文件系統(tǒng)。

11、Namespace

Namespace（命名空間）是Kubernetes系統(tǒng)中的另一個非常重要的概念，Namespace在很多情況下用于實現(xiàn)多租戶的資源隔離。Nameaspace通過將集群內(nèi)部的資源對象“分配”到不同的Namespce中，形成邏輯上分組的不同項目、小組或用戶組，便于不同的分組在共享使用整個集群的資源的同時還能被分別管理。

Kubernetes集群默認會創(chuàng)建一個名為default的Namespace，通過kubectl可以查看：

[xcbeyond@bogon ~]$ kubectl get namespaces
NAME                   STATUS   AGE
default                Active   23d
istio-system           Active   22d
kube-node-lease        Active   23d
kube-public            Active   23d
kube-system            Active   23d
kubernetes-dashboard   Active   23d

如果不特別指定Namespace，則用戶創(chuàng)建的Pod、RC、Service等都將創(chuàng)建到默認的default的Namespace中。

12、Annotation

Annotation（注解）與Label類似，也使用key/value鍵值對的形式進行定義。不同的是Label具有嚴格的命名規(guī)則，它定義的是Kubernetes對象的元數(shù)據(jù)（Metadata），并且用于Label Selector。而Annotation則是用戶任意定義的“附加”信息，以便于外部工具進行查找，很多時候，Kubernetes的模塊自身會通過Annotation的方式標記資源對象的特殊信息。

通常來說，用Annotation來記錄的信息如下：

• build信息、release信息、Docker鏡像信息等，例如時間戳、release id號、PR號、鏡像hash值、docker registry地址等。

• 日志庫、監(jiān)控庫、分析庫等資源庫的地址信息。

• 程序調(diào)試工具信息，例如工具、版本號等。

• 團隊等聯(lián)系信息，例如電話號碼、負責人名稱、網(wǎng)址等。

13、ConfigMap

為了能夠準確、深刻理解Kubernetes ConfigMap的功能和價值，可以先從Docker說起。我們都知道，Docker通過將程序、依賴庫、數(shù)據(jù)及配置文件等“打包固化”到一個不變的鏡像文件，以解決因應用部署差異的難題，但這同時帶來了另一個棘手的問題，即：配置文件中的參數(shù)在運行期間如何修改的問題。為了解決這個問題，Docker提供了以下兩種方式：

• 通過環(huán)境變量來傳遞參數(shù)。

• 通過Docker Volume將容器外的配置文件映射到容器內(nèi)。

在大多數(shù)情況下，我們更傾向于后一種方式，應該大多數(shù)應用通常擁有多個參數(shù)，配置文件映射的方式簡潔。但這種方式也有明顯的缺陷：必須事先在宿主機上創(chuàng)建好配置文件，然后容器啟動時才能夠映射到容器里。

如果在分布式系統(tǒng)中，就會變得更加糟糕，多臺宿主機上創(chuàng)建相同的配置文件，并且要確保這些配置文件的一致性，是很難實現(xiàn)的。為此，Kubernetes引入了ConfigMap，巧妙的解決了這種問題。

把所有的配置項都當作key-value字符串，如：配置項host=192.168.1.1、user=root、password=123456用于表示連接FTP服務器的配置參數(shù)。這些配置項作為Map表中的一項，整個Map的數(shù)據(jù)被持久化存儲在Kubernetes的etcd中，并提供API方便Kubernetes相關組件或應用CRUD操作，這里用來保存配置參數(shù)的Map就是Kubernetes ConfigMap資源對象。

ConfigMap機制： 將存儲在etcd中的ConfigMap通過Volume映射方式變?yōu)槟繕薖od內(nèi)的配置文件，不管目標Pod被調(diào)度到哪臺服務器上，都會自歐東完成映射。如果ConfigMap中的key-value數(shù)據(jù)被修改，則映射到Pod中的“配置文件”也會隨之自動更新。于是，ConfigMap就形成了分布式系統(tǒng)中最為簡單且對應用無侵入的配置中心。

14、總結(jié)

上述的這些概念術語也是Kubernetes的核心組件，它們共同構(gòu)成了Kubernetes的框架和計算模型。通過對它們進行靈活組合，用戶就可以快速、方便地對容器集群進行配置、創(chuàng)建和管理。除了本文介紹的概念外，Kubernetes中還有許多其他的概念，用于輔助配置資源對象，如：LimitRange、ResourceQuota等，更多概念術語可參照官方術語表：https://kubernetes.io/zh/docs/reference/glossary/?fundamental=true

到此，關于“Kubernetes的概念是什么”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>