Kubernetes 入門之Kubernetes 的基本概念和術語

Kubernetes是什麼？

   他是一個全新的基於容器技術分佈式架構領先方案；

   他也是一個開放的開發平臺；

   他也是一個完備的分佈式系統支撐平臺；

 

Kubernetes的基本慨念和術語

• Master

      Kubernetes 裏的Master 指的是集羣控制節點，每一個Kubernetes 集羣裏須要有一個 Master 節點負責整個集羣的管理和控制，基本上Kuberneter全部的控制命令都發給它，他來負責具體的執行過程，咱們後面所執行的全部命令基本上都是在Master節點上運行的。Masteer一般會佔用一個獨立的服務器（高可用部署建議用三臺服務器）；

     

Master節點上運行着一組關鍵進程

a). Kubernetes API Server（kube-apiserver）：提供了HTTP Rest 接口的關鍵進程，是Kubernetes裏全部資源增、刪、改、查等操做的統一入口，也是集羣控制的入口進程。

b). Kubernetes Controller Manager（kub-controller-manager）：Kubernetes 裏全部資源對象的自動化控制中心，能夠理解爲資源對象的「大總管」；

c). Kubernetes Scheduer（kub-scheduler）：負責資源調度（pod調度）的進程；

d). Masternetes 節點上還須要啓動一個etcd服務，由於Kubernetes 上全部的資源對象所有保存在etcd中的；

• Node

      除了Mater節點外，Kubernetes集羣中其餘機器的節點被稱爲Node節點，在較早的版本中也被稱爲Minion。與Master同樣，Node節點能夠是一臺物理機，也能夠是一臺虛擬機。Node節點纔是Kubernetes集羣中的工做負載節點，每一個Node節點都會被Master分配一些工做負載（Docker容器），當某個Node宕機時，其上的工做負載會被Master節點自動轉移到其餘節點上去的。

    

每一個Node節點上都都運行着一組關鍵進程

a）kubelet：負責Pod 對應的容器的建立、啓停等任務，同時與Master 節點密切協做，實現集羣管理的基本功能。

b）kube-proxy：實現Kubernetes Server 的通訊與負載均衡機制的重要組件。

c）Docker Engine（docker）：Docker 引擎，負責本機的容器建立和管理工做。

 

   Node節點能夠在運行期間動態的增長到Kubernetes集羣中，前提是這個節點上已經正確安裝、配置和啓動了上述關鍵進程，在默認的狀況下kubelet會向Master註冊本身，這也是Kubernetes推薦的Node 管理方式。一旦Node 被歸入集羣管理範圍，kubelet進程就會定時向Master節點彙報自身的狀況，例如操做系統、Docker版本、機器的CPU和內存狀況，以及當時有哪些Pod在運行等，這樣Master能夠獲知每一個Node 的資源使用狀況，並實現高效均衡的資源調度策略。而某個Node 超過指定時間不上報信息時，會被Master斷定爲」失聯「，Node的狀態被標記爲不可用（Not Ready），隨後Master會觸發」工做負載大轉移「的自動流程。

  

 咱們能夠經過執行如下命令查看集羣中有多少個Node：

# kubectl get nodes

而後經過kubectl describe node <node-name>查看某個Node 節點的詳細信息：

• Pod

 Pod的基本組成：

      每一個Pod都有一個特殊地被稱爲」根容器「的Pause的容器。Pause容器對應的鏡像屬於Kubernetes平臺的一部分，除了Pause容器，每一個Pod還包含一個或多個緊密相關的用戶業務容器。

經過kubectl get pods查看全部pod列表

 

爲何Pod會設計出一個全新的Pod概念而且對Pod有這樣特殊的組成結構？

緣由之一：在一組容器做爲一個單元的狀況下，咱們難以對「總體」簡單地的進行判斷及有效地進行運動。好比，一個容器死亡了，此時算是總體死亡？是N/M的死亡率？引入業務無關且不易死亡的Pause容器做爲Pod的根容器，以他的狀態表明整個容器組的狀態，就簡單、巧妙的解決了這個問題。

