前面咱們分享了 mater 和 worker 節(jié)點(diǎn)里面都有哪些組件，他們又是各自主要負(fù)責(zé)的工作是什么，現(xiàn)在我們心里應(yīng)該都有數(shù)了吧

master 節(jié)點(diǎn)：

etcd 存儲(chǔ)資源配置，ApiServer 提供 RESTful Api 用于交互，scheduler 用于調(diào)度 pod，controller manager 控制器管理器

worker 節(jié)點(diǎn)：

kubelet 管理 節(jié)點(diǎn)上的所有組件和內(nèi)容，kube-proxy，作為代理將數(shù)據(jù)給到 pod

從控制器到 pod 運(yùn)行，是如何達(dá)成的？

那么今天來分享一下，這些組件都是如何高效配合協(xié)同作戰(zhàn)的，我們可以從控制器作為切入點(diǎn)，來看看

前面我們說到 master 里面的組件是不會(huì)直接去創(chuàng)建和運(yùn)行 pod 的，只會(huì)和 ApiServer 通信，那么我們來看看創(chuàng)建一個(gè) 控制器的資源，到最終 pod 運(yùn)行，中間都會(huì)涉及哪些控制器，哪些資源，哪些動(dòng)作

我們都知道，咱們在生產(chǎn)環(huán)境下面，是不會(huì)直接去創(chuàng)建 pod 資源的，而是通過 RC / RS 去管控 pod ，然后我們是否還記得 Deployment 資源是會(huì)去管控 RS 的，那么我們就用之前環(huán)境中一直有的 deploy 來演示一下效果吧

看一下環(huán)境中的 deploy

可以看到環(huán)境中是有 5 個(gè) pod，我們進(jìn)入 newkubia ，將副本數(shù)修改為 3 個(gè)，并且在另外一個(gè)窗口進(jìn)入到 master 節(jié)點(diǎn)，開啟事件監(jiān)控 kubectl get events --watch

在將 newkubia Deployment 從 5 個(gè)副本修改到 3 個(gè)副本的時(shí)候，我們可以看到此處的事件監(jiān)控能夠看到監(jiān)控的信息

[xmt@VM-20-15-centos?~]$?kubectl?get?events?--watch
LAST?SEEN???TYPE?????REASON??????????????OBJECT????????????????MESSAGE
0s??????????Normal???ScalingReplicaSet???deployment/newkubia???Scaled?down?replica?set?newkubia-85df599b7f?to?3
0s??????????Normal???Killing?????????????pod/newkubia-85df599b7f-zhwnw???Stopping?container?newkubia
0s??????????Normal???Killing?????????????pod/newkubia-85df599b7f-jzjsn???Stopping?container?newkubia
0s??????????Normal???SuccessfulDelete????replicaset/newkubia-85df599b7f???Deleted?pod:?newkubia-85df599b7f-zhwnw
0s??????????Normal???SuccessfulDelete????replicaset/newkubia-85df599b7f???Deleted?pod:?newkubia-85df599b7f-jzjsn


咱可以在 REASON 字段處看到，經(jīng)歷的過程是 ?**ScalingReplicaSet -> Killing newkubia-85df599b7f-zhwnw -> ?Killing newkubia-85df599b7f-jzjsn -> SuccessfulDelete **

上述過程中，就會(huì)涉及到這些 控制器：

• Deployment 控制器

• ReplicaSet 控制器

還涉及 調(diào)度器，ApiServer 和 kubelet 和 docker

首先是各種控制器會(huì)監(jiān)聽 ApiIServer 里面對應(yīng)的資源，當(dāng)我們修改 newkubia Deployment 清單的副本數(shù)時(shí)候，

• kubectl 會(huì)發(fā) http 請求 POST 方法去請求 ApiServer，ApiServer 修改對應(yīng)的 etcd 數(shù)據(jù)

• Deployment 控制器監(jiān)控到 Deployment 資源有變動(dòng)，則會(huì)去和 APiServer 交互修改 ReplicaSet 資源的副本數(shù)

• ReplicaSet 此時(shí)監(jiān)聽到 ApiServer 處的 ReplicaSet 資源有變動(dòng)，則會(huì) 與 ApiServer 進(jìn)行交互 去通知 相應(yīng)的 pod 資源 進(jìn)行需要進(jìn)行更新

• 調(diào)度器 scheduler 同樣也是監(jiān)聽到 ApiServer 中的 pod 資源有變動(dòng)后，Scheduler 就會(huì)去和 ApiServer 交互 在相應(yīng)節(jié)點(diǎn)上配置增刪 pod

• 對應(yīng)節(jié)點(diǎn)的 kubelet 監(jiān)聽到 ApiServer 中 pod 資源的變化，便會(huì)去通知自己節(jié)點(diǎn)的 docker，進(jìn)行增加運(yùn)行容器和刪除容器的動(dòng)作

通過上述簡圖和描述，相應(yīng)到這里，xdm 對于修改一個(gè) deployment 資源的副本數(shù)， k8s 中從控制器 到 實(shí)際的 pod 會(huì)涉及哪些組件了吧！

今天就到這里，學(xué)習(xí)所得，若有偏差，還請斧正

歡迎點(diǎn)贊，關(guān)注，收藏

朋友們，你的支持和鼓勵(lì)，是我堅(jiān)持分享，提高質(zhì)量的動(dòng)力

好了，本次就到這里

技術(shù)是開放的，我們的心態(tài)，更應(yīng)是開放的。擁抱變化，向陽而生，努力向前行。

我是阿兵云原生，歡迎點(diǎn)贊關(guān)注收藏，下次見~