譯?者 | 李睿

審校 | 孫淑娟

基礎(chǔ)設(shè)施即代碼：從哪里來(lái)  

近年來(lái)，隨著Docker的出現(xiàn)和容器的日益普及，基礎(chǔ)設(shè)施即代碼（IaC）的概念得到了擴(kuò)展?；A(chǔ)設(shè)施即代碼（IaC）最初是用于連接虛擬機(jī)、網(wǎng)絡(luò)和存儲(chǔ)等具體基礎(chǔ)設(shè)施的API，然后逐漸擴(kuò)展到包括操作系統(tǒng)和Kubernetes以及它們的配置和強(qiáng)化策略。當(dāng)查看諸如Terraform之類(lèi)的基礎(chǔ)設(shè)施即代碼（IaC）工具時(shí)，它們甚至支持工作負(fù)載的部署。  

沒(méi)有改變的是人們最初對(duì)“即代碼”感到興奮的原因。這一切都?xì)w結(jié)為軟件開(kāi)發(fā)中使用的熟悉工具（編輯器、CI/CD等）和流程（代碼審查、版本控制等），并將它們應(yīng)用到較低層，同時(shí)使其具有描述性、可重復(fù)性、可共享性，以及同樣重要的自動(dòng)化。

平臺(tái)即代碼：前進(jìn)的方向

下一步是將這一概念及其優(yōu)勢(shì)擴(kuò)展到希望為開(kāi)發(fā)人員提供的平臺(tái)上。目標(biāo)是構(gòu)建類(lèi)似于平臺(tái)即服務(wù)（PaaS）的系統(tǒng)，抽象出基礎(chǔ)設(shè)施并使工程師能夠?qū)Ｗ⒂谒麄兊拇a。在理想情況下，PaaS系統(tǒng)會(huì)在無(wú)需打擾開(kāi)發(fā)人員的情況下獲得自助服務(wù)、標(biāo)準(zhǔn)化和共享常見(jiàn)最佳實(shí)踐以及某種類(lèi)型的安全性和實(shí)施合規(guī)性等好處。  

然而，典型的PaaS系統(tǒng)有一些人們應(yīng)該避免的常見(jiàn)陷阱。  

首先，PaaS的抽象通常會(huì)導(dǎo)致人為限制，并且隨著軟件和開(kāi)發(fā)人員的成長(zhǎng)和成熟，他們會(huì)遇到更多的限制?，F(xiàn)在，對(duì)于傳統(tǒng)或封閉的PaaS系統(tǒng)，這導(dǎo)致異常并被建模為一個(gè)糟糕的解決方案。其次，傳統(tǒng)的PaaS往往伴隨著很高的供應(yīng)商鎖定率。第三，人們要問(wèn)一個(gè)不受歡迎的問(wèn)題：采用一個(gè)平臺(tái)真的就足夠嗎？企業(yè)的數(shù)據(jù)科學(xué)工程師是否需要與其電子商務(wù)團(tuán)隊(duì)采用相同的平臺(tái)？  

Kubernetes提供幫助

“Kubernetes是一個(gè)構(gòu)建平臺(tái)的平臺(tái)?！比绻藗兪煜せ蛄私釱elsey Hightower或JoeBeda等Kubernetes思想領(lǐng)袖，可能已經(jīng)聽(tīng)說(shuō)過(guò)他們的這一聲明。  

同樣，建議Kubernetes實(shí)際上可以成為不僅僅是容器的首選平臺(tái)。事實(shí)上，這可能是最終實(shí)現(xiàn)人們?cè)O(shè)想的平臺(tái)即代碼理想目標(biāo)所需的一件事。  

Kubernetes的好處（例如作為一個(gè)協(xié)調(diào)器和一個(gè)統(tǒng)一的接口）構(gòu)成了這一論點(diǎn)的基礎(chǔ)。Kubernetes作為協(xié)調(diào)器帶來(lái)了有效的協(xié)調(diào)方法，可以將其視為一種更強(qiáng)大的聲明范式。它允許編碼操作知識(shí)，這比將這些知識(shí)構(gòu)建到任何形式的腳本中更具彈性并面向未來(lái)。此外，基于狀態(tài)的存儲(chǔ)是典型IaC工具中存儲(chǔ)和狀態(tài)的典型缺點(diǎn)。  

Kubernetes作為一個(gè)統(tǒng)一的接口，為人們帶來(lái)了一個(gè)通用的API，它內(nèi)置了身份驗(yàn)證、速率限制和審計(jì)等功能。而且，該API已經(jīng)成為云原生工作負(fù)載管理的標(biāo)準(zhǔn)，并且憑借其原生可擴(kuò)展性，對(duì)KubernetesAPI的熟悉轉(zhuǎn)化為API擴(kuò)展。由于Kubernetes在近幾年取得的成功和變得流行，從持續(xù)集成（CI）/持續(xù)交付（CD）上的傳統(tǒng)IaC到現(xiàn)代GitOps方法的工具得到了廣泛的支持。  

最后，許多企業(yè)已經(jīng)為許多用例擴(kuò)展了API，包括在Kubernetes內(nèi)部就定義集群、應(yīng)用程序和基礎(chǔ)設(shè)施服務(wù)的通用抽象達(dá)成了第一個(gè)共識(shí)。

Kubernetes平臺(tái)的構(gòu)建塊——超越容器編排  

