Kubernetes 持續(xù)交付工具的簡單性，是優(yōu)點還是缺點？

譯自How Far Can You Go with Argo?，作者 Joanna Wyganowska 是 Octopus Deploy 的營銷副總裁。在她的角色中，她有幸與 DevOps 從業(yè)者討論持續(xù)交付的最佳實踐，以及從他們的 DevOps 之旅中吸取的教訓。Joanna 是一位精益大師，并且......

從自芝加哥的 ArgoCon 返回后，我開始思考 Argo，尤其是 Argo CD 的未來。有兩大陣營: 忠實的 Argo 粉絲致力于開源社區(qū)，以及更傾向于繼續(xù)使用他們當前的部署工具并擴展其用于 Kubernetes 部署的人。這兩種方法都有其優(yōu)點。

使用 Argo CD進行 Kubernetes 持續(xù)交付的組織贊揚它的簡單性。VMware的技術負責人Navneet Verma表示，Argo CD 提供了直觀的圖形用戶界面(GUI)，由強大的命令行界面(CLI)和 API 支持。他還重視其處理多個集群的單一安裝的能力。

太簡單了？還是過于簡單？

然而，許多人發(fā)現它過于簡單。DeepOpinion 的首席后端開發(fā)者Diogo Baeder說，Argo CD 缺乏允許開發(fā)人員部署特定版本的功能。相反，它依賴于應用程序規(guī)范中定義的內容。Codefresh 等公司看到他們構建在 Argo 之上的商業(yè)解決方案采用率增長的原因，是對已證實的部署模式的需求。

Octopus Deploy 的高級產品經理Nikita Dergilev也有同感。在他看來，Argo CD 非常適合集群引導。它易于配置，首次部署會花費一點時間。然而，當團隊需要跨許多環(huán)境或集群(如云區(qū)域)部署應用程序時，他發(fā)現使用 Argo CD 存在問題。痛點來自于需要管理許多 Git 倉庫、分支或文件夾，并通過自制腳本或手動編排推進的需求。它很快就會變成一團糟。

另一個潛在問題是可擴展性。Dergilev 說，如果組織擁有許多集群、應用程序和團隊，他們實際上有兩種選擇。第一個是集中化的 Argo 實例，這可能會變慢并引入權限和網絡流量的問題。第二個是每個集群一個實例，這可能難以管理，并且無法提供單片玻璃來觀察。他建議利用現有 DevOps 工具的功能來部署軟件。例如，Octopus Deploy 提供了開箱即用的 Kubernetes 部署功能，包括環(huán)境推進和控制面板，可在所有項目和環(huán)境中查看 Kubernetes 部署。

圍繞使用 Argo 的討論也在戰(zhàn)略層面上進行，重點關注 Argo 的配置方法。這很好地體現在美國家庭保險公司的首席工程師Justin Pullen身上。他說，盡管他是聲明式配置的忠實粉絲，但他看到的任何聲明性項目的一個缺點是初始設置后的代碼管理。

要對所有代碼庫進行任何廣泛的更改，就需要越來越多的人手參與。Pullen 指出，這不是 Argo 或Kubernetes 部署聲明所獨有的。這是任何基于聲明式語法的系統(tǒng)都會遇到的問題。

那么，如何快速在大規(guī)模上管理強制性更改？正如 Pullen 總結的那樣: 答案尚不明確，但無論選擇哪種解決方案，在大型企業(yè)中計劃和執(zhí)行到 Kubernetes 的部署時，都需要進行這方面的討論。

我同意這種說法，因為這又是一次證明，重要的不是你選擇使用的技術，而是你如何將當前的流程和人員整合到面向應用容器化的這種新的技術轉變中。