緣由之二：Pod裏的uoge業務容器共享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進程實例化成一組相關的Docke容器並存儲起來。在默認狀況下，當Pod裏的某個容器中止時，Kubernetes會自動檢測到這個問題而且從新啓動這個Pod（重啓Pod裏的全部容器），若是Pod所在的Node宕機，則會將這個Node節點上的全部Pod從新調度到其餘Node節點上。

Pod、容器和Node的關係以下所示：

 

• Label

       Label是Kubernetes裏的另一個核心概念。一個Label是一個key=value的鍵值對，其中key與value由用戶本身指定。Label能夠附加到各類資源對象上，例如Node、Pod、Service、RC等，一個資源對象能夠定義任意數量的label，同一個Label也能夠被添加到任意數量的資源對象上去，Label一般在資源對象定義時被肯定，也能夠在對象建立後動態的添加或者刪除。

        咱們能夠經過給指定的資源對象捆綁一個或多個不一樣的Label來實現多維度的資源分組管理功能，以便靈活、方便的進行資源分配、調度、配置、部署等管理工做。例如：部署不一樣的版本的應用到不一樣的環境中；或者監控和分析應用（日誌記錄、監控、告警）等。一些經常使用的Label標籤以下。

      版本標籤：」release「：」stable「，」release「：「canary」....

      環境標籤：」environment「：」dev「，」environment」：「qa」，「environment」：「producetion」

      架構標籤：「tier」：「frontend」，「tier」：「backend」，「tier」：「middleware」

      分區標籤：「partition」：「customerA」，「partition」：「customerB」....

      質量管控標籤：「track」：「daily」，「track」：「weekly」

     

        Label至關於咱們熟悉的「標籤」，給某個資源對象定義一個Label，就至關於給他打了一個標籤，隨後能夠經過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源對象，Kubernetes經過這種方式實現了相似SQL的簡單又通用的對象查詢機制。

       Label Selector 能夠類比爲SQL語句中的where查詢條件，例如，name=redis-slave這個Label Selector 做用於Pod時，能夠類比爲select * from pod where pod_name = 'redis-slave'這樣的語句。當前者有兩種不一樣的Label Selector 的表達式：基於等式的（Equality-based）和基於集合的（Set-based），前者採用「等式類」的表達式匹配標籤，下面是一些具體的例子。

      name = redis-server：匹配全部具備標籤 nameredis-server的資源對象。

      env != production:匹配全部不具備標籤 env=prouction 的資源對象。

然後者則使用集合操做的表達式匹配標籤，下面是一些具體的例子。

      name in （redis-master，redis-slave）：匹配全部具備標籤的nameredis-master或者nameredis-slave的資源對象。

      name not in （php-frontend） ：匹配全部不具備標籤namepho-frontend的資源對象。

能夠經過多個Label Selector 表達式的組合實現複雜的條件選擇，多個表達式之間用「，」進行分割，幾個條件之間是「and」的關係，即同時知足多個條件，好比下面的例子：

     name = redis-server，env != production

 

Label Selector 在Kubernetes 中的重要使用場景有如下幾處。

    a）kube-controller 進程經過資源對象RC上定義的Label Selector 來篩選要監控的Pod副本的數量，從而實現Pod副本的數量始終負荷預期設定的全自動流程控制。

   b） kueb-proxy 進程經過Service 的 Label Selector 來選擇對應的Pod，自動創建起每一個Service到對應Pod的請求轉發路由表，從而實現Servicce的智能負載均衡機制。

    c）經過對某些Node 定義特定的Label，而且在Pod定義文件中使用NodeSelector這種標籤調度策略，kube-scheduler進程能夠實現Pod定向調度的策略。

 

