如果你這樣使用 kubectl，可能就錯了！

和許多人一樣，我使用 kubernetes CLI(又名 kubectl) 管理我的第一個集羣。通過直接應用 yaml 文件部署了一些 “對象”，如 Deployment、secret、configmaps 和 services，例如:

kubectl config use-context cluster1
kubectl apply -f deployment1.yaml -n namespace
kubectl apply -f secret1.yaml -n namespace

經過多次試驗和調整，我終於完善了本地應用的 yaml 文件，每次執行這些命令都可以實現應用程序的部署。

然後，我又添加了兩個其他的集羣分別是預發和生產環境，這樣要執行的命令就變成原來的三倍。

然後，我又添加了另一個應用程序，文件和命令的數量再次翻倍。

當需要升級應用程序時，每次升級我都必須修改所有文件，重新執行所有命令。

當然，人工操作就會犯錯。其中許多問題導致應用和 / 或某些功能和 / 或用戶崩潰。所以，爲了排除壞的應用程序，我需要學習和執行一大堆其他的 kubectl 命令，例如:

kubectl config use-context cluster
kubectl apply -f deployment1.yaml -n mynamespace
kubectl apply -f service1.yaml -n mynamespace

我在想肯定有更好的辦法。如何實現自動化，並消除人爲錯誤和開銷？作爲一名工程師，我過去寫過一些定位腳本，我認真地考慮編寫一組腳本來自動化這些過程，這樣我 (以及未來的團隊) 就不會再犯一些可以避免的錯誤。畢竟，腳本把大量命令行參數推送給 kubeclt 執行會很容易。我也考慮過 helm 和 Kustomize，但這並不能解決問題，因爲它仍然需要推送很多更新 chart 的工作。

有一天，我讀到一篇關於 ArgoCD 的文章，重點是 “推” 和“拉”配置之間的區別，這讓我大喫一驚。我不應該 “推送” 命令、腳本或 chart 去更新應用。這些方法總是需要在每個集羣、每個應用、所有監控和每次升級中進行人工操作。

相反，我應該從單一的代碼或配置倉庫中 “拉” 部署文件到 k8 集羣。換句話說，在集羣中創建一個代理，該代理監聽配置修改(應用程序的期望狀態)，並自動地執行更新命令。機器人比人類更擅長下達命令。使用 pull 方法，我的所有應用程序和所有集羣的行爲都將完全符合我的預期，不會再有人爲錯誤。

當每天或每週升級時，我只需要在一個地方升級所需的狀態，所有集羣中的相關應用程序就會自動更新。這就是我一直在尋找的自動化工具。隨着我的閱讀，並最終成爲 ArgoCD 的用戶，我意識到 ArgoCD 是 K8s 應用程序的完美機器人。ArgoCD 將這種方法更進一步，將應用部署文件放在源代碼管理工具上，所以有一個 “撤消” 按鈕，可以審計應用程序和集羣的完整更改歷史。與使用 kubectl 的人工執行方式相比，GitOps 是一個更加健壯、高效和可擴展的模型。

所以，如果你使用 CLI 將文件、命令或 chart“推送” 到 Kubernetes，那麼你可能搞錯了。從 kubectl 命令開始是可以的，但是關鍵任務的應用程序應該用 GitOps 來管理。

ArgoCD 作爲一個應用持續發佈工具非常好用，該工具現在就可以爲你所用。所以，加入 GitOps 革命吧。

更多閱讀

猜你喜歡