本篇文章是ㄧ個 Kubernetes 相關工具經驗分享文,作者認為即使是前端開發工程師也必須要瞭解一下 Kubernetes 這個容器管理平台,作者認為 k8s 基本上已經算是這個領域的標準(de-facto)。
因此作者於本篇文章介紹一些搭建一個 K8s 叢集時需要注意的工具,透過這些自動化工具來減少反覆動作的執行藉此簡化每天的工作流程。
工具包含
1. ArgoCD
2. MetalLB
3. External-secrets
4. Cert-manager
5. External-dns
Simplify deploying of new apps
作者大力推薦使用 ArgoCD 來簡化部署應用程式,作者提到一開始使用 ArgoCD 時也是感到無比煩感,因為心中一直存在要於 `GitLab CI/CD pipeline` 透過 kubectl apply 的方式來部署應用程式,並不想要導入其他的元件來加入更多的複雜性。
然而當作者嘗試 ArgoCD 後,第一眼發現的是其架構不如想像中複雜,完全依賴 GitOps 的原則來簡化整個部署流程,同時透過一個 WebUI 的方式來呈現當前應用程式的部署狀況
Load balancer for your on-prem clusters
地端環境的 Load-Balancer,沒什麼好說就是 MetalLB。
Managing your secrets
Secrets 是 Kubernetes 內一個非常重要的物件,然而大部分的團隊都會思考如何有效且安全的去管理 Kubernetes 內的 Secret 物件。雲端供應商譬如 AWS Secrets Manager, Azure Key Vault 或是廣受熱門的 HashiCorp Vault.
作者推薦使用 external-secrets operator 這個專案來將外部的管理系統給同步到 Kubernetes 內並且產生對於的 secrets。
詳細全文可以參考下列原文
https://chris-blogs.medium.com/tools-that-should-be-used-in-every-kubernetes-cluster-38969ed3e603
「kubectl apply」的推薦目錄:
- 關於kubectl apply 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於kubectl apply 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
- 關於kubectl apply 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
- 關於kubectl apply 在 kubectl apply - Kubernetes 的評價
- 關於kubectl apply 在 kubectl apply vs kubectl create? - Stack Overflow 的評價
- 關於kubectl apply 在 jhipster-online/kubectl-apply.sh at main - GitHub 的評價
kubectl apply 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
這篇文章探討的是 kubectl 於 1.18 對於 kubectl run/kubectl create 改動所造成的影響,這個影響我認為層面不會太大,但是對於習慣用 kubectl run 的人來是一個滿大的困擾,簡單來說就是移除了一些用法,但是卻沒有任何替代解決方案可以取代。
kubectl v1.18 以前,你有至少三種方法可以部署一個 Deployment 到 Kubernetes 中
1. 撰寫程式並且透過相關函式庫直接戳 kubernetes API server 來創建資源
2. 手動撰寫 YAML 檔案,透過 kubectl apply -f 等類似方式創建
3. 透過 kubectl run (e.g kubectl run nginx-1 --image=nginx --port=80 --restart=Always) 此方式來動態創建一個 deployment.
基於各種維護與管理考量,任何的生產環境都會基於 (1)/(2) 這類型可以控管的方式來部署應用程式,基本上不會使用 (3) 這種方式來創建,但是 (3) 某些情況下滿好用的,譬如
1. 新手測試,想要快速起一個 deployment 測試,但是卻不知道去哪邊找一個 deployment Yaml 的範例(Deployment YAML 本身結構多層,人腦難以記住全貌)
2. 一些 OSS 專案想要提供使用者一些範例去操作,會提供 kubectl run 的指令來創建資源
作者還表示可以將 (2) + (3) 給結合,譬如透過下列方式可以產生一個 YAML 內容
kubectl run nginx-1 --image=nginx:1.14.2 --port=80 \
--restart=Always -o yaml --dry-run
接者透過這個範例去創建與修改來達到 (2) 的做法
不過這一切都隨者 kubectl v1.18 的改變而壞光了,因為 v1.18 後 kubectl run 不再支援 deployment 的創建,退而求其次要求使用者透過 kubectl create 去創建資源,但是其支援的參數比過往還要少,所以沒有辦法透過 kubectl create 取代 kubectl run 的所有用法。
詳細的一些內容與比較可以參閱全文
https://alexellisuk.medium.com/kubernetes-1-18-broke-kubectl-run-heres-what-to-do-about-it-2a88e5fb389a
PR: https://github.com/kubernetes/kubernetes/pull/87077
PR: https://github.com/kubernetes/kubectl/issues/898
kubectl apply 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
如果你機會跑過 kubernetes 1.18 版本,一定要試試看最基本的 kubectl get pods -o yaml,看看是不是內容裡面多出了非常多 f:{} 系列的檔案,導致整個 Yaml 變得非常冗長,閱讀不易,甚至想要抓取到最原始的內容都非常麻煩。
Kubernetes 官方 Github 上還有相關的 issue 再討論這個欄位,詢問是否有辦法能夠清除。不少人都提出了一些希望的用法來處理
Issue: https://github.com/kubernetes/kubernetes/issues/90066
目前看下來最簡單的做法還是透過 kubectl plugin, kubectl-neat 來幫忙完成,可以透過 krew 這個 kubectl 管理工具來安裝管理
https://github.com/itaysk/kubectl-neat
此工具可以將 Server 上得到 Yaml 的內容給整理最後得到最初的檔案
至於到底什麼是 managedFiles? 這個由欄位的出現是因為 1.18 以後,已經將 Server Side Apply 更新策略預設啟用而導致的,而 Server Side Apply 則是一種用來管理 Declarative 設定檔案的方式,對使用者來說基本上完全無感,因為一切都還是透過 kubectl apply 來使用,只是到底如何判斷 當前檔案內容與系統上內容誰先誰後,誰對誰錯,甚至當有人透過 kubectl edit 去編輯內容的時候,到底該怎麼更新。
之後有時間可以再寫一篇來詳細介紹 Kubernetes 內的 Declarative 更新策略
kubectl apply 在 jhipster-online/kubectl-apply.sh at main - GitHub 的推薦與評價
# Files are ordered in proper order with needed wait for the dependent custom resource definitions to get initialized. # Usage: bash kubectl-apply.sh. ... <看更多>
kubectl apply 在 kubectl apply - Kubernetes 的推薦與評價
Apply a configuration to a resource by filename or stdin. The resource will be created if it doesn't exist yet. JSON and YAML formats are accepted. kubectl ... ... <看更多>