?
在學(xué)習(xí)k8s之前，必須先了解 Kubernetes 的幾個重要概念，它們是組成 Kubernetes 集群的基石。先作大致了解，后續(xù)再詳細分享。（參考Kubernetes權(quán)威指南）

一、Master
Kubernetes 里的Master指的是集群的控制節(jié)點， 每個Kubernetes 集群里至少需要有一個Master節(jié)點負責(zé)整個集群的管理和控制，基本上Kubernetes的所有控制命令都發(fā)給它，它來負責(zé)具體的執(zhí)行過程，我們后面執(zhí)行的所有命令基本都是在Master節(jié)點上運行。為了實現(xiàn)高可用，可以運行多個Master。

Master節(jié)點上運行著以下一組關(guān)鍵進程。

• Kubernetes API Server(kube-apiserver), 提供 HTTP Rest 接口的關(guān)鍵服務(wù)程序，kubernets里所有資源增、刪、改、查等操作的唯一入口，也是集群控制的入口進程。
• Kubernetes Controller Manager(kube-controller-manager)，所有資源對象的自動化控制中心可以理解為資源對象的大總管。
• Kubernetes Scheduler(kube-scheduler)，資源調(diào)度(pod)的進程，相當(dāng)于調(diào)度室。
• etcd Server，Kubernetes 里所有資源對象的數(shù)據(jù)全部是保持在etcd中，etcd是一種key-value類型的數(shù)據(jù)庫

二、Node
Node 的職責(zé)是運行各種容器應(yīng)用。Node 由 Master 管理，Node 上有相應(yīng)的服務(wù)負責(zé)監(jiān)控并匯報容器的狀態(tài)，并根據(jù) Master 的要求管理容器的生命周期。Node 可以是物理機或者是虛擬機，可以是Windows或者是Linux的操作系統(tǒng)。Master節(jié)點也可以充當(dāng)為node節(jié)點。

Node運行著一些關(guān)鍵進程：

• kubelet：負責(zé)Pod對應(yīng)的容器的創(chuàng)建、啟停等任務(wù)，同時與Master節(jié)點密切協(xié)作，實現(xiàn)集群管理的基本功能。
• kube-proxy：實現(xiàn)Kubernetes Service的通信與負載均衡機制的重要組件。
• Docker Engine （docker）：Docker引擎，負責(zé)本機的容器創(chuàng)建和管理工作。

我們可以執(zhí)行下述命令查看集群中有多少個Node（master節(jié)點也算是node節(jié)點中的一種）：

[root@k8s-m1 ~]# kubectl get node
NAME     STATUS   ROLES    AGE    VERSION
k8s-m1   Ready    master   111d   v1.19.16
k8s-m2   Ready    master   111d   v1.19.16
k8s-m3   Ready    master   111d   v1.19.16

三、Pod
Pod 是 Kubernetes 的最小工作單元。每個 Pod 包含一個或多個容器。Pod 中的容器會作為一個整體被 Master 調(diào)度到某個 Node 上運行。(可以把pod想象成豌豆莢，里面的豌豆就是容器，可以有一個或多個。)
說到Pod，簡單介紹其概念。首先，Pod運行在一個我們稱之為節(jié)點（Node）的環(huán)境中，這個節(jié)點可能是物理機或虛擬機，通常一個節(jié)點上上面運行幾百個Pod；其次每個Pod運行著一個特殊的被稱之為根容器（Pause），和一組用戶容器組成。一方面，用Pause 容器的狀態(tài)代表整個容器組的狀態(tài)；另一方面，這些業(yè)務(wù)容器共享根容器（Pause）的網(wǎng)絡(luò)棧和Volume掛載卷，因此它們之間的通信和數(shù)據(jù)交換效率更為高效。在設(shè)計時我們可以充分利用這一特性將一組密切相關(guān)的服務(wù)進程放到同一個Pod中。最后需要注意的是并不是每一個Pod和它里面運行的容器都能映射到一個Service上，只有那些提供服務(wù)的一組Pod才會被映射成一個服務(wù)。

Kubernetes 引入 Pod 主要基于下面兩個目的：

• 可管理性:
  在一組容器作為一個單元的情況下，我們難以對“整體”簡單地進行判斷及有效地進行行動。比如，一個容器死亡了，此時算是整體死亡么？引入業(yè)務(wù)無關(guān)并且不易死亡的Pause容器作為Pod的根容器，以它的狀態(tài)代表整體容器組的狀態(tài)，就簡單、巧妙地解決了這個難題。
