溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“Kubernetes的概念是什么”，在日常操作中，相信很多人在Kubernetes的概念是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kubernetes的概念是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
在開始使用之前，應當先了解一下關于Kubernetes的相關概念術語，對后續的學習、使用將有很大的幫助。（Kubernetes的概念比較多，建議加強理解，并清楚各種所處位置及關聯！）
Kubernetes中的大部分概念，如：Node、Pod、Replication Controller、Service等都可以看作是一種資源對象，幾乎所有資源對象都可以通過Kubernetes提供的kubectl工具（或者API接口）執行增、刪、改、查等操作并將其保存在etcd中持久化存儲。
從這個角度來看，Kubernetes其實是一個高度自動化的資源控制系統，它通過跟蹤對比etcd庫里保存的“資源期望狀態”與當前環境中的“實際資源狀態”的差異來實現自動控制和自動糾錯的高級功能。
本文將介紹Kubernetes中重要的資源對象，即：Kubernetes的基本概念和術語。
Master是指Kubernetes集群中的控制節點（Master Node），在每個Kubernetes集群里都需要有一個Master來負責整個集群的管理和控制，基本所有的控制命令都發給它，它負責具體的執行過程，后續執行的所有命令基本都是在Master上運行。
Master提供集群的獨特視角，并且擁有一系列組件，比如Kubernetes API Server。API Server提供可以用來和集群交互的REST端點。可以通過命令行或圖形化界面來維護pod、副本和服務。
在Master上包括以下組件：
etcd： 分布式key-value存儲，保存集群的狀態數據、資源對象數據。
API Server(kube-api-server)： Kubernetes提供的HTTP Rest接口，是所有資源的增、刪、改、查等操作的唯一入口，也是集群控制的入口進程。
Controllers(kube-controller-manager)： Kubernetes里所有資源對象的自動化控制中心。
Scheduler(kube-scheduler)： 負責資源調度（Pod調度）的進程，相當于公交公司的"調度室"。
除了Master，Kubernetes集群中的其他集群被稱為Node，即：Worker Node（工作節點）。與Master一樣，Node可以是一臺物理主機，也可以是一臺虛擬機。
Node是Kubernetes集群中的工作負載節點，每個Node都會被Master分配一些工作負載，當某個Node宕機時，其上的工作負載會被Master自動轉移到其他節點上。
每個Node上都運行著以下關鍵組件：
kubelet： 負責Pod對應的容器創建、啟停等任務，同時與Master密切協作，實現集群管理的基本功能。
kube-proxy： 實現Kubernetes Service的通信與負載均衡機制的重要組件。
Container Runtime： 下載鏡像、運行容器。如Docker引擎，負責本機的容器創建和管理工作。
Node可以再運行期間動態增加調整到Kubernetes集群中，默認情況下kubelet會向Master注冊自己。一旦Node被納入集群管理范圍，kubelet進程就會定時向Master上報自己的信息，如操作系統、Docker版本、機器CPU和內存、以及當前有哪些Pod在運行等，這樣Master就可以獲知每個Node的資源使用情況，并實現高效均衡的資源調度策略。而某個Node在超過指定時間不上報信息時，會被Master判定為“失聯”狀態，標記為不可用（Not Ready）,隨后Master會觸發“工作負載大轉移”的自動流程。
執行命令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 ……
Pod是Kubernetes中的原子對象，是基本構建單元。
Pod表示集群上一組正在運行的容器。通常創建Pod是為了運行單個主容器。Pod 還可以運行可選的sidecar容器，以實現諸如日志記錄之類的補充特性。（如：在Service Mesh中，和應用一起存在的istio-proxy、istio-init容器）
通常用Deployment來管理Pod。
一個Pod中可以包含多個容器（其他容器作為功能補充），負責處理容器的數據卷、秘鑰、配置。
如下圖所示是Pod的組成示意圖，我們可以看到每個Pod都有一個特殊的被稱為“根容器”的Pause容器。Pause容器對應的鏡像屬于Kubernetes平臺的一部分，除了Pause容器，每個Pod還包含一個或多個緊密相關的用戶業務容器。
為什么Kubernetes會設計出一個全新的Pod概念，并且Pod要有這樣特殊的組成結構？
在一組容器作為一個單元整體的情況下，我們難以對“整體”簡單地進行判斷及有效地進行控制。比如，一個容器死亡了，此時算是整體死亡么？引入業務無關并且不易死亡的Pause容器作為Pod的根容器，以它的狀態代表整體容器組的狀態，就簡單、巧妙地解決了這個難題。
Pod里的多個業務容器共享Pause容器的IP，共享Pause容器掛接的Volume，這樣既簡化了密切關聯的業務容器之間的通信問題，也很好地解決了它們之間的文件共享問題。
Kubernetes為每個Pod都分配了唯一的IP地址，稱之為Pod IP，一個Pod里的多個容器共享Pod IP地址。
Kubernetes要求底層網絡支持集群內任意兩個Pod之間的TCP/IP直接通信，這通常采用虛擬二層網絡技術來實現，例如Flannel、Open vSwitch等，因此我們需要牢記一點：在Kubernetes里，一個Pod里的容器與另外主機上的Pod容器能夠直接通信。
Pod有兩種類型：
普通的Pod
靜態Pod（Static Pod）
后者比較特殊，它并不存放在Kubernetes的etcd存儲里，而是存放在某個Node上的一個有個文件中，并且只在此Node上啟動運行。而普通的Pod一旦被創建，就會被放入到etcd中存儲，隨后會被Kubernetes Master調度到某個具體的Node上并進行綁定（Binding），隨后該Pod被對應的Node上的kubelet進程實例化成一組相關的Docker容器并且啟動起來。
在默認情況下，當Pod里的某個容器停止時，Kubernetes會自動檢測到這個問題并且重新啟動這個Pod（重啟Pod里的所有容器），如果Pod所在的Node宕機，則會將這個Node上的所有Pod重新調度到其他節點上。Pod、容器與Node的關系圖如下圖所示。
Pod 的生命周期是不確定的，可能非常短暫，但 Pod 具有很強的再生能力，在死后可以自動重新啟動（重啟機制）。Pod生命周期整個過程中，通常可能處于以下五個階段之一：
Pending： Pod定義正確，提交到Master，但其所包含的容器鏡像還未完全創建。通常，Master對Pod進行調度需要一些時間，Node進行容器鏡像的下載也需要一些時間，啟動容器也需要一定時間。
Running： Pod已經被分配到某個Node上，并且所有的容器都被創建完畢，至少有一個容器正在運行中，或者有容器正在啟動或重啟中。
Succeeded： Pod中所有的容器都成功運行結束，并且不會被重啟。這是Pod的一種最終狀態。
Failed： Pod中所有的容器都運行結束了，其中至少有一個容器是非正常結束的（exit code不是0）。這也是Pod的一種最終狀態。
Unknown： 無法獲得Pod的狀態，通常是由于無法和Pod所在的Node進行通信。
Label（標簽）是Kubernetes中另外一個核心概念。一個Label是一個key=value的鍵值對，其中key與value由用戶自己指定。Label可以被附加到各種資源對象上，例如Node、Pod、Service、RC等，一個資源對象可以定義任意數量的Label，同一個Label也可以被添加到任意數量的資源對象上。Label通常在資源對象定義時確定，也可以在對象創建后動態添加或刪除。
一般來說，我們會給指定的資源對象定義多個label，來實現多維度的資源分組管理，以便靈活、方便地進行資源分配、調度、配置、部署等管理工作。例如：部署不同版本的應用到不同的環境中，或者監控和分析應用（日志記錄，監控，報警等）。一些常用的Label示例如下：
版本標簽：release：stable、release: canary
環境標簽：environment: dev、environemnt: qa、environment: production
架構標簽：tier: frontend、tier: backend、tier: middleware
……
某個資源對象定義了Label后，可以通過Label Selector（標簽選擇器）查詢和篩選Label的資源對象，Kubernetes通過這種方式實現了類似SQL的對象查詢機制。
通常我們通過描述文件中的spec.selector字段來指定Label，從而Kubernetes尋找到所有包含你指定Label的對象，進行管理。
Kubernetes目前支持兩種類型的Label Selector：
基于等式的Selector（Equality-based）：等式雷表達式匹配標簽。
基于集合的Selector（Set-based）：集合操作類表達式匹配標簽。
使用Label可以給對象創建一組或多組標簽，Label和Label Selector共同構成了Kubernetes系統中最核心的應用模型，使得對象能夠精細分組、管理，同時實現了集群的高可用性。
Replication Controller，簡稱RC，是Kubernetes中核心概念之一，定義了一個期望的場景，即：聲明某種Pod的副本數量在任意時刻都符合某個預期值。
RC的定義包括以下幾個部分：
Pod預期的副本數量。
用于篩選目標Pod的Label Selector。
當Pod的副本數量小于預期數量時，用于創建新Pod的Pod模板。
下面以有3個Node的集群為例進行，說明Kubernetes如何通過RC來實現Pod副本數量自動控制的機制。
假如在我們的RC里定義redis-slave這個Pod需要保持2個副本，系統將可能在其中的兩個Node創建Pod，如下圖所示：
假如Node 2上的Pod意外終止，則根據RC定義的replicas數量2，Kubernetes將自動創建并啟動一個新的Pod，以保證整個集群中始終有兩個redis-slave運行。如下圖所示，Kubernetes可能選擇Node 3或者Node 1來創建一個新的Pod。
此外，在運行時，我們可以通過修改RC的副本數量，來實現Pod的動態縮放（Scaling），可通過執行kubectl scale rc redis-slave --replicas=3命令一鍵完成。執行結果示意如下圖所示：
注意：刪除RC并不會影響通過該RC創建好的Pod。 刪除所有Pod，可以設置replicas的值為0，然后更新該RC。另外，kubectl也提供了stop和delete命令來一次性刪除RC和RC控制的全部Pod。
最后，總結一下RC的特性和作用：
大多數情況下，通過自定義一個RC實現Pod的創建過程及副本數量的自動控制。
RC里包含完整的pod定義模板。
RC通過label selector機制實現對pod副本的自動控制。
通過改變RC里的Pod副本數量，實現對Pod的擴容和縮容功能。
通過改變RC里Pod模板中的鏡像版本，可以實現Pod的滾動升級功能。
Deployment是Kubernetes在1.2版本中引入的新概念，用于更好地解決Pod的編排問題。為此，Deployment在內部使用了Replica Set來實現，無論從Deployment的作用、YAML定義，還是從它的具體命令行操作來看，我們都可以把它看作是RC的一次升級。
Deployment相對于RC的一個最大升級是我們可以隨時知道當前Pod部署的進度。
典型使用場景：
創建Deployment對象來生成對應的Replica set并完成Pod副本的創建。
檢查Deployment的狀態來看部署動作是否完成（Pod副本數是否達到預期值）。
更新Deployment來創建新的Pod。
如果當前Deployment不穩定，則回滾到一個先前的Deployment版本。
暫停Deployment以便于一次性修改多個PodTemplateSpec的配置項，之后再恢復Deployment，進行新的發布。
擴展Deployment以應對高負載。
查看Deployment狀態，以此作為發布是否成功的指標。
在Kubernetes中，Pod的管理對象RC、Deployment、DaemonSet和Job都是面向無狀態的服務。但現實中有很多服務是有狀態的，特別是一些復雜的中間件集群，例如MySQL集群、MongoDB集群、Kafka集群、Zookeeper集群等，這些應用集群有以下一些共同點。
每個節點都有固定的身份ID，通過這個ID，集群中的成員可以相互發現并且通信。
集群的規模是比較固定的，集群規模不能隨意變動。
集群里的每個節點都是有狀態的，通常會持久化數據到永久存儲中。
如果磁盤損壞，則集群里的某個節點無法正常運行，集群功能受損。
如果用RC或Deployment控制Pod副本數的方式來實現上述有狀態的集群，則我們會發現第一點是無法滿足的，因為Pod的名字是隨機產生的，Pod的IP地址也是在運行期才確定且可能有變動的，我們事先無法為每個Pod確定唯一不變的ID，為了能夠在其他節點上恢復某個失敗的節點，這種集群中的Pod需要掛接某種共享存儲，為了解決這個問題，Kubernetes從v1.4版本開始引入了PetSet這個新的資源對象，并且在v1.5版本時更名為StatefulSet，StatefulSet從本質上來說，可以看作Deployment/RC的一個特殊變種，它有如下一些特性。
StatefulSet里的每個Pod都有穩定、唯一的網絡標識，可以用來發現集群內的其他成員。假設StatefulSet的名字叫kafka，那么第一個Pod叫kafak-0，第二個Pod叫kafak-1，以此類推。
StatefulSet控制的Pod副本的啟停順序是受控的，操作第n個Pod時，前n-1個Pod已經時運行且準備好的狀態。
StatefulSet里的Pod采用穩定的持久化存儲卷，通過PV/PVC來實現，刪除Pod時默認不會刪除與StatefulSet相關的存儲卷（為了保證數據的安全）。
StatefulSet除了要與PV卷捆綁使用以存儲Pod的狀態數據，還要與Headless Service配合使用，即在每個StatefulSet的定義中要聲明它屬于哪個Headless Service。Headless Service與普通Service的關鍵區別在于，它沒有Cluster IP，如果解析Headless Service的DNS域名，則返回的是該Service對應的全部Pod的Endpoint列表。StatefulSet在Headless Service的基礎上又為StatefulSet控制的每個Pod實例創建了一個DNS域名，這個域名的格式為：
$(podname).$(headless service name)
比如一個3節點的Kafka的StatefulSet集群，對應的Headless Service的名字為kafka，StatefulSet的名字為kafka，則StatefulSet里面的3個Pod的DNS名稱分別為kafka-0.kafka、kafka-1.kafka、kafka-3.kafka，這些DNS名稱可以直接在集群的配置文件中固定下來。
Service也是Kubernetes里的最核心的資源對象之一，Kubernetes里的每個Service其實就是我們經常提起的微服務架構中的一個“微服務”，上面我們所說的Pod、RC等資源對象其實都是為講解Kubernetes Service做鋪墊的。下圖顯示了Pod、RC與Service的邏輯關系。
從圖中我們看到，Kubernetes的Service定義了一個服務的訪問入口地址，前端的應用（Pod）通過這個入口地址訪問其背后的一組由Pod副本組成的集群實例，Service與其后端Pod副本集群之間則是通過Label Selector來實現“無縫對接”的。而RC的作用實際上是保證Service的服務能力和服務質量始終處于預期的標準。
Job（批處理任務）通過并行或串行啟動多個進程去處理一批工作，在處理完成后，整個批處理任務結束。從Kubernetes 1.2版本開始，支持批處理類型的應用，可以通過Kubernetes Job這種新的資源對象定義并啟動一個批處理任務Job。與RC、Deployment、ReplicaSet類似，Job也是用來控制一組Pod容器。
Job負責批量處理短暫的一次性任務 ，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束。
Volume（存儲卷）是Pod中能夠被多個容器訪問的共享目錄。Kubernetes的Volume概念、用途和目的與Docker的Volume比較類似，但兩者不能等價。首先，Kubernetes中的Volume定義在Pod上，然后被一個Pod里的多個容器掛載到具體的文件目錄下；其次，Kubernetes中的Volume中的數據也不會丟失。最后，Kubernetes支持多種類型的Volume，例如Gluster、Ceph等先進的分布式文件系統。
Namespace（命名空間）是Kubernetes系統中的另一個非常重要的概念，Namespace在很多情況下用于實現多租戶的資源隔離。Nameaspace通過將集群內部的資源對象“分配”到不同的Namespce中，形成邏輯上分組的不同項目、小組或用戶組，便于不同的分組在共享使用整個集群的資源的同時還能被分別管理。
Kubernetes集群默認會創建一個名為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，則用戶創建的Pod、RC、Service等都將創建到默認的default的Namespace中。
Annotation（注解）與Label類似，也使用key/value鍵值對的形式進行定義。不同的是Label具有嚴格的命名規則，它定義的是Kubernetes對象的元數據（Metadata），并且用于Label Selector。而Annotation則是用戶任意定義的“附加”信息，以便于外部工具進行查找，很多時候，Kubernetes的模塊自身會通過Annotation的方式標記資源對象的特殊信息。
通常來說，用Annotation來記錄的信息如下：
build信息、release信息、Docker鏡像信息等，例如時間戳、release id號、PR號、鏡像hash值、docker registry地址等。
日志庫、監控庫、分析庫等資源庫的地址信息。
程序調試工具信息，例如工具、版本號等。
團隊等聯系信息，例如電話號碼、負責人名稱、網址等。
為了能夠準確、深刻理解Kubernetes ConfigMap的功能和價值，可以先從Docker說起。我們都知道，Docker通過將程序、依賴庫、數據及配置文件等“打包固化”到一個不變的鏡像文件，以解決因應用部署差異的難題，但這同時帶來了另一個棘手的問題，即：配置文件中的參數在運行期間如何修改的問題。為了解決這個問題，Docker提供了以下兩種方式：
通過環境變量來傳遞參數。
通過Docker Volume將容器外的配置文件映射到容器內。
在大多數情況下，我們更傾向于后一種方式，應該大多數應用通常擁有多個參數，配置文件映射的方式簡潔。但這種方式也有明顯的缺陷：必須事先在宿主機上創建好配置文件，然后容器啟動時才能夠映射到容器里。
如果在分布式系統中，就會變得更加糟糕，多臺宿主機上創建相同的配置文件，并且要確保這些配置文件的一致性，是很難實現的。為此，Kubernetes引入了ConfigMap，巧妙的解決了這種問題。
把所有的配置項都當作key-value字符串，如：配置項host=192.168.1.1、user=root、password=123456用于表示連接FTP服務器的配置參數。這些配置項作為Map表中的一項，整個Map的數據被持久化存儲在Kubernetes的etcd中，并提供API方便Kubernetes相關組件或應用CRUD操作，這里用來保存配置參數的Map就是Kubernetes ConfigMap資源對象。
ConfigMap機制： 將存儲在etcd中的ConfigMap通過Volume映射方式變為目標Pod內的配置文件，不管目標Pod被調度到哪臺服務器上，都會自歐東完成映射。如果ConfigMap中的key-value數據被修改，則映射到Pod中的“配置文件”也會隨之自動更新。于是，ConfigMap就形成了分布式系統中最為簡單且對應用無侵入的配置中心。
上述的這些概念術語也是Kubernetes的核心組件，它們共同構成了Kubernetes的框架和計算模型。通過對它們進行靈活組合，用戶就可以快速、方便地對容器集群進行配置、創建和管理。除了本文介紹的概念外，Kubernetes中還有許多其他的概念，用于輔助配置資源對象，如：LimitRange、ResourceQuota等，更多概念術語可參照官方術語表：https://kubernetes.io/zh/docs/reference/glossary/?fundamental=true
到此，關于“Kubernetes的概念是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
