從零開始瞭解 kubernetes，還有誰不會？

kubernetes 已經成爲容器編排領域的王者，它是基於容器的集羣編排引擎，具有擴展集羣、滾動升級回滾、彈性伸縮、自動治癒、服務發現等多種特性能力。更多關注Kubernetes的介紹請參閱舊文：Kubernetes 前世此生（ 附學習導圖 ）

本文將帶着你們快速瞭解 kubernetes ，從零開始學習 kubernetes 技術。

kubernetes 架構

從宏觀上來看 kubernetes 的總體架構，包括 Master、Node 以及 Etcd。

Master 即主節點，負責控制整個 kubernetes 集羣。它包括 Api Server、Scheduler、Controller 等組成部分。它們都須要和 Etcd 進行交互以存儲數據。

• Api Server: 主要提供資源操做的統一入口，這樣就屏蔽了與 Etcd 的直接交互。功能包括安全、註冊與發現等。
• Scheduler: 負責按照必定的調度規則將 Pod 調度到 Node 上。
• Controller: 資源控制中心，確保資源處於預期的工做狀態。

Node 即工做節點，爲整個集羣提供計算力，是容器真正運行的地方，包括運行容器、kubelet、kube-proxy。

• kubelet: 主要工做包括管理容器的生命週期、結合 cAdvisor 進行監控、健康檢查以及按期上報節點狀態。
• kube-proxy: 主要利用 service 提供集羣內部的服務發現和負載均衡，同時監聽 service/endpoints 變化並刷新負載均衡。

從建立 deployment 開始

deployment 是用於編排 pod 的一種控制器資源，咱們會在後面作介紹。這裏以 deployment 爲例，來看看架構中的各組件在建立 deployment 資源的過程當中都幹了什麼。

• 首先是 kubectl 發起一個建立 deployment 的請求
• apiserver 接收到建立 deployment 請求，將相關資源寫入 etcd；以後全部組件與 apiserver/etcd 的交互都是相似的
• deployment controller list/watch 資源變化併發起建立 replicaSet 請求
• replicaSet controller list/watch 資源變化併發起建立 pod 請求
• scheduler 檢測到未綁定的 pod 資源，經過一系列匹配以及過濾選擇合適的 node 進行綁定
• kubelet 發現本身 node 上需建立新 pod，負責 pod 的建立及後續生命週期管理
• kube-proxy 負責初始化 service 相關的資源，包括服務發現、負載均衡等網絡規則

至此，通過 kubenetes 各組件的分工協調，完成了從建立一個 deployment 請求開始到具體各 pod 正常運行的全過程。

Pod

在 kubernetes 衆多的 api 資源中，pod 是最重要和基礎的，是最小的部署單元。

首先咱們要考慮的問題是，咱們爲何須要 pod？pod 能夠說是一種容器設計模式，它爲那些"超親密"關係的容器而設計，咱們能夠想象 servelet 容器部署 war 包、日誌收集等場景，這些容器之間每每須要共享網絡、共享存儲、共享配置，所以咱們有了 pod 這個概念。

對於 pod 來講，不一樣 container 之間經過 infra container 的方式統一識別外部網絡空間，而經過掛載同一份 volume 就天然能夠共享存儲了，好比它對應宿主機上的一個目錄。

更多關於Kubernetes pod 的詳細介紹請參閱舊文：Kubernetes 之 Pod 實現原理

容器編排

容器編排是 kubernetes 的看家本領了，因此咱們有必要了解一下。kubernetes 中有諸多編排相關的控制資源，例如編排無狀態應用的 deployment，編排有狀態應用的 statefulset，編排守護進程 daemonset 以及編排離線業務的 job/cronjob 等等。

咱們仍是以應用最普遍的 deployment 爲例。deployment、replicatset、pod 之間的關係是一種層層控制的關係。簡單來講，replicaset 控制 pod 的數量，而 deployment 控制 replicaset 的版本屬性。這種設計模式也爲兩種最基本的編排動做實現了基礎，即數量控制的水平擴縮容、版本屬性控制的更新/回滾。

水平擴縮容

水平擴縮容很是好理解，咱們只需修改 replicaset 控制的 pod 副本數量便可，好比從 2 改到 3，那麼就完成了水平擴容這個動做，反之即水平收縮。

更新/回滾

更新/回滾則體現了 replicaset 這個對象的存在必要性。例如咱們須要應用 3 個實例的版本從 v1 改到 v2，那麼 v1 版本 replicaset 控制的 pod 副本數會逐漸從 3 變到 0，而 v2 版本 replicaset 控制的 pod 數會註解從 0 變到 3，當 deployment 下只存在 v2 版本的 replicaset 時變完成了更新。回滾的動做與之相反。