• 通信和資源共享:
  Pod里的多個業(yè)務(wù)容器共享Pause容器的IP，即相同的 IP 地址和 Port 空間。它們可以直接用 localhost 通信。同樣的，這些容器可以共享存儲，當(dāng) Kubernetes 掛載 volume 到 Pod，本質(zhì)上是將 volume 掛載到 Pod 中的每一個容器。這樣既簡化了密切關(guān)聯(lián)的業(yè)務(wù)容器之間的通信問題，也很好地解決了它們之間的文件共享問題。

靜態(tài)Pod & 普通Pod

• 普通的Pod:
  普通Pod一旦被創(chuàng)建，就會被放入到etcd中存儲，隨后會被Kubernetes Master調(diào)度到某個具體的Node上并進行綁定(Binding),隨后該Pod 被對應(yīng)的Node上的kubelet進程實例化成一組相關(guān)的docker容器運行起來。
  當(dāng)Pod里的某個容器停止時，Kubernetes會自動檢測到這個問題并且重新啟動這個Pod (重啟Pod里的所有容器)，如果Pod所在的Node宕機，則會將這個Node上所有的Pod從新調(diào)度到其他節(jié)點上。

• 靜態(tài)Pod (Static Pod):
  靜態(tài)Pod不存放在Kubernetes的etcd存儲里，而是存放在某個具體的Node上的文件夾中（如果是k8s集群是通過kubeadm部署的，該文件夾默認是/etc/kubernetes/manifests/），并且只在此Node上啟動運行。
  靜態(tài)Pod是由kubelet進行管理的僅存在于特定Node上的Pod。他們不能通過API Server進行管理，無法與ReplicationController(RC)、Deployment、或者DaemonSet進行關(guān)聯(lián)，并且kubelet也無法對它們進行健康檢查。靜態(tài)Pod總是由kubelet進行創(chuàng)建的，并且總是在kubelet所在的Node上運行的

三、副本控制器類型（Pod叫副本）
ReplicationController （簡稱為RC）
ReplicaSet (簡稱為RS)
Deployment
StatefulSet
DaemonSet
Job,Cronjob
Pods 有兩種使用方式：
運行單一容器:
one-container-per-Pod 是 Kubernetes 最常見的模型，這種情況下，只是將單個業(yè)務(wù)容器簡單封裝成 Pod。即便是只有一個容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。

運行多個容器:
但問題在于：哪些容器應(yīng)該放到一個 Pod 中？
答案是：這些容器聯(lián)系必須 非常緊密，而且需要 直接共享資源。

示例：
下面這個 Pod 包含兩個容器：一個 File Puller，一個是 Web Server。他們兩個container的net namespace、uts namespace、ipc namespace是屬于共享的。 mnt namespace、user namespace、pid namespace是互相隔離的。

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

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

版本標簽：“release”:“stable”,“release”:“canary”…
環(huán)境標簽：“environment”:“dev”,“environment”:“qa”,“environment”:“production”
架構(gòu)標簽：“tier”:“fronted”,“tier”:“backend”,“tier”:"middleware”
分區(qū)標簽：“partition”:“customerA”,“partition”:"customerB”…
質(zhì)量管控標簽：“track”:“daily”:“rack”:“weekly”

Label相當(dāng)于我們熟悉的“標簽”，給某個資源對象定義一個Label，就相當(dāng)于給它打了一個標簽，隨后可以通過Label Selector（標簽選擇器）查詢和篩選擁有某些Label的資源對象，Kubernetes通過這種方式實現(xiàn)了類似SQL的簡單又通用的對象查詢機制。

Label Selector可以被類比為SQL語句中的where查詢條件，例如，name=redis-slave這個label Selector作用于Pod時，可以被類比為select * from pod where pod’s name = 'redis-slave’這樣的語句。當(dāng)前有兩種Label Selector的表達式：基于等式的（Equality-based）和基于集合的（Set-based），前者采用“等式類”的表達式匹配標簽，下面是一些具體的例子。

• 基于等式的表達式匹配標簽實例：
  name=redis-slave：匹配所有具有標簽name=redis-slave的資源對象。
  env != production：匹配所有不具有標簽env=production的資源對象。

• 基于集合方式的表達式匹配標簽實例：
  name in (redis-master,redis-slave)：匹配所有具有標簽name=redis-master或者name=redis-slave的資源對象。
  name notin (php-frontend)：匹配所有不具有標簽name=php-frontend的資源對象。

可以通過多個Label Selector表達式的組合實現(xiàn)復(fù)雜的條件，多個表達式之間用“,”進行分隔即可，幾個條件之間是“AND”的關(guān)系，即同時滿足多個條件，比如下面的例子：

name=redis-slave,env!=production
name notin (php-fronted),env!=production

Label Selector在Kubernetes中重要使用場景有以下幾種:

• kube-controller進程通過資源對象RC上定義都Label Selector來篩選要監(jiān)控的Pod副本的數(shù)量，從而實現(xiàn)Pod副本的數(shù)量始終符合預(yù)期設(shè)定的全自動控制流程。
• kube-proxy進程通過Service的Label Selector來選擇對應(yīng)的Pod，自動建立起每個Service到對應(yīng)Pod的請求轉(zhuǎn)發(fā)路由表，從而實現(xiàn)Service的智能負載均衡機制。
  通過對某些Node定義特定的Label，并且在Pod定義文件中使用NodeSelector這種標簽調(diào)度策略，kube-scheduler進程可以實現(xiàn)Pod“定向調(diào)度”的特性。
• 前面我們只是介紹了一個name=XXX的Label Selector。讓我們看一個更復(fù)雜的例子。假設(shè)為Pod定義了Label: release、env和role，不同的Pod定義了不同的Label值，如圖下圖所示，如果我們設(shè)置了“role=frontend”的Label Selector，則會選取到Node 1和Node 2上到Pod。

而設(shè)置“release=beta”的Label Selector，則會選取到Node 2和Node 3上的Pod，如下圖所示。

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

五、service
Service也是Kubernetes里的最核心的資源對象之一，Kubernetes里的每個Service其實就是我們經(jīng)常提起的微服務(wù)架構(gòu)中的一個“微服務(wù)”，之前我們所說的Pod、RC等資源對象其實都是為這節(jié)所說的“服務(wù)”------Kubernetes Service作“嫁衣”的。下圖顯示了Pod、RC與Service的邏輯關(guān)系。

Service和ReplicationController之間的關(guān)系
對于這兩種對象的Label選擇器是用map定義在json或者yaml文件中的，并且只支持基于等式(Equality-based)的條件：

"selector": { "component" : "redis",}
#要么：
selector: component: redis

此選擇器（分別為json或yaml格式）等同于component=redis或component in (redis)。

支持set-based的資源
Job，Deployment，Replica Set，和Daemon Set，支持基于等式和基于集合方式(set-based)的兩種表達式。

selector:
  matchLabels:
    component: redis

matchLabels 是一個{key,value}的映射。一個單獨的 {key,value} 。

selector:
  matchExpressions:
    - {key: tier, operator: In, values: [prod,backup]}       
    - {key: environment, operator: NotIn, values: [dev]}

注意：以上實例表示
key 鍵 tier
operator 操作符 in
values 值 [prod,backup]
表示key鍵tier要包含cache和backup

matchExpressions 是一個pod的選擇器條件的list 。有效運算符包含In, NotIn, Exists, 和DoesNotExist。在In和NotIn的情況下，value必須不能為空列表。Exists和DoesNotExist的情況下，value必須為空列表。當(dāng)包含 matchLabels 和 matchExpressions都純在時，會用AND符號連接，他們必須都被滿足才能完成匹配。

六、Replication Controller
RC是Kubemetes系統(tǒng)中的核心概念之一，簡單來說，它其實是定義了一個期望的場景，即聲明某種Pod的副本數(shù)量在任意時刻都符合某個預(yù)期值，所以RC的定義包括如下幾個部分。
Pod期待的副本數(shù)（replicas）。
用于篩選目標Pod的LabelSelector.
當(dāng)Pod的副本數(shù)量小于預(yù)期數(shù)量時，用于創(chuàng)建新Pod的Pod模板（template）。

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

七、Deployment
Deployment是Kubemetesvl .2 引入的新概念，引入的目的是為了更好地解決Pod的編排問題。 為此，Deployment在內(nèi)部使用了Replica Set來實現(xiàn)目的，無論從Deployment的作用與目的、它的Yaml定義，還是從它的具體命令行操作來看，我們都可以把它看作RC的一次升級，兩者的相似度超過90%。
Deployment相對于RC的一個最大升級是我們可以隨時知道當(dāng)前Pod“部署”的進度。實
際上由于一個Pod的創(chuàng)建、調(diào)度、綁定節(jié)點及在目標Node上啟動對應(yīng)的容器這一完整過程需
要一定的時間，所以我們期待系統(tǒng)啟動N個Pod副本的目標狀態(tài)，實際上是一個連續(xù)變化的“部
署過程”導(dǎo)致的最終狀態(tài)。

