前言

之前的文章提到透過 K8s 的 Health Check，可以將不健康的 Pod 砍掉重建，或是確保 Pod 可以正常接收 Request，相信讀者應該很好奇 K8s 到底是如何做到這些功能的，接下來筆者就來談一下 K8s 內部架構。

kubelet

kubelet 用於管理該機器上的所有 Pod 狀態以及與 Master 進行即時溝通，簡單來說 kubelet 就是以管理員的身份存在，所有的 Pod 都是經過 kubelet 審核後才可以開始使用，所以在上一篇的 Health Check 提到：當 Pod 被 livenessProbe 偵測為不健康時，K8s 就會砍掉 Pod 並重建，而砍掉重建這段過程就是依賴 kubelet 完成的。

kube-proxy

kube-proxy 是用來實現 Service 功能，還記得在 Service 的文章提到，只要讓 selector 選擇到正確的 Pod Labels 就可以正確的連接到 Pod，但 Service 本身是沒辦法一次發多個 Request 到各個 Pod，當今天有多個 Pod 時 Service 要如何平均分散流量至各個 Pod，這段過程就是依賴 kube-proxy 來實現。

kube-proxy 一共有兩種方式來實作：

• Userspace

  在學系統架構的時候相信讀者一定很常聽到 Kernelspace 以及 Userspace，Kernelspace 指的是系統內部核心要操作時的空間，舉凡像是讀寫檔案等等需要操作到系統的都會在這邊運行，而 Userspace 能做的事情就比較少，只能做一些簡單的邏輯運算等等，這些只需要耗費一些記憶體以及 cpu 資源就可以完成的就會在 Userspace 中運行。

  在 kube-proxy 中 Userspace 的實作通常是會監聽一個 port，並把機器上所有的 Request 都轉發到這個 port，然後 kube-proxy 再將轉發至旗下的 Pod，整體看起來好像沒什麼問題，但光一個 Service 就要經過這麼多層的轉發想當然整體效率也會很差，所以現階段 kube-proxy 都不是用 Userspace 的方式實作。

• iptables

  iptables 則是使用 linux 的 iptables 進行實作，透過 iptables 的 netfilter 可以快速地進行網路位址轉換，也因為這個特性，所以可以讓一個 Service 代理非常多的 Pod，反正過程都會藉由 iptables 來進行網路位址轉換，讓整體效率提升許多省去很多轉發的過程，這也是目前 K8s 預設的實作方式。

  

container runtimes

container runtimes 則是 K8s 負責讓 Pod 內運行 container 的方法，K8s 支援非常多的實現方法有：Docker、containered、CRI-O，通常都是用 Docker 進行 Pod 內運行 container。

Addons

還記得先前筆者所介紹的 Ingress 文章嗎？裡面有提到 addons，但那時候只是輕描淡寫帶過而已，其實 addons 在 K8s 中代表的就是插件的意思，K8s 有非常多的插件可以使用，只要把插件內的某個功能 enable 起來就可以使用了，所以像是 Ingress、以及 HPA 文章時所介紹的 metrics-server 都是利用這種方式打開。

謎之聲：只有 minikube 這麼搞剛要各項打開，上雲端都開好好不用自己手動開了XD

DNS

不曉得大家在之前筆者介紹 Ingress 的時候有沒有好奇一點，為什麼可以直接寫上 ServiceName 這樣就可以自動找到對應的 Service，有點像是在瀏覽器打上 https://www.google.com/ 就會自動接到 Google 的伺服器一樣，相信讀者都知道所有的連線溝通都必須要依賴網路，沒有一個對應的 IP 就沒辦法連接到對應的服務，所以 K8s 內部也有一套 DNS 系統，方便 Pod 與 Service 之間互相溝通，而這套系統就叫：kube-dns。

小結

今天介紹了 K8s 的內部架構，相信讀者應該更了解 K8s 是如何處理內部的相關內容，先前疑惑的點可能也在這次的文章都有了答案。

接下來要介紹的內容不一定每位讀者都會用到，但其實也是蠻重要的觀念，如果有任何問題都歡迎留言給我，那我們就下篇文章見嘍～