首先，有集群API項(xiàng)目，它在1.0中已準(zhǔn)備好生產(chǎn)。對(duì)于初學(xué)者來(lái)說(shuō)，Cluster API是對(duì)共識(shí)API的上游努力，以聲明方式管理任何基礎(chǔ)設(shè)施上Kubernetes集群的生命周期。如果這對(duì)用戶(hù)來(lái)說(shuō)聽(tīng)起來(lái)只是一個(gè)普通的API，請(qǐng)放心，它包括所述API的工作實(shí)現(xiàn)，以便在許多基礎(chǔ)設(shè)施提供商上生成集群，包括超大規(guī)模服務(wù)器以及常見(jiàn)的內(nèi)部部署解決方案。

在檢查了集群之后，接下來(lái)是所述集群中的應(yīng)用程序和工作負(fù)載。對(duì)于功能齊全的云原生平臺(tái)，需要采用一組基本的可觀察性工具、連接工具、構(gòu)成開(kāi)發(fā)人員管道的工具，甚至可能需要一些額外的安全工具或服務(wù)網(wǎng)格?，F(xiàn)在，作為一個(gè)社區(qū)，至少可以認(rèn)同Helm作為一種通用的打包格式。但是，如何將這些Helm圖表實(shí)際部署到集群中，尤其是在多集群環(huán)境中（隨著集群管理變得越來(lái)越容易，這種情況變得越來(lái)越普遍）仍然是尚未達(dá)成共識(shí)的領(lǐng)域。如果企業(yè)已經(jīng)加入了GitOps的潮流，像FluxCD這樣的工具有一些抽象，例如HelmRelease，可以提供幫助。GiantSwarm開(kāi)發(fā)了一個(gè)名為app-operator的開(kāi)源Kubernetes擴(kuò)展，它擴(kuò)展了Helm，添加了多集群功能以及用于配置的多級(jí)覆蓋，從而在將應(yīng)用程序群部署到集群群的用例中減輕了配置管理的痛苦。它還為在部署過(guò)程中包含更多元數(shù)據(jù)（如測(cè)試結(jié)果和兼容性信息）做好了準(zhǔn)備。

人們不能忽視的另一種類(lèi)型的資源是云計(jì)算提供商的服務(wù)。在這里，看到大多數(shù)超大規(guī)模開(kāi)發(fā)者都在開(kāi)發(fā)自己的原生Kubernetes擴(kuò)展，這樣就可以生成他們所謂的第一方資源。第一方資源是諸如直接在Kubernetes中的托管數(shù)據(jù)庫(kù)之類(lèi)，可以從云原生工作負(fù)載連接。另一個(gè)非常有趣的方法是Crossplane，它是一個(gè)開(kāi)源Kubernetes擴(kuò)展，使用戶(hù)能夠通過(guò)同一個(gè)擴(kuò)展組裝來(lái)自多個(gè)供應(yīng)商的服務(wù)，提供一個(gè)抽象層，減少對(duì)實(shí)際提供商的鎖定。  

這些只是基本的擴(kuò)展；該領(lǐng)域有了很大的發(fā)展，越來(lái)越多的項(xiàng)目或者在后臺(tái)使用Kubernetes，或者將其公開(kāi)擴(kuò)展到他們的用例。在構(gòu)建平臺(tái)即代碼的背景下，特別需要提及一些更具體的框架和擴(kuò)展，這些框架和擴(kuò)展涵蓋了專(zhuān)門(mén)但常見(jiàn)的用例，例如Kubeflow項(xiàng)目的MLOps/AI和KubeEdge的邊緣計(jì)算。  

未來(lái)的愿景和挑戰(zhàn)  

如今仍處于Kubernetes擴(kuò)展和平臺(tái)即代碼的早期階段。大多數(shù)標(biāo)準(zhǔn)化工作也處于早期階段，但正在迅速朝著達(dá)成共識(shí)和生產(chǎn)就緒的方向發(fā)展。  

現(xiàn)在需要解決的最重要的問(wèn)題是此類(lèi)擴(kuò)展的用戶(hù)體驗(yàn)。這不僅限于改進(jìn)API的驗(yàn)證和默認(rèn)值，還涉及擴(kuò)展的發(fā)現(xiàn)及其文檔級(jí)別。此外，一旦使用這些標(biāo)準(zhǔn)中的一些更接近生產(chǎn)，作為一個(gè)社區(qū)需要注意保持API的可組合性，并在不緊密耦合系統(tǒng)的情況下促進(jìn)交互。最后，具有許多Kubernetes擴(kuò)展的復(fù)雜系統(tǒng)中的可調(diào)試性和可追溯性仍然是可以改進(jìn)的。  

然而，可以肯定的是，Kubernetes將把自己確立為基礎(chǔ)設(shè)施和云原生技術(shù)的首選接口。此外，還將建立更多標(biāo)準(zhǔn)，更多工具支持并與這些標(biāo)準(zhǔn)集成。  

總之，對(duì)未來(lái)的預(yù)測(cè)是，Kubernetes將成為標(biāo)準(zhǔn)的云原生管理接口。它是一個(gè)統(tǒng)一社區(qū)的共識(shí)API。當(dāng)然，用戶(hù)仍然可以自由使用其選擇的工具，但統(tǒng)一的開(kāi)源界面保證用戶(hù)不會(huì)被鎖定。  

借助Docker和容器，人們創(chuàng)造了一種工作負(fù)載是短暫的情況。使用這樣技術(shù)，不僅可以將這個(gè)概念擴(kuò)展到Kubernetes集群，還可以擴(kuò)展到整個(gè)開(kāi)發(fā)者平臺(tái)，或者提供給用戶(hù)的眾多平臺(tái)。

原文標(biāo)題：??The Future of Platform-as-Code is Kubernetes Extensions???，作者：Puja Abbassi?