Kubernetes 已經(jīng)成為容器編排領(lǐng)域的王者条摸，它是基于容器的集群編排引擎欠窒，具備擴展集群覆旭、滾動升級回滾、彈性伸縮岖妄、自動治愈型将、服務(wù)發(fā)現(xiàn)等多種特性能力。

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

Kubernetes 架構(gòu)

image.png

從宏觀上來看 Kubernetes 的整體架構(gòu)七兜，包括 Master、Node 以及 Etcd福扬。

Master 即主節(jié)點惊搏，負責控制整個 Kubernetes 集群，它包括 API Server忧换、Scheduler、Controller 等組成部分向拆，它們都需要和 Etcd 進行交互以存儲數(shù)據(jù)：

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

Node 即工作節(jié)點，為整個集群提供計算力晴圾，是容器真正運行的地方颂砸，包括運行容器、kubelet、kube-proxy：

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

從創(chuàng)建 Deployment 開始

image.png

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

步驟如下：

• 首先是 kubectl 發(fā)起一個創(chuàng)建 deployment 的請求腌且。
• apiserver 接收到創(chuàng)建 deployment 請求梗肝，將相關(guān)資源寫入 etcd；之后所有組件與 apiserver/etcd 的交互都是類似的切蟋。
• deployment controller list/watch 資源變化并發(fā)起創(chuàng)建 replicaSet 請求
• replicaSet controller list/watch 資源變化并發(fā)起創(chuàng)建 pod 請求统捶。
• scheduler 檢測到未綁定的 pod 資源，通過一系列匹配以及過濾選擇合適的 node 進行綁定柄粹。
• kubelet 發(fā)現(xiàn)自己 node 上需創(chuàng)建新 pod喘鸟，負責 pod 的創(chuàng)建及后續(xù)生命周期管理。
• kube-proxy 負責初始化 service 相關(guān)的資源驻右，包括服務(wù)發(fā)現(xiàn)什黑、負載均衡等網(wǎng)絡(luò)規(guī)則。

至此堪夭，經(jīng)過 Kubenetes 各組件的分工協(xié)調(diào)愕把，完成了從創(chuàng)建一個 Deployment 請求開始到具體各 Pod 正常運行的全過程。

Pod

在 Kubernetes 眾多的 API 資源中森爽，Pod 是最重要和基礎(chǔ)的恨豁，是最小的部署單元。

首先我們要考慮的問題是爬迟，我們?yōu)槭裁葱枰?Pod橘蜜？Pod 可以說是一種容器設(shè)計模式，它為那些”超親密”關(guān)系的容器而設(shè)計付呕，我們可以想象 Servelet 容器部署 War 包计福、日志收集等場景。

這些容器之間往往需要共享網(wǎng)絡(luò)徽职、共享存儲象颖、共享配置，因此我們有了 Pod 這個概念姆钉。

image.png

對于 Pod 來說说订，不同 Container 之間通過 Infra Container 的方式統(tǒng)一識別外部網(wǎng)絡(luò)空間抄瓦，而通過掛載同一份 Volume 就自然可以共享存儲了，比如它對應(yīng)宿主機上的一個目錄克蚂。

容器編排

容器編排是 Kubernetes 的看家本領(lǐng)了闺鲸，所以我們有必要了解一下。

Kubernetes 中有諸多編排相關(guān)的控制資源埃叭，例如編排無狀態(tài)應(yīng)用的 Deployment摸恍，編排有狀態(tài)應(yīng)用的 Statefulset，編排守護進程 Daemonset 以及編排離線業(yè)務(wù)的 job/cronjob 等等赤屋。

我們還是以應(yīng)用最廣泛的 Deployment 為例立镶。Deployment、Replicatset类早、Pod 之間的關(guān)系是一種層層控制的關(guān)系媚媒。

簡單來說，Replicaset 控制 Pod 的數(shù)量涩僻，而 Deployment 控制 Replicaset 的版本屬性缭召。

這種設(shè)計模式也為兩種最基本的編排動作實現(xiàn)了基礎(chǔ)，即數(shù)量控制的水平擴縮容逆日、版本屬性控制的更新/回滾嵌巷。

水平擴縮容

image.png

水平擴縮容非常好理解，我們只需修改 Replicaset 控制的 Pod 副本數(shù)量即可室抽，比如從 2 改到 3搪哪，那么就完成了水平擴容這個動作，反之即水平收縮坪圾。

更新/回滾

image.png

更新/回滾則體現(xiàn)了 Replicaset 這個對象的存在必要性晓折。例如我們需要應(yīng)用 3 個實例的版本從 v1 改到 v2。

那么 v1 版本 Replicaset 控制的 Pod 副本數(shù)會逐漸從 3 變到 0兽泄，而 v2 版本 Replicaset 控制的 Pod 數(shù)會注解從 0 變到 3漓概，當 Deployment 下只存在 v2 版本的 Replicaset 時變完成了更新〔∩遥回滾的動作與之相反垛耳。

滾動更新

可以發(fā)現(xiàn)，在上述例子中飘千，我們更新應(yīng)用，Pod 總是一個一個升級栈雳，并且最小有 2 個 Pod 處于可用狀態(tài)护奈，最多有 4 個 Pod 提供服務(wù)。