總結：使用Label 能夠給對象建立更多組標籤，Label 和 Label Selector 共同構成了Kubernetes 系統中最核心的應用模型，使得被管理者對象可以被精細地分組管理，同時實現了整個集羣的高可用性。

• Replication Controller

     Replication Controller （簡稱RC），RC是Kubernetes的核心概念之一，簡單地說，他實際上是定義了一個指望的場景，即聲明瞭某種Pod的副本的數量在任意時刻都符合某個預期值，全部RC的定義包括如下幾個部分：

    a）Pod期待的副本數（replicas）

    b）用於篩選目標Pod的Label Selector。

    c）當Pod的副本數量小於預期值時，用於建立新Pod的Pod 模板（template）。

   

   當咱們定義了一個RC並提交到Kubernetes集羣中之後，Master節點上的Controller Manager組件就會收到通知，按期巡檢系統當中的當前存活的目標Pod，並確保目標Pod實例數量恰好等於此RC的指望值，若是有過多的Pod副本在運行，系統就會停掉一些Pod，不然系統就會再手動建立一些Pod。能夠說，經過RC，Kubernetes實現了用戶應用集羣的高可用性，而且大大減小了系統管理員再傳統IT環境中須要手動完成的許多運維工做（如主機監控腳本、應用監控腳本、故障恢復腳本等）。

----經過RC，Kubernetes很容易就實現了這種高級實用的特性，被稱爲「滾動升級」，具體的操做方法之後在作分析。

因爲Replication Controller 與 Kubernetes代碼中的模塊Replication Controller同名，同時這個詞也沒法準確表達他的本意，因此在Kubernetes v1.2時，他就升級成了另一個概念-------Replica Set，官方解釋爲「下一代的RC」，它與RC當前存在的惟一區別是：Replica Set支持基於集合的Label Selector（Set-based selector），而RC只支持基於等式的Label Selector（equality-based selector），這使得Replica Set的功能更強。

    kubectl命令行使用與RC的絕大部分命令一樣也適用於Replica Set。此外，當前咱們不多單獨使用Replica Set，它主要是被Deployment這個更高層級的資源對象所使用，從而造成一套完整的Pod建立、刪除、更新的編排機制。當咱們使用Deplyment時，無須關心他說如何建立和維護Replica Set的，這一切都是自動發生的。

    Replica Set和Deployment這兩個重要的資源對象逐步替換看以前的RC的做用，時Kubernetes v1.3裏的Pod自動擴容（伸縮）這個告警功能實現的基礎，也將繼續在Kubernetes將來的版本中發揮重要做用。

    總結RC(Replica Set)的一些特性和做用。

     a）在大多數狀況下，咱們經過定義一個RC實現Pod的傳教過程及副本數量的自動過程。

     b）RC裏包含完整的Pod定義模板。

     c）RC經過Label Selector機制實現對Pod副本的自動控制。

     d）經過改變RC裏的Pod的副本數量，能夠實現Pod的擴容與縮容功能。

     e）經過改變RC裏Pod模板的鏡像版本，能夠實現Pod的滾動升級功能。

 

• Deployment

     Deployment 是Kubernetes v1.2引入的概念，引入的目的是欸藍更好的解決Pod的編排問題。爲此，Deployment 在內部使用了 Replica Set 來實現目的的，不管從Deployment 的做用與目的、它的YAML定義，仍是從它的具體命令行操做來看，咱們均可以把它看做RC的一次升級，二者的類似度超過90%。

       Deployment相對於RC的最大一個升級時咱們能夠隨時知道當前Pof「部署」的進度。實際上因爲一個Po的建立、調度、綁定節點及在目標Node上啓動對應的的容器這一完整的過程須要必定的時間，因此咱們期待系統啓動N個Pod副本的目標狀態，其實是一個連續變化的「部署過程」致使的最終狀態。

      Deployment典型使用場景有如下幾個：

     a）建立一個Deployment對象來生成對應的Replica Set 並完成Pod副本的建立過程。

     b）檢查Deployment的狀態來看部署動做是否完成（Pod副本的數量是達到預期的值）。

     c）更新Deployment以建立新的Pod（好比鏡像升級）。

     d）若是當前Deployment不穩定，則回滾到一個早先的Deployment版本。

     e）暫停Deployment 以便一次性修改多個PodTemplateSpec 的配置項，以後再恢復Deployment，進行新的發佈。

     f）擴展Deployment以應對高負載。

     g）查看 Deployment 的狀態，以此做爲發佈是否成功的標誌。

     h）清理再也不須要的舊的 ReplicaSets。

 

   運行下面命令能夠查看 Deployment 的信息

   kubectl  get deployments

   

Pod 的管理對象，除了RC和Deployment，還包括ReplicaSet、DaemonSet、StatefulSet、Job等，分別用於不一樣的業務場景，具體之後再分析。

• Horizontal Pod Autoscaler

          以往咱們經過手動執行kubectl scale 命令，咱們能夠實現Pod擴容和縮容。若是僅僅至此爲止，顯然不符合谷歌對Kubernetes 的定位目標----自動化、智能化。再谷歌看來，分佈式系統要可以根據當前負載的變化狀況觸發水平擴展或縮容的行爲，由於這一過程多是頻繁發生的、不可預料的，因此手動控制的方式是不現實的。

• StatefulSet

        在Kubernetes 中，Pod 的管理對象RC、Deployment、DaemonSet和job都是面向無狀態的服務。可是現實中有不少服務是由狀態的，特別是一些負載的中間件集羣，例如MYsQL集羣、MongoDB集羣、Akka集羣、Zookeeper集羣等，這些應用集羣都有如下一些特色。   

     a) 每一個節點都有固定的省份ID，經過這個ID，集羣中的成員能夠相互發現並通信。

     b) 集羣的規模是比較固定的，集羣規模不能隨意的變更。

     c)  集羣裏的每一個節點都是有狀態的，一般會持久化數據到永久存儲中。

     d)  若是磁盤損壞，則集羣裏的某個節點沒法正常運行，集羣功能受損。

若是用RC/Deployment控制Pod副本數的方式來實現上述有狀態的集羣，則咱們會發現第一點是沒法知足的，由於Pod的名字是隨機產生的，Pod的ID地址也是在運行期才肯定是否有變更的，咱們事先沒法爲每一個Pod肯定一個惟一不便的ID，另外，爲了可以在其餘節點上恢復這個失敗的節點，這中集羣中的Pod須要掛接某種共享存儲，爲了解決這個問題，Kubernetes v1.4版本開始引入PetSet 這個新的資源對象，而且在 v1.5版本時改名爲StatefulSet，StatefulSet從本質上來講，能夠看着是Deployment/RC的一個特殊變種，它有以下的一些特性：

      a）StatefulSet 裏的每個Pod 都有穩定、惟一的網絡標識，能夠用來發現集羣內的其餘成員。假設StatefulSet的名字叫kafka，那麼第一個Pod叫kafka-0，第二個叫kafka-1，以此類推。

      b）StatefulSet 控制的Pod副本的啓停順序是受控的，操做第n個Pod時，前n-1 個Pod已是運行且準備好的狀態。

      c）StatefulSet 裏的Pod 採用穩定的持久化存儲卷，經過PV/PVC來實現，刪除Pod 時默認不會刪除與StatefulSet相關的存儲卷（爲了保證數據的安全）。

 

• Service

         Kubernetes 裏的每一個Servcice 其實就是咱們常常提到的微服務架構中的一個「微服務」，以前咱們所說的Pod、RC等資源對象其實都是爲這節所說的「服務」-----Kubernetes Service做「嫁衣」的。

後面會單獨針對Service作講解，這裏首先知道有這麼一個對象存在就行。

