Kubernetes

本文內容僅為個人理解，如有偏頗，歡迎指正。

一、傳統的運維方式

在瞭解Kubernetes之前，我們有必要先簡單瞭解一下傳統的運維模式。在傳統的專案架構中(單體or微服務)，我們一般將專案打包為war或fatJar的方式進行部署。

在部署時，需要人工建立相應的伺服器及資源，並搭建專案執行的依賴環境，預估服務需要佔用的記憶體與CPU，同事還要考慮到高可用的部署環境，在不同配置的伺服器上部署相應的服務。當服務意外崩潰或者伺服器意外宕機時，需要人工處理。總結一下傳統部署的不足如下:

• 依賴伺服器環境，需要各伺服器資源統一。
• 無法充分利用伺服器等資源，使用率一般僅能達到70%。
• 無法或很難做到容災恢復。
• 需要人工進行服務擴容，修改服務配置。
• 服務資源散亂(域名，伺服器，負載，資料庫)，無法做集中管理。
• 時間消耗較多，增加運維成本。
• 需要藉助第三方工具進行資源監控，較為麻煩。
• 需要對開發、測試、生產環境進行區別管理。

要想解決以上的問題是相對比較麻煩的，特別是現在的專案多為微服務專案，少則幾十，多則上百，極大的增加了運維的難度和成本。

一、Kubernetes是什麼？

官方文件中描述為:v

Kubernetes一個用於容器叢集的自動化部署、擴容以及運維的開源平臺。通過Kubernetes,你可以快速有效地響應使用者需求;快速而有預期地部署你的應用;極速地擴充套件

你的應用;無縫對接新應用功能;節省資源，優化硬體資源的使用。為容器編排管理提供了完整的開源方案。

介紹一下其中提到的幾個詞:

• 容器
  
  • 我們現在常說的容器一般是指Docker容器，通過容器隔離的特性和宿主機進行解耦，使我們的服務不需要依賴於宿主機而執行，與宿主機互不影響，Docker容器十分輕量。而kubernetes則負責管理服務中所有的Docker容器，建立、執行、重啟與刪除容器。
• 快速響應
  
  • 個人理解為兩個方面。一、新增或者修改需求時，可以快速進行部署測試(CICD)；二、kubernetes可以根據不同條件進行動態擴縮容，舉個栗子，使用者訪問量突然由1000人上升到100000人時，現有的服務已經無法支撐，kubernetes會自動將使用者服務模組增加更多例項以保證當前的系統訪問量。
• 擴充套件
  
  • 在快速響應的特點中已經有所提及，這裡再補充一點: Kubernetes內部有完善的註冊發現機制，當某個服務的例項增加時，kubernetes會自動將其加入服務列表中，免除在傳統運維中需要人工維護服務列表的問題。
• 對接新應用
  
  • kubernetes是一個通用的容器編排框架，支援不同型別的語言，或者是語言無關的，新增加的應用都會以一個新的物件進行接入。
• 硬體資源
  
  • 這一點我覺得是kubernetess很基本但是非常重要的一個優點了，kubernetes在部署應用時會自動檢查各個伺服器的cpu與記憶體使用量，同時會根據服務申請的cpu與記憶體資源，將服務部署到最合適的伺服器。(其實這就是容器排程的核心功能了)

小知識: 因kubernetes名字過長，一般簡稱為k8s，因為k與s之間有8個字母，故而稱之。

二、Kubernetes解決了什麼問題？

下面以幾個case進行闡述，便於理解。

伺服器環境

kubernetes是使用Docker進行容器管理的，所以天生具備Docker的所有特性，只需要使用相應環境的Docker映象就可以執行服務，還需要關心宿主機是redhat、centos還是ubuntu，只要在宿主機上安裝Docker環境即可，相比傳統運維，減少了各種依賴環境的衝突，降低運維成本，也方便整體服務的遷移。

伺服器資源管理

對於kubernetes來說，是不關心有幾臺伺服器的，每個伺服器都是一個資源物件(Node)，kubernetes關心的是這個Node上有多少可用的cpu和記憶體。例如現在有兩臺伺服器

• server01 (4c16g), 已用(2c7.5G)
• server02 (4c16g), 已用(3c13G)

現在有一個服務ServiceA需要部署，ServiceA申明自己執行需要至少3G記憶體，這時kubernetes會根據排程策略將其部署到server01上，很明顯server01的資源是更加充足的。實際上kubernetes的排程策略要複雜的多，kubernetes會監控整體伺服器資源的狀態進行排程，而以前的運維方式只能由人工判斷資源使用。這裡只做簡單示例。

各個伺服器節點的狀態

總體叢集的資源狀態

服務容災恢復

