kubernetes 已經(jīng)成為容器編排領(lǐng)域的王者,，它是基于容器的集群編排引擎，具備擴(kuò)展集群,、滾動(dòng)升級(jí)回滾,、彈性伸縮、自動(dòng)治愈,、服務(wù)發(fā)現(xiàn)等多種特性能力,。

本文將帶著大家快速了解 kubernetes ，了解我們談?wù)?kubernetes 都是在談?wù)撌裁础?/span>

kubernetes 架構(gòu)

從宏觀上來看 kubernetes 的整體架構(gòu),，包括 Master,、Node 以及 Etcd。

Master 即主節(jié)點(diǎn),，負(fù)責(zé)控制整個(gè) kubernetes 集群,。它包括 Api Server、Scheduler,、Controller 等組成部分,。它們都需要和 Etcd 進(jìn)行交互以存儲(chǔ)數(shù)據(jù),。

• Api Server: 主要提供資源操作的統(tǒng)一入口，這樣就屏蔽了與 Etcd 的直接交互,。功能包括安全,、注冊(cè)與發(fā)現(xiàn)等。
• Scheduler: 負(fù)責(zé)按照一定的調(diào)度規(guī)則將 Pod 調(diào)度到 Node 上,。
• Controller: 資源控制中心,，確保資源處于預(yù)期的工作狀態(tài)。

Node 即工作節(jié)點(diǎn),，為整個(gè)集群提供計(jì)算力,，是容器真正運(yùn)行的地方，包括運(yùn)行容器,、kubelet,、kube-proxy。

• kubelet: 主要工作包括管理容器的生命周期,、結(jié)合 cAdvisor 進(jìn)行監(jiān)控,、健康檢查以及定期上報(bào)節(jié)點(diǎn)狀態(tài)。
• kube-proxy: 主要利用 service 提供集群內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡,，同時(shí)監(jiān)聽 service/endpoints 變化并刷新負(fù)載均衡,。

從創(chuàng)建 deployment 開始

deployment 是用于編排 pod 的一種控制器資源，我們會(huì)在后面做介紹,。這里以 deployment 為例,，來看看架構(gòu)中的各組件在創(chuàng)建 deployment 資源的過程中都干了什么。

1. 首先是 kubectl 發(fā)起一個(gè)創(chuàng)建 deployment 的請(qǐng)求
2. apiserver 接收到創(chuàng)建 deployment 請(qǐng)求,，將相關(guān)資源寫入 etcd,；之后所有組件與 apiserver/etcd 的交互都是類似的
3. deployment controller list/watch 資源變化并發(fā)起創(chuàng)建 replicaSet 請(qǐng)求
4. replicaSet controller list/watch 資源變化并發(fā)起創(chuàng)建 pod 請(qǐng)求
5. scheduler 檢測到未綁定的 pod 資源，通過一系列匹配以及過濾選擇合適的 node 進(jìn)行綁定
6. kubelet 發(fā)現(xiàn)自己 node 上需創(chuàng)建新 pod,，負(fù)責(zé) pod 的創(chuàng)建及后續(xù)生命周期管理
7. kube-proxy 負(fù)責(zé)初始化 service 相關(guān)的資源,，包括服務(wù)發(fā)現(xiàn)、負(fù)載均衡等網(wǎng)絡(luò)規(guī)則

至此,，經(jīng)過 kubenetes 各組件的分工協(xié)調(diào)，完成了從創(chuàng)建一個(gè) deployment 請(qǐng)求開始到具體各 pod 正常運(yùn)行的全過程,。

Pod

在 kubernetes 眾多的 api 資源中,，pod 是最重要和基礎(chǔ)的，是最小的部署單元,。

首先我們要考慮的問題是,，我們?yōu)槭裁葱枰?pod？pod 可以說是一種容器設(shè)計(jì)模式,，它為那些'超親密'關(guān)系的容器而設(shè)計(jì),，我們可以想象 servelet 容器部署 war 包,、日志收集等場景，這些容器之間往往需要共享網(wǎng)絡(luò),、共享存儲(chǔ),、共享配置，因此我們有了 pod 這個(gè)概念,。

對(duì)于 pod 來說,，不同 container 之間通過 infra container 的方式統(tǒng)一識(shí)別外部網(wǎng)絡(luò)空間，而通過掛載同一份 volume 就自然可以共享存儲(chǔ)了,，比如它對(duì)應(yīng)宿主機(jī)上的一個(gè)目錄,。

容器編排

容器編排是 kubernetes 的看家本領(lǐng)了，所以我們有必要了解一下,。kubernetes 中有諸多編排相關(guān)的控制資源,，例如編排無狀態(tài)應(yīng)用的 deployment，編排有狀態(tài)應(yīng)用的 statefulset,，編排守護(hù)進(jìn)程 daemonset 以及編排離線業(yè)務(wù)的 job/cronjob 等等,。

我們還是以應(yīng)用最廣泛的 deployment 為例。deployment,、replicatset,、pod 之間的關(guān)系是一種層層控制的關(guān)系。簡單來說,，replicaset 控制 pod 的數(shù)量,，而 deployment 控制 replicaset 的版本屬性。這種設(shè)計(jì)模式也為兩種最基本的編排動(dòng)作實(shí)現(xiàn)了基礎(chǔ),，即數(shù)量控制的水平擴(kuò)縮容,、版本屬性控制的更新/回滾。

水平擴(kuò)縮容

水平擴(kuò)縮容非常好理解,，我們只需修改 replicaset 控制的 pod 副本數(shù)量即可,，比如從 2 改到 3，那么就完成了水平擴(kuò)容這個(gè)動(dòng)作,，反之即水平收縮,。

更新/回滾

更新/回滾則體現(xiàn)了 replicaset 這個(gè)對(duì)象的存在必要性。例如我們需要應(yīng)用 3 個(gè)實(shí)例的版本從 v1 改到 v2,，那么 v1 版本 replicaset 控制的 pod 副本數(shù)會(huì)逐漸從 3 變到 0,，而 v2 版本 replicaset 控制的 pod 數(shù)會(huì)注解從 0 變到 3，當(dāng) deployment 下只存在 v2 版本的 replicaset 時(shí)便完成了更新,?；貪L的動(dòng)作與之相反。

滾動(dòng)更新

可以發(fā)現(xiàn),，在上述例子中,，我們更新應(yīng)用,，pod 總是一個(gè)一個(gè)升級(jí)，并且最小有 2 個(gè) pod 處于可用狀態(tài),，最多有 4 個(gè) pod 提供服務(wù),。這種'滾動(dòng)更新'的好處是顯而易見的，一旦新的版本有了 bug,，那么剩下的 2 個(gè) pod 仍然能夠提供服務(wù),，同時(shí)方便快速回滾。

在實(shí)際應(yīng)用中我們可以通過配置 RollingUpdateStrategy 來控制滾動(dòng)更新策略,，maxSurge 表示 deployment 控制器還可以創(chuàng)建多少個(gè)新 Pod,；而 maxUnavailable 指的是，deployment 控制器可以刪除多少個(gè)舊 Pod,。

kubernetes 中的網(wǎng)絡(luò)

我們了解了容器編排是怎么完成的,，那么容器間的又是怎么通信的呢？

講到網(wǎng)絡(luò)通信,，kubernetes 首先得有'三通'基礎(chǔ)：

1. node 到 pod 之間可以通
2. node 的 pod 之間可以通
3. 不同 node 之間的 pod 可以通

簡單來說,，不同 pod 之間通過 cni0/docker0 網(wǎng)橋?qū)崿F(xiàn)了通信，node 訪問 pod 也是通過 cni0/docker0 網(wǎng)橋通信即可,。而不同 node 之間的 pod 通信有很多種實(shí)現(xiàn)方案,，包括現(xiàn)在比較普遍的 flannel 的 vxlan/hostgw 模式等。flannel 通過 etcd 獲知其他 node 的網(wǎng)絡(luò)信息,，并會(huì)為本 node 創(chuàng)建路由表,，最終使得不同 node 間可以實(shí)現(xiàn)跨主機(jī)通信。

