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

本篇文章是一個深度介紹文，除了探討 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

本篇文章是經驗分享文，作者分享為什麼其跟最初學習 Kubernetes 使用的 minikube 說掰掰，而轉換到新歡 KIND 的故事

作者之前演講分享時，透過 minikube 架設所有 demo 環境，平常使用都好好的然而活動前幾天開始覺得叢集有點慢，但是作者並沒有特別注意去處理。
活動當天 demo 直接爆炸，系統變得很慢，不論是 pod 的各種操作都很慢，作者沒有辦法很漂亮的清除 minikube 內的環境，最後只好砍掉VM全部重來。

活動結束後作者重新創建了一次整個 VM(使用 VirtualBox)，結果整個系統還是很慢，作者開始思考有沒有其他的替代方案，後來找到了 Kind 這套解決方案。

KIND 是 Kubernetes In Docker 的縮寫，透過 Docker Container 的方式創建節點並基於該節點創建 Kubernetes 叢集。

這邊要注意的是 KIND 透過 Docker 創建節點，而節點內卻使用 Contaeinrd 作為 k8s 的 CRI 解決方案。

除了 KIND 之外， Rancher 維護的 K3D 也是一樣類型的創建方式，其中 K3D 支持動態加入與移除節點，KIND 只能一開始創建時就定好 cluster 的大小。

https://nfrankel.medium.com/goodbye-minikube-340070edc5af

本文是一篇 2017 年的文章，雖然已經四年之久，但是我認為本篇文章值得一讀。
作者團隊於 2017 年時正在經歷如何將 VM 上的各種 Java 應用程式轉移到 Kubernetes 內的 Container，而本篇文章則是探討到底 Container 是如何透過 Linux Control Group 以及 namespace 實作的，透過對這些底層實作的瞭解，才有辦法針對 Container 效能部分去除錯與提升。

這種文章探討的都是很底層的概念，建議所有人都閱讀一遍，好好複習關於 cgroups/namespace 的概念，透過對這些概念的理解與掌握，能夠更有系統的去解釋何謂Docker Container，何謂輕量級虛擬化。

以下幫大家節錄一些重點，還是推薦自行閱讀全文

1. cgroup 用來隔離與限制 CPU,Memory,Disk,Network Bandwidth 等資源的用量
2. namespace 則是用來限制 ipc, pid, mount ,network, utc 等資訊的可視性，不同 namespace 內看到的資訊是獨立的，但是最終彼此還是屬於同一個 Kernel。
3. 任何沒有被 cgroup 規範的應用程式都會被自動包含到 root cgroup 的規範，不同發行版其位置不同，譬如 /sys/fs/cgropu.

假設今天透過 docker run 去運行一個 java 應用程式
a. Docker 會創建一個 pid namespace，接者運行 Java 前先把該應用程式給掛到新的 pid namespace 上並且賦予該 java 應用程式 PID 1
註: Host 上還是可以觀察到該 Java 應用程式，因為除了 Host 本身外，每個 pid namespace 都有自己的老爸，而老爸是可以看到小孩資訊的，這意味 docker dameon 雖然創建新的 pid namespace，但是host的pid namespace 實際是新 namespace 的老爸
b. 從老爸的視角來看，可以看到該 Java 應用程式也會有一個不同的 PID，而這個 PID 也會於 cgroup 系統中有自己的設定

4. CPU Cgroup 則是會用 share 為單位來定義每個 task 可以獲得多少相對的 CPU 時間，相對的算法是去計算 task 擁有的 share 數量佔了整個 cgroup 階層元件中的多少百分比。
舉例: 捨去其他服務單純考慮運行三個 Container 且有 4 Core CPU 的環境，三個 Container Task 分別給予 2048,1024,1024 share 的話，第一個 Container 大致是會被分配到兩個 CPU Time

5. CPU shares 沒有辦法去保證每個 task 最小用量是多少，所以需要透過 CPU Quotas 的概念來設定 CPU.cfs_quota_us(假設使用 CFS 這個排成演算法)以及 CPU.cfs_period_us(預設100ms)。
概念大概就是 cfs_period_us 定義的時間內，你最小可以使用多少時間，所以假如設定 cfs_quota_us 為 100ms，則預設情況下該 process 可以使用的量就是 100ms/100ms = 1 ~= 1 Core CPU

k8s 與上述的相關bug 可參考下列 issue
https://github.com/kubernetes/kubernetes/issues/67577

6. JVM 看到的是系統上全部的 CPU 資源，但是 Contaienr 本身當被限制 CPU 用量時，會有資訊落差，造成 GC 運行的效果不如預期，因為其認為系統有超多 CPU，而不知道自己其實被限制的CPU很少。

原文滿精彩的，推薦閱讀
https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling