Kubernetes[1] — 運行流程

會用是一回事，理解到底是怎麼讓它動起來又是一回事。

常自嘲腦袋裡的REM大概只有KB等級的廢物我本人，在用各種領域需要的開源服務或工具的時候，會搭建嗯好基本，會用那必須得的啊廢話！

但隨著時間的深入，有時候維運，例如spark出現了OOM問題要替user解決，除錯除了看log之外，了解運作原理是怎麼樣開始的是我永遠也做不完的功課。盲目的亂調參數並不是一個最優雅的方式，就算剛好我瞎貓碰到死老鼠tunning到可以了沒問題了，但我不是確切的知道為什麼啊幹！

我他媽到底做了什麼？ 你怎麼又可以動了？

有些大神會去解析原始碼或是用途去解釋流程，為什麼會誰打誰、誰跟誰對接之類這種，啊我常常看了就

哩咧公三小 哇跨謀

對，我就是會忘記。看完又掉五成的那種，所以我要常常回去再重看一次，另外刷題的時候遇到比較難纏的題目也是這樣。寫完很高興哇偶真棒～然後過幾天再重看一次題目：

欸不是 那時候是怎麼寫出來的？

還問我自己咧糙，不是你寫的嗎？

你要確定欸？

所以複習文們就這樣出現了，為了拯救我少的可憐的暫存記憶體把它好好的存成disk記下來。(我就是那種剛出家門會又折回來至少兩三次的健忘症患者，嘴巴明明還唸著手機錢包鑰匙之類這種必需品的)

在上一篇中有介紹了每個component的作用是什麼了，今天就來扒一下

如果是一個pod的創建，會經過哪些步驟？

一樣我們先來從官方文檔的架構圖來瞧瞧

ref: https://kubernetes.io/docs/concepts/overview/components/

簡單複習一下，Master node(圖中的control plane)就是出一張嘴的人比如說你主管，Worker node(圖中的node們)就是勞動階級你本人(聲明：我愛我的公司，我愛我的工作，主管是我的天，老闆是我的信仰)

有個前提要說在前面，很重要所以我講三遍
所有component之間的溝通都是透過API
所有component之間的溝通都是透過API
所有component之間的溝通都是透過API

整體流程以白話的方式來描述的話會像下面這樣：

1. 當你在Master node上提交出 $ kubectl create -f example.yaml，這種部署的設定檔時，會交給api-server，當提交出的要求通過時，這時候control manager手握這創建pod具體需要的資源和設定做出分配，這次的動作會把資源資訊存在etcd裡面。
2. 這時候api-server負責review，審核檢查api key有沒有在有效期限內啦、語法啦、完成後etcd又把這紀錄存起來，然後叫scheduler去喬。
3. scheduler一臉矇，喔要搞事啦？要喬什麼？新來的pod？那我得看看它位置和適合塞去哪邊。所以他跑去問etcd，新人誰啊？
4. 在第一點中etcd裡已經有這個新來的pod的部署設定，所以scheduler拿到他要的東西了，他就會開始安排，決定好新來的pod要去哪台node上。
5. scheduler終於做完他的ppt報告了跟api-server報告完了，身為國小午休時間的最愛畫正字號記不睡覺的同學的風紀股長，什麼都要記的etcd，記錄下這次的新人安排。
6. api-server通知新人要報到的worker node，你們有新人來接一下空個位置出來。這時候worker node上的kubelet就會去問etcd，欸這個新來的要什麼排場啊？然後叫container runtime款款欸準備好叫他有新來的要play one了。
7. 由於是在不同機器上的共同協作，網路的部分就會有kube-proxy來處理。可以把它想像成是引路和開路的人。在每台worker node都會有kubelet和kube-proxy，kube-proxy就是大廳的保安大哥。為了要讓新來的pod家裡有門牌號碼安排起來，別人要怎麼找到他，就他負責的事了。

以上就是一個pod建立的過程會經過哪些component啦！
可以觀察到，每個component要做的事情都分得很清楚，看起來好像很複雜，但其實都是在各自做該做的事情，處理的事情劃分得很明顯。

其實在上面的敘述中，只是一個大概的流程。後面再來細展開這些流程中技術的層面運行。

下一篇來介紹resource object！

也就是大家常聽的 depolyment、 serivce、和depolymen看似糾纏不清的replication set，這些到底是什麼東西？差別在哪邊？

咱下篇見！

一樣感謝看到這邊的你，若有大神願意指點哪邊有誤，還請不吝指教，小的先跪謝～

參考資料：
https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/
https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/
https://blog.pichuang.com.tw/20201009-kubernetes-api-communication.html
https://codelove.tw/@tony/post/AqJwrx
https://www.oreilly.com/library/view/kubernetes-best-practices/9781492056461/ch17.html
https://blog.pichuang.com.tw/20201009-kubernetes-api-communication.html