微服務(wù)—service

在了解接下來的內(nèi)容之前,，我們得先了解一個(gè)很重要的資源對(duì)象:service,。

我們?yōu)槭裁葱枰?service 呢？在微服務(wù)中,，pod 可以對(duì)應(yīng)實(shí)例,，那么 service 對(duì)應(yīng)的就是一個(gè)微服務(wù)。而在服務(wù)調(diào)用過程中,，service 的出現(xiàn)解決了兩個(gè)問題：

1. pod 的 ip 不是固定的,，利用非固定 ip 進(jìn)行網(wǎng)絡(luò)調(diào)用不現(xiàn)實(shí)
2. 服務(wù)調(diào)用需要對(duì)不同 pod 進(jìn)行負(fù)載均衡

service 通過 label 選擇器選取合適的 pod，構(gòu)建出一個(gè) endpoints,，即 pod 負(fù)載均衡列表,。實(shí)際運(yùn)用中，一般我們會(huì)為同一個(gè)微服務(wù)的 pod 實(shí)例都打上類似app=xxx的標(biāo)簽,，同時(shí)為該微服務(wù)創(chuàng)建一個(gè)標(biāo)簽選擇器為app=xxx的 service。

kubernetes 中的服務(wù)發(fā)現(xiàn)與網(wǎng)絡(luò)調(diào)用

在有了上述'三通'的網(wǎng)絡(luò)基礎(chǔ)后,，我們可以開始微服務(wù)架構(gòu)中的網(wǎng)絡(luò)調(diào)用在 kubernetes 中是怎么實(shí)現(xiàn)的了,。

這部分內(nèi)容其實(shí)在說說 Kubernetes 是怎么實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)的已經(jīng)講得比較清楚了,，比較細(xì)節(jié)的地方可以參考上述文章，這里做一個(gè)簡單的介紹,。

服務(wù)間調(diào)用

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

clusterIp 是 service 的一種類型,，在這種類型模式下,，kube-proxy 通過 iptables/ipvs 為 service 實(shí)現(xiàn)了一種 VIP(虛擬 ip)的形式,。只需要訪問該 VIP，即可負(fù)載均衡地訪問到 service 背后的 pod,。

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

dns 模式很好理解,，對(duì) clusterIp 模式的 service 來說，它有一個(gè) A 記錄是
service-name.namespace-name.svc.cluster.local,，指向 clusterIp 地址,。所以一般使用過程中，我們直接調(diào)用 service-name 即可,。

服務(wù)外訪問

南北向的流量,，即外部請(qǐng)求訪問 kubernetes 集群，主要包括三種方式：nodePort,、loadbalancer,、ingress。

nodePort 同樣是 service 的一種類型,，通過 iptables 賦予了調(diào)用宿主機(jī)上的特定 port 就能訪問到背后 service 的能力,。

loadbalancer 則是另一種 service 類型，通過公有云提供的負(fù)載均衡器實(shí)現(xiàn),。

我們?cè)L問 100 個(gè)服務(wù)可能需要?jiǎng)?chuàng)建 100 個(gè) nodePort/loadbalancer,。我們希望通過一個(gè)統(tǒng)一的外部接入層訪問內(nèi)部 kubernetes 集群，這就是 ingress 的功能,。ingress 提供了統(tǒng)一接入層,，通過路由規(guī)則的不同匹配到后端不同的 service 上。ingress 可以看做是'service 的 service',。ingress 在實(shí)現(xiàn)上往往結(jié)合 nodePort 以及 loadbalancer 完成功能,。

到現(xiàn)在為止，我們簡單了解了 kubernetes 的相關(guān)概念，它大致是怎么運(yùn)作的,，以及微服務(wù)是怎么運(yùn)行在 kubernetes 中的,。于是當(dāng)我們聽到別人討論 kubernetes 時(shí)，我們可以知道他們?cè)谟懻撌裁础?/span>