咱們從 pod 一直分享到最近的 Statefulset 資源，到現(xiàn)在好像我們只是知道如何使用 k8s，如何按照 k8s 設(shè)計好的規(guī)則去應(yīng)用，去玩 k8s
仔細想想，對于 k8s 自身的內(nèi)在原理，我們好像還不是很清楚，對于每一個資源背后是如何實現(xiàn)的，我們好像也不得而知
或許也就只知道 k8s 是 golang 寫的吧
[圖片上傳失敗...(image-554dc4-1691586502729)]
我認為咱們學(xué)習(xí)一項技能，一項知識點的學(xué)習(xí)順序應(yīng)該是
- 學(xué)習(xí)如何應(yīng)用，培養(yǎng)自己感覺和興趣
- 學(xué)習(xí)應(yīng)用背后的內(nèi)在原理，知曉其細節(jié)
- 能夠?qū)ζ湓泄δ茏龆伍_發(fā)，加入自己的理解
前面基本分享了所有資源的使用方式以及實戰(zhàn)，今天開始，我們來逐步了解和分享 k8s 內(nèi)在自身原理
k8s 基本架構(gòu)
學(xué)習(xí) k8s 的時候，若一開始就學(xué) k8s 的架構(gòu)和組成，其實吸收的東西會比較少，自己的對于這項技術(shù)也沒有啥概念，當(dāng)然這也是一個熟悉的過程，慢慢學(xué)著會使用了，再來了解和學(xué)習(xí)他的原理，效果會更好
[圖片上傳失敗...(image-6ae016-1691586502729)]
k8s 中分為 主節(jié)點 master 和 工作節(jié)點 worker
我們可以是 1 個 master ，也可以是多 master 的
一般 master 節(jié)點會有如下 4 個核心組件：
- etcd ，用作持久化存儲
- Api Server，提供各種 Restful Api
- sheduler 調(diào)度器
- controller manager 控制器管理器
woker 節(jié)點一般會放這幾個組件：
- kube-proxy kubelet 服務(wù)代理
- kubelet
- 實際的服務(wù)對應(yīng)的容器
從上圖我們就可以知道，k8s 中所有的主控都是 master 節(jié)點來進行控制的，實際運行的容器是運行在工作節(jié)點上面的
通過上圖我們還可以知道，對于 訪問和修改 etcd，只有 Api Server 才能夠直接去交互，其他的組件都是不能直接訪問的
如何在 k8s 中查看上述組件的狀態(tài)呢？
我們可以使用 kubectl get componentstatuses 即可查看到 k8s 集群中的組件狀態(tài)，我們也可以寫縮寫，例如 kubectl get cs
[圖片上傳失敗...(image-1aad32-1691586502729)]
我的當(dāng)前環(huán)境是 minikube，可以暫時可以先不用關(guān)注截圖中的 error 信息
是不是會有點納悶，說好的這么多組件，咋沒有看到 ApiServer 呢？
都在下面了，我們可以使用 kubetl get po -n kube-system 查看 kube-system 命名空間下的 pod，我們就可以看到關(guān)于 apiserver，etcd，controller-manager，kube-proxy，scheduler 等信息了
[圖片上傳失敗...(image-2f8d30-1691586502729)]
同樣的，我們也可以把這些當(dāng)成普通的 pod 一樣，咱還是可以使用 kubectl describe 或者 kubectl edit 等指令來操作他們
例如：
我們可以嘗試命令kubectl edit po etcd-minikube -n kube-system，來查看到 etcd-minikube 的信息
注意，這里一定需要加上 -n kube-system 指定命名空間 ，因為當(dāng)前我們默認的 命名空間是 default ，如果不在命令中指令命名空間，則 k8s 會去默認的命名空間查找 pod
[圖片上傳失敗...(image-3e44f6-1691586502729)]
如果不指定命名空間，那么 k8s 在 default 默認命名空間中找不到 etcd-minikube 這個 pod
[圖片上傳失敗...(image-732a42-1691586502729)]
我們可以看到，系統(tǒng)組件 etcd，其實在 k8s 運行環(huán)境中也是一個正常的 Pod ，我們可以從 pod 清單中可以看到 kind: Pod
[圖片上傳失敗...(image-3376a6-1691586502729)]
spec 中具體的定義，使用了 k8s.gcr.io/etcd:3.5.0.0-0 版本的鏡像，以及 啟動 改容器，需要自行的命令和參數(shù)等等
那么 k8s 的 etcd 是干啥的？
還記得 etcd 我們在微服務(wù)開發(fā)時候，僅僅是用于存放 key-value 鍵值對的，那么 k8s 里面又是如何使用 etcd 的呢？
k8s 中的 etcd，是環(huán)境中唯一存儲集群狀態(tài)和元數(shù)據(jù)的地方，相當(dāng)重要哦
k8s 中的 etcd 是用來存儲 k8s 中每個資源清單信息的，例如 pod，RC，Service，私鑰，持久化方式等等，呈現(xiàn)方式也是 鍵值對
并且在 k8s ，如果 1 個 etcd 不夠用了，我們也是可以橫向擴容，運行多個 etcd 的實例就可以了
前面我們也提到了，在 k8s 中的各個系統(tǒng)組件，只能通過 ApiServer 進行通信，另外 ApiServer 是和 etcd 通信的唯一組件，也就是說 ApiServer 是 etcd 的唯一客戶端，其他的組件是沒有辦法修改 etcd 里面的數(shù)據(jù)的
這是為什么呢？所有組件都要通過 ApiServer 才能訪問和 修改 etcd，這樣做是有啥好處呢？
好處 1 ：
可以增強 k8s 驗證系統(tǒng)的健壯性，來源只有 1 個，簡單清晰
好處 2 ：
就只有 etcd 和 Apiserver 交互，不存在其他組件的耦合，那么替換存儲機制也是比較方便的
好處 3 ：
k8s 中多 master 的時候，仍然適用于 控制平臺操作存儲模塊的時候，同樣是需要通過和 ApiServer 交互，這樣咱們的 k8s 集群狀態(tài)才會總是一致的
k8s 的 Apiserver 具體是做了哪些事情呢？
簡單來說 Apiserver 組件主要就是提供 RESTful API ，接收其他組件的請求，對請求的數(shù)據(jù)做校驗，并將請求給到 etcd
例如，查詢集群狀態(tài)，修改 pod ，刪除 RS ，創(chuàng)建指定資源等等
細心的 xdm 應(yīng)該就可以發(fā)現(xiàn)，我們是如何訪問 ApiServer 的呢？ApiServer 的客戶端又是誰呢？
是滴，就是我們一直都在使用的 kubectl，一直以來，我們都在使用 kubectl 來和 ApiServer 進行通信，那么是否會有這樣的疑問：
我多開幾個 master 的窗口，同時使用 kubectl 創(chuàng)建會有沖突的資源，那么 ApiServer 會如何處理呢？
這一點，xdm 大可放心， ApiServer 自身會有一致性的機制，
第一，就是 ApiServer 是唯一和 etcd 通信的客戶端
第二，ApiServer 自身還會處理樂觀鎖，會保證最終一致性，在并發(fā)更新資源的情況下，A 對對象做的更改不會去覆蓋 B 對對象做的更改
那么其他組件訪問 ApiServer 的時候，ApiServer 內(nèi)部處理流程是什么樣的呢？
- ApiServer 會去校驗客戶端是否通過認證
- ApiServer 會去校驗客戶端是否通過授權(quán)
- ApiServer 會去校驗客戶端是否通過準入插件的驗證（對資源進行創(chuàng)建，刪除，編輯的時候會校驗）
- 若以上都通過了，那么 ApiServer 會將數(shù)據(jù)給到 etcd，并給客戶端做響應(yīng)
用一個圖展示，可以是這樣的：
[圖片上傳失敗...(image-4a83ee-1691586502729)]
那么 ApiServer 又是如何通知 客戶端資源變更的？
你可能會認為是 ApiServer 自己去控制和通知具體的控制器去做事情，并不是的，其實是通過 k8s 內(nèi)部的監(jiān)聽機制，如圖：
[圖片上傳失敗...(image-efd9d7-1691586502729)]
當(dāng) ApiServer 收到客戶端的請求時，ApiServer 校驗完成后去更新 etcd，最終會啟動對應(yīng)的控制器，客戶端自己會做監(jiān)聽，收到監(jiān)聽的變更信息之后，就會去對應(yīng)的更新對象了
今天就到這里，學(xué)習(xí)所得，若有偏差，還請斧正
歡迎點贊，關(guān)注，收藏
朋友們，你的支持和鼓勵，是我堅持分享，提高質(zhì)量的動力
[圖片上傳失敗...(image-750633-1691586502729)]
好了，本次就到這里
技術(shù)是開放的，我們的心態(tài)，更應(yīng)是開放的。擁抱變化，向陽而生，努力向前行。
我是阿兵云原生，歡迎點贊關(guān)注收藏，下次見~