Deployment的典型使用場景有以下幾個。
創(chuàng)建一個Deployment對象來生成對應(yīng)的ReplicaSet井完成Pod副本的創(chuàng)建過程。
檢查Deployment的狀態(tài)來看部署動作是否完成（Pod副本的數(shù)量是否達到預(yù)期的值）。
更新Deployment以創(chuàng)建新的Pod （比如鏡像升級）。
如果當(dāng)前Deployment不穩(wěn)定，則回滾到一個早先的Deployment版本。
暫停Deployment 以便于一次性修改多個PodTemplateSpec 的配置項，之后再恢復(fù)Deployment，進行新的發(fā)布。
擴展Deployment以應(yīng)對高負載。
查看Deployment的狀態(tài)，以此作為發(fā)布是否成功的指標。
清理不再需要的舊版本ReplicaSets。

八、StatefulSet
在Kubemetes系統(tǒng)中， Pod的管理對象RC、 Deplo嚴nent、 DaemonSet和Job都是面向無狀態(tài)的服務(wù)。但現(xiàn)實中有很多服務(wù)是有狀態(tài)的，特別是一些復(fù)雜的中間件集群，例如MySQL集群、 MongoDB集群、Kafka集群、 ZooKeeper集群等， 這些應(yīng)用集群有以下一些共同點：

每個節(jié)點都有固定的身份田，通過這個ID，集群中的成員可以相互發(fā)現(xiàn)并且通信。
集群的規(guī)模是比較固定的，集群規(guī)模不能隨意變動。

集群里的每個節(jié)點都是有狀態(tài)的，通常會持久化數(shù)據(jù)到永久存儲中。
如果磁盤損壞，則集群里的某個節(jié)點無法正常運行，集群功能受損。

九、Horizontal Pod Autoscaler （水平pod自動伸縮）

應(yīng)用場景，分布式系統(tǒng)要能夠根據(jù)當(dāng)前負載的變化情況自動觸發(fā)水平擴展或縮容的行為，因為這一過程可能是頻繁發(fā)生的、不可預(yù)料的，所以手動控制的方式是不現(xiàn)實的。

HPA與之前的RC、 Deployment一樣，也屬于一種Kubemetes資源對象。通過追蹤分析RC控制的所有目標Pod的負載變化情況，來確定是否需要針對性地調(diào)整目標Pod的副本數(shù)，這是HPA的實現(xiàn)原理。常用的HPA可以有以下兩種方式作為Pod負載的度量指標。
CPUUtilizationPercentage。
應(yīng)用程序自定義的度量指標，比如服務(wù)在每秒內(nèi)的相應(yīng)的請求數(shù)（TPS或QPS）。

十、Service （服務(wù)）
Service也是Kubemetes里的最核心的資源對象之一， Kubernetes里的每個Service其實就是我們經(jīng)常提起的微服務(wù)架構(gòu)中的一個“微服務(wù)”，之前我們所說的Pod、 RC等資源對象其實都是為這節(jié)所說的“服務(wù)”---- Kubemetes Service作“嫁衣”的。 下圖顯示了Pod、 RC與Service的邏輯關(guān)系。

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

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

十二、Persistent Volume

之前我們提到的Volume是定義在Pod上的，屬于“計算資源”的一部分，而實際上，“網(wǎng)絡(luò)存儲”是相對獨立于“計算資源”而存在的一種實體資源。比如在使用虛擬機的情況下，我們通常會先定義一個網(wǎng)絡(luò)存儲，然后從中劃出一個“網(wǎng)盤”并掛接到虛擬機上。PersistentVolume （簡稱PV）和與之相關(guān)聯(lián)的PersistentVolume Claim （簡稱PVC）也起到了類似的作用。
PV可以理解成Kubemetes集群中的某個網(wǎng)絡(luò)存儲中對應(yīng)的一塊存儲，它與Volume很類似，但有以下區(qū)別。
PV只能是網(wǎng)絡(luò)存儲，不屬于任何Node，但可以在每個Node上訪問。
PV井不是定義在Pod上的，而是獨立于Pod之外定義。
PV 目前支持的類型包括： gcePersistentDisk、 AWSElasticBlockStore、 AzureFile、
AzureDisk、 FC(Fibre Channel）、 Flocker、 NFS、 iSCSI、 RBD(Rados Block Device）、
CephFS、Cinder、GlusterFS、Vsphere Volume、QuobyteVolumes、VMwarePhoton、Portwonc
Volumes、 ScaleIOVolumes和HostPath。

十三、Namespace （命名空間）

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

默認使用的命名空間為default，默認的命名空間有default、kube-system

以上只是做一個大致了解，后面將對各種資源詳細分享。

更多關(guān)于kubernetes的知識分享，請前往博客主頁。編寫過程中，難免出現(xiàn)差錯，敬請指出
?文章來源地址http://www.zghlxwxcb.cn/news/detail-500972.html

到了這里，關(guān)于【kubernetes系列】Kubernetes中的重要概念的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！