說簡單點，就是服務掛了之後，能夠自動恢復。例如現在有一個ServiceA，執行在server01上，kubernetes會通過內部的kubelet元件監控ServiceA服務程序的狀態，一旦發現程序丟失(服務本身掛掉或者整個server01的伺服器掛掉)，就會嘗試換一臺資源充足的伺服器重新部署ServiceA並啟動，這樣就可以確保我們的服務一直是可用狀態，而不需要人工維護。

硬體資源利用

前面已經說過，kubernetes會根據節點(Node)的CPU與記憶體資源的可用量對服務進行部署排程，在排程策略中，可以配置不同的排程策略。例如現在有兩臺伺服器：

• server01 (4c16g), 已用(3c7.5G)
• server02 (4c16g), 已用(1c13G)

需要部署兩個服務

• serviceA-Java, 申請2G記憶體，0.5CPU單位
• ServiceB-Nginx, 申請200M記憶體,申請1CPU單位

這裡kubernetes如果講道理的話，會將ServiceA-Java部署到server01，將serviceB-Nginx部署到server02。這裡server01的記憶體和server02的CPU資源都得到了充分的利用。經過個人實踐，相比之前的部署方式，kubernetes節省了很多資源，資源利用是非常高效的。

服務資源建立

kubernetes建立服務是非常方便的，分為以下兩個方面：

• 自有服務
  
  • 在kubernetes中，進行專案服務部署是十分方便的，只需要構建好相應的映象，編寫一個yaml檔案即可完成服務的部署。

yaml示例

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  # 部署的模組名稱
  name: phantom-server-admin
  # 需要部署哪個環境
  namespace: develop
spec:
  # 部署的例項數量
  replicas: 1
  template: 
    metadata:
      labels:
        # 給這個部署打個標籤，方便之後進行選擇
        app: phantom-server-admin
    spec:
      containers:
      # 服務的名稱
      - name: phantom-server-admin
        # 服務的映象
        image: phantom-server-admin:v1
        ports:
        # 服務的埠
        - containerPort: 7006
        resources:
          limits:
            # 該服務需要的記憶體
            memory: 1000Mi

• 公共基礎服務
  
  • kubernetes開源社群中有一個工具叫helm, 類比的話就像是CentOS中的yum，我們可以通過這個工具進行簡單快速的安裝複雜的應用。阿里雲提供了視覺化的建立介面，建立十分方便，相比於傳統運維需要自己進行基礎軟體的安裝的優點是十分突出的，免去了繁瑣的安裝過程，服務的穩定性也有了一定的保障。talk is cheap, show you the below images,

應用商店

eureka示例

視覺化管理

在kubernetes中，所有的概念都抽象成不同的物件，而所有的物件都是可以通過圖形化介面進行管理和監控的，當然了，也同時提供了命令列客戶端kubectl進行管理。

物件建立

日誌監控

服務資源監控

各個節點的使用量監控

每個服務的使用量監控

資源整合管理

在之前的運維過程中，對各種資源的管理是十分複雜的，想做到統一管理各種資源更是難上加難，從前到後，我們需要對域名、負載均衡、服務例項、儲存服務進行逐個配置，配置的細節暫且不說，各個資源的關聯關係就錯綜複雜，非專業運維人員是無法進行統一規劃的。

而使用與雲服務整合的kubernetes之後，這些問題都迎刃而解。先看下圖做簡單說明

這是阿里kubernetes的路由配置介面，其中將負載均衡裝置與域名和對應的服務進行了繫結，可以很直觀的表述三者之間的關係，同時易於修改排錯。

版本管理與滾動升級

• 版本管理

  • kubernetes在部署服務時，會記錄部署服務的版本，我們可以很容易的進行上次版本或跨版本回退。

• 滾動升級

  • kubernetes在進行服務升級時，採用的預設策略是先將一部分新的服務啟動，確定服務正常後，停止一部分舊服務，進行新老服務的替換，之後再啟動一些新的服務，停止一部分舊服務，直到舊服務全部停止，即切換完成。滾動省級的過程中，極大的減少了服務切換的間隔時間。

其它

上面所說的是kubernetes的主體功能，kubernetes還有很多其他重要的特性解決了之前運維的痛點，例如DNS解析、自動負載、儲存宣告等等。

三、kubernetes特點

網路模型

kubernetes採用了三層網路模型，分為PodIP,ClusterIP,NodeIP。用簡單的話來說，kubernetes在內部使用自己的網路進行通訊，這樣做一個最直接的好處是我們不用再擔心埠衝突的問題。

舉個栗子: 我們在server01上部署兩個一樣的服務serviceA-1,serviceA-2,兩個服務的埠都是8080，這個時候有一個服務是無法啟動的，因為埠被佔用了，而在kubernetes中，兩個服務在不同的Docker容器中,每個Docker容器都有自己的IP,這時就不會出現端口占用的問題了。

為什麼要有三層網路有三個IP呢？其實每個IP的作用是不一樣的：

