關於 node controller ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://loft.sh/blog/the-cost-of-managed-kubernetes-a-comparison/

本篇文章探討不同 Cloud Provider kubernetes 服務的差異，作者列舉了四個常見的 kubernetes 服務，包含 GKE, EKS, AKS 以及 DOKS。

這四個 kubernetes 服務所部署的 Kubernetes 叢集都有獲得 CNCF Kubernetes Certification 的認證，不同 Cloud Provider 都有自己的優缺點。
使用 Kubernetes 服務帶來的好處就是使用者通常不太需要去擔心如何處理
1. Kubernetes 核心元件之間的 Certificate (API Server, Controller, Scheduler, Kubelet ...etc)
2. 動態調整 Kubernetes 節點
3. 相較於單純靠社群， Cloud Provider 可以提供更快速且更好的支援(畢竟有付錢給對方)

因此該文章接下來就會針對這四個 Kubernetes 服務來探討一下彼此的差異。

註: 有興趣的話都可以用 Sonobuoy 這個開源專案來檢測自己維護的 Kubernetes 叢集，通過測試就可以把測試報告送到 GitHub 開 Issue 申請認證

GKE
1. Kubernetes 正式公開後一個月就 GKE 就出現了 (08/2015), 是最早的 Kubernetes 服務
2. GKE 會使用 gVisor 專注於安全層級的容器隔離技術來部署服務。
3. 有機會使用針對 Container 最佳化的 OS，有些 cloud provider 只能使用 Ubuntu image 之類的。
4. 服務出現問題時，可以啟動 auto-repair 來修復叢集，一種典型作法就是將一直回報為 NotReady 的 k8s 節點給重建
5. GKE 提供自動升級 Kubernetes 版本的功能，如果不想要的話記得要去關閉這個功能，否則自動升級是有可能讓某些應用程式無法正常運作的。
6. 使用 GKE 的話，要付每小時 $0.1 美元的管理費。如果使用 on-prem 的解決方案 (Anthos) 的話就可以免去這些管理費。

EKS
1. 06/2018 創立
2. 可以使用 Ubuntu Image 或是 AWS 針對 EKS 最佳化的 EKS AMI 來獲得更好的效能。
3. EKS 沒有提供自動升級 Kubernetes 版本的功能，官方有提供大量詳細的文件介紹如何手動升級 Kubernetes 版本
4. 沒有類似 auto-repair 的機制去幫忙監控與修復出問題的 k8s node，因此 EKS 使用者需要自己去監控與維護這些節點。
5. EKS 也是每小時 $0.10 的管理費用。 AWS Outposts/EKS Anywhere 這些 2021 啟動的專案讓你有機會將 EKS 部署到 on-prem 的環境中。

AKS
1. 06/2018 創立
2. AKS 沒有提供任何最佳化的 OS，你只能使用常見的那些 OS image 作為你的 k8s 節點
3. 預設情況不會自動升級 kubernetes 版本，不過 AKS 提供選項去開啟自動升級。Cluster 有四種不同策略(none,patch,stable,rapid)來自動更新你的 k8s 叢集。
4. AKS 預設不會啟動 auto-repair 功能。對於一直持續回報 NotReady 的節點， AKS 會先重起該節點，如果問題無法解決就會砍掉重建節點。
5. AKS 不收管理費
6. Azure 沒有特別提供一個供 on-prem 的 AKS 解決方案，不過透過 ARC 是有機會於 on-prem 的環境運行 AKS.

DOKS(DigitalOcean)
1. 05/2019 創立
2. 有提供 kubernetes 版本自動更新功能，但是只有針對 patch 版本的變化
3. 沒有 auto-repair 的功能
4. 文章撰寫的當下， DOKS 沒有任何文件說明如何於 on-prem 的環境運行 DOKS
5. 不收管理費
6. 相對其他三家來說，底層架構相對便宜，一個 DOKS 最低可以低到每個月 $10 美元。

