譯?者 | 李睿

審校 | 孫淑娟

基礎設施即代碼：從哪里來  

近年來，隨著Docker的出現和容器的日益普及，基礎設施即代碼（IaC）的概念得到了擴展。基礎設施即代碼（IaC）最初是用于連接虛擬機、網絡和存儲等具體基礎設施的API，然后逐漸擴展到包括操作系統和Kubernetes以及它們的配置和強化策略。當查看諸如Terraform之類的基礎設施即代碼（IaC）工具時，它們甚至支持工作負載的部署。  

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

平臺即代碼：前進的方向

下一步是將這一概念及其優勢擴展到希望為開發人員提供的平臺上。目標是構建類似于平臺即服務（PaaS）的系統，抽象出基礎設施并使工程師能夠專注于他們的代碼。在理想情況下，PaaS系統會在無需打擾開發人員的情況下獲得自助服務、標準化和共享常見最佳實踐以及某種類型的安全性和實施合規性等好處。  

然而，典型的PaaS系統有一些人們應該避免的常見陷阱。  

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

Kubernetes提供幫助

“Kubernetes是一個構建平臺的平臺。”如果人們熟悉或了解Kelsey Hightower或JoeBeda等Kubernetes思想領袖，可能已經聽說過他們的這一聲明。  

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

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

Kubernetes作為一個統一的接口，為人們帶來了一個通用的API，它內置了身份驗證、速率限制和審計等功能。而且，該API已經成為云原生工作負載管理的標準，并且憑借其原生可擴展性，對KubernetesAPI的熟悉轉化為API擴展。由于Kubernetes在近幾年取得的成功和變得流行，從持續集成（CI）/持續交付（CD）上的傳統IaC到現代GitOps方法的工具得到了廣泛的支持。  

最后，許多企業已經為許多用例擴展了API，包括在Kubernetes內部就定義集群、應用程序和基礎設施服務的通用抽象達成了第一個共識。

Kubernetes平臺的構建塊——超越容器編排  

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

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

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

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

未來的愿景和挑戰  

如今仍處于Kubernetes擴展和平臺即代碼的早期階段。大多數標準化工作也處于早期階段，但正在迅速朝著達成共識和生產就緒的方向發展。  

現在需要解決的最重要的問題是此類擴展的用戶體驗。這不僅限于改進API的驗證和默認值，還涉及擴展的發現及其文檔級別。此外，一旦使用這些標準中的一些更接近生產，作為一個社區需要注意保持API的可組合性，并在不緊密耦合系統的情況下促進交互。最后，具有許多Kubernetes擴展的復雜系統中的可調試性和可追溯性仍然是可以改進的。  

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

總之，對未來的預測是，Kubernetes將成為標準的云原生管理接口。它是一個統一社區的共識API。當然，用戶仍然可以自由使用其選擇的工具，但統一的開源界面保證用戶不會被鎖定。  

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

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