• NodeIP
  
  • NodeIP是最好理解的，就是每個伺服器的IP。例如server01的IP是192.168.1.2，有一個服務例項的IP申明型別為NodeIP，埠申明為30222,那麼我們就可以通過192.168.1.2:30222訪問到這個服務例項。
• PodIP
  
  • PodIP的作用可以簡單理解為每個服務自己teyoudeIP,就像上面說的可以解決埠衝突的問題，同時也是每個服務的唯一標識。PodIP是無法通過外網訪問的，只能在服務內部進行訪問。
• ClusterIP(可以按照下面訪問的進行理解，但實際有所區別)
  
  • 中文叫叢集IP，對叢集瞭解的同學應該很容易理解。叢集IP可以簡單理解為是對同一個服務的多個例項(每個例項有自己的PodIP)組成的叢集的入口IP，換句話說，是對多個例項的負載IP。舉個栗子：

有三個例項:

• serviceA-1 172.22.1.2
• serviceA-2 172.22.1.3
• serviceA-3 172.22.1.4

有一個ClusterIP 172.23.2.23指向了serviceA服務，那麼我們訪問172.23.2.23則會負載轉向到172.22.1.2、172.22.1.3、172.22.1.4中的其中一個服務

物件

在kubernetes中，萬物皆物件。路由(Ingress)、服務(Service)、部署(Deployment)、儲存(Storage/PV/PVC)、容器(Pod)、角色(Role)、賬戶(Accoutn)、配置(ConfigMap)等等。通過管理這些物件來管理整個kubernetes叢集。

注意：此處說的服務(Service),不同於上文提到的服務(開發的專案模組)

聲名式管理

kubernetes採用聲名式進行資源管理，也就是從結果來看問題。舉個栗子，現在需要部署十個ServiceA

面向過程: 部署ServiceA-01,再部署ServiceA02…..ServiceA-10，強調的是過程，用程式碼來表示的話就是while(serviceA.count < 10) {serviceA.count++}

面向結果(宣告式):不管是同時部署還是挨個部署，總之要部署十個ServiceA服務。用程式碼來表示的話就是kubernetes.addServiceA(10),不用管內部的細節怎麼處理，只要最終的結果。

四、Kubernetes常用相關概念

部署 - Deployment

類似於Docker中的映象Image，也就是容器(Pods)例項的模板，容器例項是根據Deploy創建出來的。在Deployment物件中會寫明容器的映象，容器的版本，容器要部署的數量等資訊。

容器組 - Pods

Pods是Kubernetes中的最小管理單元，Pods和Docker中的容器可以理解為包含關係，在Pods中可以包含有多個Docker容器，例如有ServiceA和ServiceB,ServiceA高度依賴ServiceB(需要共享主機的相同檔案),這時就可以將ServiceA與ServiceB放在同一個Pods中，當做一個整體來管理。如果分開部署當然也可以，不過會小號額外的資源或者產生其他不必要的麻煩。

服務 - Service

Service是一個物件，這個物件有自己的IP，也就是ClusterIP,可以理解為就是下層服務的負載均衡。

路由 - Ingress

無論是容器組還是Service，外網都是無法直接訪問的，Ingress就可以通過一個負載IP與Kubernetes叢集內部進行通訊，一般會和Service物件進行配合使用。

配置項 - ConfigMap

簡單理解為一個管理配置的物件，可以將專案的配置寫入到ConfgiMap中，專案中的配置使用相應的變數名就可以讀取相應的變數值。

還有很多其它概念，這是就不一一介紹了，可以參考Kubernetes中文社群

五、Kubernetes結構圖

Kubernetes由Master節點和Worker節點組成。master節點是Kubernetes的大腦，而woker節點則是kubernetes中實際執行服務的勞動者。

Master主要由ETCD/Controller Manager/Api Server/Schedular能成，

• ETCD
  
  • 主要負責儲存各個woker節點的狀態和其它相關資料，可以理解為kubernetes的資料庫。
• Controller Manager
  
  • 負責維護叢集的狀態，比如故障檢測、自動擴充套件、滾動更新等
• Scheduler
  
  • 負責資源的排程，按照預定的排程策略將Pod排程到相應的機器上

Worker主要由kubelet和kube-proxy組成，一般還會安裝kube-dns元件。

• kubelet
  
  • 負責維護容器的生命週期，同時也負責Volume（CVI）和網路（CNI）的管理；
• kube-proxy
  
  • 負責為Service提供cluster內部的服務發現和負載均衡；
• kube-dns
  
  • 負責為整個叢集提供DNS服務，通過Service名稱訪問相應的服務

六、總結

Kubernetes在容器編排可謂是做到了淋漓盡致，解決了之前的種種痛點，但是學習成本也相對較高，需要結合一定的實踐，踩一定的坑才能形成自己的理解。

Thanks !