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 的看家本領了，是以我們有必要了解一下。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-kubernetes
4月21-22日，XOps風向标！GOPS 全球運維大會 2022 · 深圳站正式開啟，國内外網際網路、金融、通信領域TOP議題來襲~，關注 GOPS，運維轉型不背鍋~
近期好文：
這篇文章為你 Redis 知識面來個查漏補缺
“高效運維”公衆号誠邀廣大技術人員投稿，
投稿郵箱：[email protected]，或添加聯系人微信：greatops1118.