譯?者 | 李睿

審校 | 孫淑娟

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

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

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

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

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

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

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

Kubernetes提供幫助

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

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

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

Kubernetes作為一個統(tǒng)一的接口，為人們帶來了一個通用的API，它內(nèi)置了身份驗證、速率限制和審計等功能。而且，該API已經(jīng)成為云原生工作負(fù)載管理的標(biāo)準(zhǔn)，并且憑借其原生可擴(kuò)展性，對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á)成了第一個共識。

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

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

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

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

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

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

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

現(xiàn)在需要解決的最重要的問題是此類擴(kuò)展的用戶體驗。這不僅限于改進(jìn)API的驗證和默認(rèn)值，還涉及擴(kuò)展的發(fā)現(xiàn)及其文檔級別。此外，一旦使用這些標(biāo)準(zhǔn)中的一些更接近生產(chǎn)，作為一個社區(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)集成。  

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

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

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