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

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

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

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

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

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

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

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

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

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

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

我同意這種說法，因?yàn)檫@又是一次證明，重要的不是你選擇使用的技術(shù)，而是你如何將當(dāng)前的流程和人員整合到面向應(yīng)用容器化的這種新的技術(shù)轉(zhuǎn)變中。