這種”滾動更新”的好處是顯而易見的哥纫，一旦新的版本有了 Bug霉旗，那么剩下的 2 個 Pod 仍然能夠提供服務(wù)，同時方便快速回滾。

在實際應(yīng)用中我們可以通過配置 RollingUpdateStrategy 來控制滾動更新策略厌秒。

maxSurge 表示 Deployment 控制器還可以創(chuàng)建多少個新 Pod读拆；而 maxUnavailable 指的是，Deployment 控制器可以刪除多少個舊 Pod鸵闪。

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

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

image.png

講到網(wǎng)絡(luò)通信蚌讼，Kubernetes 首先得有“三通”基礎(chǔ)：

• Node 到 Pod 之間可以通
• Node 的 Pod 之間可以通
• 不同 Node 之間的 Pod 可以通

簡單來說辟灰，不同 Pod 之間通過 cni0/docker0 網(wǎng)橋?qū)崿F(xiàn)了通信，Node 訪問 Pod 也是通過 cni0/docker0 網(wǎng)橋通信即可篡石。

而不同 Node 之間的 Pod 通信有很多種實現(xiàn)方案芥喇，包括現(xiàn)在比較普遍的 Flannel 的 vxlan/hostgw 模式等。

Flannel 通過 Etcd 獲知其他 Node 的網(wǎng)絡(luò)信息凰萨，并會為本 Node 創(chuàng)建路由表继控，最終使得不同 Node 間可以實現(xiàn)跨主機通信。

微服務(wù)—Service

在了解接下來的內(nèi)容之前胖眷，我們得先了解一個很重要的資源對象：Service武通。

我們?yōu)槭裁葱枰?Service 呢？在微服務(wù)中瘦材，Pod 可以對應(yīng)實例厅须，那么 Service 對應(yīng)的就是一個微服務(wù)。

而在服務(wù)調(diào)用過程中食棕，service 的出現(xiàn)解決了兩個問題：

• Pod 的 IP 不是固定的朗和，利用非固定 IP 進行網(wǎng)絡(luò)調(diào)用不現(xiàn)實
• 服務(wù)調(diào)用需要對不同 Pod 進行負載均衡

Service 通過 Label 選擇器選取合適的 Pod，構(gòu)建出一個 Endpoints簿晓，即 Pod 負載均衡列表眶拉。

實際運用中，一般我們會為同一個微服務(wù)的 Pod 實例都打上類似 app=xxx 的標簽憔儿，同時為該微服務(wù)創(chuàng)建一個標簽選擇器為 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 中是怎么實現(xiàn)的了谒臼。

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

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

首先是東西向的流量調(diào)用拾氓，即服務(wù)間調(diào)用。這部分主要包括兩種調(diào)用方式底哥，即 ClusterIp 模式以及 DNS 模式咙鞍。

ClusterIp 是 Service 的一種類型房官，在這種類型模式下，kube-proxy 通過 iptables/ipvs 為 Service 實現(xiàn)了一種 VIP（虛擬 IP）的形式续滋。只需要訪問該 VIP翰守，即可負載均衡地訪問到 Service 背后的 Pod。

image.png

上圖是 ClusterIp 的一種實現(xiàn)方式疲酌，此外還包括 userSpace 代理模式（基本不用）蜡峰，以及 ipvs 模式（性能更好）。

DNS 模式很好理解徐勃，對 ClusterIp 模式的 Service 來說事示，它有一個 A 記錄是
service-name.namespace-name.svc.cluster.local，指向 ClusterIp 地址僻肖。所以一般使用過程中肖爵，我們直接調(diào)用 service-name 即可。

服務(wù)外訪問

image.png

南北向的流量臀脏，即外部請求訪問 Kubernetes 集群劝堪，主要包括三種方式：

• nodePort
• loadbalancer
• ingress

nodePort 同樣是 Service 的一種類型，通過 IPtables 賦予了調(diào)用宿主機上的特定 Port 就能訪問到背后 Service 的能力揉稚。

Loadbalancer 則是另一種 Service 類型秒啦，通過公有云提供的負載均衡器實現(xiàn)。

我們訪問 100 個服務(wù)可能需要創(chuàng)建 100 個 nodePort/Loadbalancer搀玖。我們希望通過一個統(tǒng)一的外部接入層訪問內(nèi)部 Kubernetes 集群余境，這就是 Ingress 的功能。

Ingress 提供了統(tǒng)一接入層灌诅，通過路由規(guī)則的不同匹配到后端不同的 Service 上芳来。

Ingress 可以看做是“Service 的 Service”。Ingress 在實現(xiàn)上往往結(jié)合 nodePort 以及 Loadbalancer 完成功能猜拾。

到現(xiàn)在為止即舌，我們簡單了解了 Kubernetes 的相關(guān)概念，它大致是怎么運作的挎袜，以及微服務(wù)是怎么運行在 Kubernetes 中的顽聂。于是當我們聽到別人討論 Kubernetes 時，我們可以知道他們在討論什么盯仪。