本篇文章是一個深度介紹文,除了探討 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
overlay用法 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
本文延續前一篇文章,作者探討十五種 Kubernetes 不該使用的部署與維運模式,總共三篇,每篇五種。
Misusing Health probes
Kubernetes 內有設定三種不同的 Probe,分別是 Readiness, Liveness 以及 Startup,前兩者 Probe 比較常被提到而且會不停的執行,而 Startup 則是會被運行一次的 Probe。
作者認為所有開發者都要去研究這三種的差異並且小心使用。
文章中列舉一些常見的錯誤用法
1. 用相同的 endpoint 同時處理 liveness 以及 readiness
2. 繼續沿用過往針對 VM 所設計的 health endpoint,應該要針對容器環境重新設計
3. Health 的檢查過於複雜,導致需要花費一個不可預測的時間
..
等
Not using the Helm package manager
作者認為目前 Kubernetes 生態系中只有一個 Package Manager,也就是 Helm,就像是常見的 apt/rpm 等套件般去管理不同的應用程式。
然而 Helm 卻很容易被誤解並拿去跟其他工具比較,譬如 Kustomize, Jsonnet.. 等。
從本質上來看 Helm, Helm 本身有 Package 的管理能力,同時也透過 Template 的方式來產生適合於不同環境的 YAML 檔案。 而上述其他的比較解決方案基本上都只能完成後者,透過如 overlay (kustomize) 等不同的方式來產生不同的 YAML,但是本身卻沒有去管理這些安裝好的應用程式。
如何產生 YAML 這些是部署前的流程,而上述的那些工具對於檔案部署到 Kubernetes 後就無能為力了,譬如想要刪除任何安裝到 Kubernetes 資源的應用程式,必須要找到原始的 YAML 檔案。而 Helm 則不一樣,本身會於 Cluster 內去記錄這些這些資訊,讓你可以透過 helm 的指令去刪除這些安裝好的應用程式。
作者認為除非團隊很明確的瞭解與設計其工作流程,確保 Helm 帶來的部署與管理流程不需要,否則推薦任何團隊都可以採用 Helm,特別是之前因為 Helm2 Tiller 而厭惡的人必須要來試試看 Helm3
Not having a strategy for secrets
如同先前探討的 Configuration 不應該直接嵌入 Contaienr Image 一樣,Secret 這類型的物件也一樣,作者看到團隊常有下列錯誤
1. 使用各種不同的方式來管理 Secret 物件
2. 沒有區分好運行期需要的 Secret 與建制時期需要的 Secret
3. 過於複雜的處理方式導致本地測試與開發過於困難
相反的,團隊應該要
1. 選擇一個策略
2. 所有團隊使用該策略來處理 Secret
3. 所有的 Secret 應該都要用相同的方式處理
4. 這樣的機制使得 secret 的管理與追蹤更為容易
Attempting to solve all problems with Kubernetes
永遠不要認為 Kubernetes 能夠解決所有問題,團隊必須要理解到 Kubernetes 帶來的優點與缺點,團隊本身的部署與工作流程是否適合使用 Kubernetes。
也不要想說要把所有服務都搬到 Kubernetes 內,譬如 databases, caching 等,這些本來就存在的解決方案依然可以使用本來的方式繼續部署,不要一相情願地覺得這些東西放到 Kubernetes 內就一定會更好。
詳細原文可以參考下列連結。
https://medium.com/containers-101/kubernetes-deployment-antipatterns-part-3-dfbdd2fd3292
overlay用法 在 GNU LD 手冊略讀(2): Chapter 3.6 SETCIONS 的推薦與評價
這表示所有的section的VMA會相同。為了方便,linker會把所有 OVERLAY 中的section串接成連續的空間。 OVERLAY用法如下. linker script設定OVERLAY ... ... <看更多>
overlay用法 在 請問OVERLAY是什麼東西?顯卡普遍都有嗎? - Mobile01 的推薦與評價
翻閱了電視棒的說明書, 他說我可能是顯示卡的「效能太差」,或者顯示卡「不支援OVERLAY技術」, 我的NB顯示晶片是分享式的intel 82830M,會很差嗎?很差 ... ... <看更多>
overlay用法 在 演示 overlay 的用法 - gists · GitHub 的推薦與評價
演示 overlay 的用法. GitHub Gist: instantly share code, notes, and snippets. ... <看更多>