滾動更新

能夠發現，在上述例子中，咱們更新應用，pod 老是一個一個升級，而且最小有 2 個 pod 處於可用狀態，最多有 4 個 pod 提供服務。這種"滾動更新"的好處是顯而易見的，一旦新的版本有了 bug，那麼剩下的 2 個 pod 仍然可以提供服務，同時方便快速回滾。

在實際應用中咱們能夠經過配置 RollingUpdateStrategy 來控制滾動更新策略，maxSurge 表示 deployment 控制器還能夠建立多少個新 Pod；而 maxUnavailable 指的是，deployment 控制器能夠刪除多少箇舊 Pod。

kubernetes 中的網絡

咱們瞭解了容器編排是怎麼完成的，那麼容器間的又是怎麼通訊的呢？

講到網絡通訊，kubernetes 首先得有"三通"基礎：

• node 到 pod 之間能夠通
• node 的 pod 之間能夠通
• 不一樣 node 之間的 pod 能夠通

簡單來講，不一樣 pod 之間經過 cni0/docker0 網橋實現了通訊，node 訪問 pod 也是經過 cni0/docker0 網橋通訊便可。而不一樣 node 之間的 pod 通訊有不少種實現方案，包括如今比較廣泛的 flannel 的 vxlan/hostgw 模式等。flannel 經過 etcd 獲知其餘 node 的網絡信息，並會爲本 node 建立路由表，最終使得不一樣 node 間能夠實現跨主機通訊。

微服務—service

在瞭解接下來的內容以前，咱們得先了解一個很重要的資源對象:service。

咱們爲何須要 service 呢？在微服務中，pod 能夠對應實例，那麼 service 對應的就是一個微服務。而在服務調用過程當中，service 的出現解決了兩個問題：

pod 的 ip 不是固定的，利用非固定 ip 進行網絡調用不現實 服務調用須要對不一樣 pod 進行負載均衡 service 經過 label 選擇器選取合適的 pod，構建出一個 endpoints，即 pod 負載均衡列表。實際運用中，通常咱們會爲同一個微服務的 pod 實例都打上相似app=xxx的標籤，同時爲該微服務建立一個標籤選擇器爲app=xxx的 service。

kubernetes 中的服務發現與網絡調用

在有了上述"三通"的網絡基礎後，咱們能夠開始微服務架構中的網絡調用在 kubernetes 中是怎麼實現的了。

這部份內容能夠參考：Kubernetes 之服務發現，比較細節的地方能夠參考上述文章，這裏作一個簡單的介紹。

服務間調用

首先是東西向的流量調用，即服務間調用。這部分主要包括兩種調用方式，即 clusterIp 模式以及 dns 模式。

clusterIp 是 service 的一種類型，在這種類型模式下，kube-proxy 經過 iptables/ipvs 爲 service 實現了一種 VIP(虛擬 ip)的形式。只須要訪問該 VIP，便可負載均衡地訪問到 service 背後的 pod。

上圖是 clusterIp 的一種實現方式，此外還包括 userSpace 代理模式(基本不用)，以及 ipvs 模式(性能更好)。

dns 模式很好理解，對 clusterIp 模式的 service 來講，它有一個 A 記錄是 service-name.namespace-name.svc.cluster.local，指向 clusterIp 地址。因此通常使用過程當中，咱們直接調用 service-name 便可。

服務外訪問

南北向的流量，即外部請求訪問 kubernetes 集羣，主要包括三種方式：nodePort、loadbalancer、ingress。

nodePort 一樣是 service 的一種類型，經過 iptables 賦予了調用宿主機上的特定 port 就能訪問到背後 service 的能力。

loadbalancer 則是另外一種 service 類型，經過公有云提供的負載均衡器實現。

咱們訪問 100 個服務可能須要建立 100 個 nodePort/loadbalancer。咱們但願經過一個統一的外部接入層訪問內部 kubernetes 集羣，這就是 ingress 的功能。ingress 提供了統一接入層，經過路由規則的不一樣匹配到後端不一樣的 service 上。ingress 能夠看作是"service 的 service"。ingress 在實現上每每結合 nodePort 以及 loadbalancer 完成功能。

到如今爲止，咱們簡單瞭解了 kubernetes 的相關概念，它大體是怎麼運做的，以及微服務是怎麼運行在 kubernetes 中的。因而當咱們聽到別人討論 kubernetes 時，咱們能夠知道他們在討論什麼。

做者：fredalxin 地址：https://fredal.xin/what-is-ku...