• Volume（存儲卷）

          Volume 是Pod 中可以被多個容器訪問的共享目錄。Kubernetes 的 Volume 概念、用途和目的與Docker的Volume比較類似，但二者不能等價。首先，Kubernetes中的Volume定義在Pod上，而後被一個Pod裏的多個容器掛載到具體的文件目錄下；其次，Kubernetes中的Volume與Pod的生命週期相同，可是與容器的生命週期不相關，當容器終止或重啓時，Volume中的數據也不會丟失。最後，Kubernetes支持多種類型的Voume，例如 ClusterFS、Geph等先進的分佈式文件系統。

 

         Kuberneter 提供了很是豐富的Volume 類型：

               1.emptyDir

               2.hosyPath

               3.gcePersistentDisk

               4.awsElasticBlockStore

               5.NFS

 

• Persistent Volume

           前面咱們說的Volume是定義在Pod上的，屬於「計算資源」的一部分，而實際上。「網絡存儲」是相對獨立於「計算資源」而存在的一種實體資源。好比在使用虛擬機的狀況下，咱們一般會先定義一個網絡存儲，而後從中劃出一個「網盤」並接到虛擬機上。Persistent Volume （簡稱 PV）和與之相關的 Persistent Volume Claim （簡稱 PVC）也起到了相似的做用。

    PV能夠理解成是 Kubernetes 集羣中的某個網絡存儲中對應的一塊存儲，他與 Volume 很相似，但又如下區別：

 a）PV只能是網絡存儲，不屬於任何 Node，但能夠在每一個 Node 上訪問。

 b）PV 並非定義在 Pod 上的，而是獨立於 Pod 以外定義的。

 c）PV 目前支持的類型有：gcePersistentDisk、awsElasticBlockStore、AzureFile、AzureDisk、FC(Fibre Channel)、Flocker、NFS、iSCSI....等等，這裏就不一一例舉了。

 

    PV 是有狀態的對象，它有如下幾種狀態：

     a）Available：空閒狀態。

     b）Bound：已經綁定到某個 PVC 上。

     c）Released：對應的PVC 已經刪除，但資源還沒被集羣回收。

     d）Failed：PV 自動回收失敗。

•  Namespace（命名空間）

        Namespace（命名空間）是Kubernetes 系統中一個很是重要的概念，Namespace在不少狀況下用於實現多租戶的資源隔離。Namespace 經過將集羣內部的資源對象「分配」到不一樣的Namespace 中，造成邏輯上分組的不一樣項目、小組或用戶組，便於不一樣的分組在共享使用整個集羣的資源的同時還能被分別管理。

       Kubernetes 集羣在啓動後，會建立一個名爲「default」的Namespace，經過 kubectl能夠查到：

      kubectl get namespace：

• Annotation

      Annotation於 Label 相似，也使用key/value 鍵值對的形式進行定義。不一樣的是Label 具備嚴格的命名規範，它的定義是 Kubernetes 對象的元數據（Metadata），而且用於 Label Selector。而 Annotation 則是任意定義的「附加」信息，以便外部工具進行查找，不少時候 Kubernetes 的模塊自身會經過 Annotation 的方式標記資源對象的一些特殊信息。一般來講，用Annotation 來記錄的信息以下：

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

    b）日誌庫、監控庫、分析庫等資源庫的地址信息。

    c）程序調式工具信息，例如工具名稱、把本號等。

    d）團隊的聯繫信息，例如電話號碼、負責人名稱、網址等。

 

小結

     上述這些組件是Kubernetes 系統的核心組件，他們共同組成了 Kubernetes 系統的框架和計算模型。除了上述所介紹的核心組件，在Kubernetes 中還有許多輔助配置的資源對象，例如LimitRange、ResourceQuota。另外，一些系統內部使用的對象 Binging、Event等參考Kubernetes的API文檔。