價錢比較:
1. 假設需要創建一個擁有 20 節點並且有 80vCPU, 320GB RAM 的叢集 (GKE 因為每個節點都是 15GB，所以最後只能湊到 300GB)
2. 每個月為單位去計算價格，AKS/EKS/GKE 都使用其提供的價格計算機來粗估， DOKS 需要手動計算。
3. 價錢評比
a. AKS: $3416
b. EKS: $2928
c. DOKS: $2400
d. GKE: $1747

對文章有興趣的別忘了參閱全文

本篇文章是一個深度介紹文，除了探討 K3S 與 K3D 的關係之外，還針對 K3D 的架構與使用方法很詳細的介紹一番，包含了
1. K3D v3 的特色與架構
2. 如何替換 K3D 裡面的 CNI
3. 如何替換 k3D 預設的 Ingress Controller
4. 使用 private registry 來處理

Kubernetes 的變化版本很多，除了 k3s 之外後來還有 k0s 的出現，每個版本都有自己想要解決的問題，而 k3s 則是一個非常輕量的 Kubernetes 版本，其特色有
1. 使用 Flannel 作為其預設 CNI，不講求太多複雜功能，單純用 VXLAN 打造一個 L2 的 overlay 網路
2. 使用 CoreDNS，與原生一樣
3. 使用 SQLite3 當作預設的 DB，而非 etcd3
4. 使用 Traefik 當作預設的 Ingress Controller，原生 K8s 則把這個主動權交給使用者
5. 使用 Containerd 當作預設的 Container Runtime

而 K3D 就是基於 K3S 的測試環境， K3S in Docker，跟 KIND 類似，只是運行的 Kubernetes 發行版本不同。

相較於 KIND 而已， K3D 的架構稍微複雜一點
1. 為了方便測試與存取，k3D 部署的時候也會部署一個 Nginx Server 來當作簡易的 Load-Balacner，讓 K3D 內的 Ingress 服務可以更簡易的被存取。使用者只需要存取該 Load-Balancer 即可，不需要去針對 Node(Docker) 的 IP 存取
2. 可以支援動態加入與刪除節點

本篇文章算是非常詳細的介紹各種參數用法，對於 K3D 這種測試環境有興趣的可以參考看看
https://yannalbou.medium.com/k3s-k3d-k8s-a-new-perfect-match-for-dev-and-test-e8b871aa6a42

如果你跟我一樣，是 kubectl 愛好者，對於其他操作介面譬如 k9s 等都不習慣的人，那我認為一定要來瞭解一下 kubectl plugin 的用法

1. kubectl plugin 本身的設計使得大家非常容易的擴充，並不需要修改 kubectl 的任何原始碼或是重新編譯。相反的只需要準備相關的執行檔案，並且依據特定規則命名即可
2. krew 是一套管理 kubectl plugin 的套件，能夠幫你整理目前官方收集的 plugin 並且提供指令讓你去安裝與刪除
3. 本文列出了幾個作者認為好用的指令，譬如 whoami，可以讓你知道你當前透過 KUBECONFIG 連接到遠方 cluster 時是以什麼樣的身份被認證
4. access-matrix 幫你列出目前系統中 RBAC 的相關權限，用一個比較易閱讀的方式呈現
5. neat 是一個清除工具，可以幫忙將 kubectl get pods xxx -o yaml 中那些由 controller 所添加的資源給移除，讓你得到一個乾淨的輸出
6. node-shell 是個非常好用的工具，可以幫你掛載一個 shell 到任意的 k8s node 之中，讓你透過該 shell 來操作該節點

除了這些之外，我認為 ksniff 也是個滿有趣的工具，可以幫忙運行 tcpdump 來錄製封包

如果有興趣的可以直接到 krew 的官方文件去看看目前收錄的 plugin 有哪些，然後可以都玩看看來找到一些對自己工作有幫助的指令

https://www.padok.fr/en/blog/kubectl-plugins

資訊推播頻道 Telegram: https://t.me/technologynote
演講投影片 SlideShare: https://www.slideshare.net/hongweiqiu/presentations
粉絲頁內容索引網站:
https://technologynoteniu.github.io/awesome-notes/