雲原生應用程序除了可以部署在Kubernetes中，還可以使用雲託管服務。與Kubernetes的聲明性對象配置模型類似，帶有Service Catalog的Open Service Broker API提供了一種聲明性的方式來描述跨平臺或跨雲的託管服務依賴項。
關鍵要點
- Kubernetes的聲明性對象配置模型是編配器最有趣的功能之一。
- Kubernetes的用戶通常需要在他們的應用程序中使用雲託管服務。
- Service Catalog是一個聲明性的Kubernetes API擴展，用於發現和使用雲託管服務。
- Service Catalog實現了Open Service Broker API，這是一個用於定義服務的標準規範。
- Azure、AWS和GCP都爲自己的服務提供了Service Broker實現。
在過去幾年中，“雲原生基礎設施”和“雲原生應用程序”這兩個術語被廣泛用於描述一種新的軟件範式，這種範式專注於某種基礎設施和應用程序的設計、實現和部署，認爲它們將會使用由公有云或私有云供應商提供的各種技術。這些應用程序通常遵循微服務架構，可以打包成容器，並使用雲供應商提供的一些託管服務，如對象存儲、數據庫或發佈和訂閱隊列。
隨着越來越多的應用程序被打包成容器，需要使用編配器來部署它們。Kubernetes迅速成爲這個雲原生領域中最受歡迎的容器編配器之一。
Kubernetes之所以能夠取得成功，其中一個因素要歸功於它的聲明性對象配置模型。在這個模型中，開發人員或者集羣管理員使用Kubernetes對象描述來描述他們希望在集羣中看到的狀態，Kubernetes將執行所需的操作，以便從當前狀態轉移到預期狀態。這不同於通過向Kubernetes API發送命令動作來告訴它該做什麼。如果Kubernetes出現故障，它會進行“自我治癒”（例如pod崩潰）。Kubernetes將意識到當前狀態與預期狀態不一致，就會執行所需的操作來返回到預期狀態。
不過，部署在Kubernetes上的雲原生應用程序將從使用雲託管服務中受益。有了雲託管服務，開發人員就可以專注於能夠提供業務價值的應用程序領域，並充分利用雲供應商提供的基礎設施組件。在將Kubernetes服務與雲託管服務相結合時，最好要保持相同的聲明性模型，並能夠將完整的應用程序（包括它所依賴的服務）描述爲一組Kubernetes對象。
自啓動Kubernetes項目以來，社區一直在尋找這種跨平臺/跨雲的解決方案。Open Service Broker API和Service Catalog是採用最爲廣泛的解決方案之一。
Open Service Broker API和Service Catalog
Open Service Broker API（OSBAPI）是一種標準規範，雲供應商用它來定義服務並提供訪問和管理這些服務的通用API。OSBAPI最初是爲Cloud Foundry而定義的，但很快由Kubernetes和Openshift項目提供支持，目前由一個項目委員會進行維護，委員會成員來自不同的公司。Service Catalog是一個實現了這個標準的Kubernetes API擴展，目前是一個Kubernetes孵化器項目，目前的API版本爲v1beta1。
Service Catalog API定義了一組類來描述服務提供者及其提供的各種服務。它還定義了一些對象，用於將Kubernetes應用程序連接到不同服務實例。
Service Broker
這個對象定義了一個服務提供者。Service Catalog只定義Kubernetes對象，而不是代理本身的實現，後者取決於服務提供者。對象的定義只需要提供一個與代理進行通信的端點和一些連接到端點URL的授權信息。
Service Class
這個對象抽象出服務的概念。例如，如果Azure代理被部署在集羣中，Azure MySQL就成爲一個Service Class。Service Broker將爲集羣用戶提供一到多個這種類。
Service Plan
公共雲供應商提供的服務通常有幾層。例如，有些層可以包含只配備一個CPU核心和1GB RAM的小型實例（適合用於開發和測試），和配備了四個內核和16GB內存的大實例（適用於生產環境）。每個Service Class都有一個或多個Service Plan。
Service Instance
當一個應用程序需要特定服務（數據庫、對象存儲等）時，它可以通過創建Service Instance對象從Service Broker請求特定的Service Plan實例。然後，Service Catalog控制器將與Service Broker端點通信，以便配置新的服務實例。
Service Binding
這個對象抽象了將應用程序連接到Service Instance的操作。在請求Service Binding時，Service Broker將返回一個新的Service Binding和一個Kubernetes Secret，其中包含了連接信息，應用程序可以使用這些信息連接到所請求的服務。
當前狀態
Service Catalog是一個Kubernetes孵化器項目，目前版本爲0.1.38，API版本爲v1beta1。從這些版本號可以看出這個項目還不穩定，目前由Kubernetes特別興趣小組（SIG）負責管理。項目仍處在開發階段，項目提供的Kubernetes控制器尚未穩定，經常發生崩潰，導致API服務器處於不容易恢復的狀態。
在啓動Service Catalog項目時，Kubernetes還沒有定製資源定義（Custom Resource Definitions，CRD）的概念，這是一種無需編寫自己的API服務器就可以擴展Kubernetes API的方法。相反，Service Catalog實現了聚合的API服務器，需要從頭開始編寫一個API服務器並維護代碼。使用CRD將允許Service Catalog只擁有控制器實現，並從通用API機制和CRD工具的改進中獲益。目前，Service Catalog SIG正在內部討論是否要在API推出穩定版之前將項目遷移到CRD。
Service Catalog獲得了來自Azure、IBM、谷歌和其他組織的支持。除了爲核心項目做出貢獻外，一些主要的公共雲還遵循Open Service Broker API爲其雲服務實現了Service Broker：
- Azure。Azure維護了一個用於Kubernetes的Service Broker，直接作爲服務運行在Kubernetes集羣上。它的維護很活躍，並提供了良好的文檔。它支持多種Azure服務，從數據庫到物聯網事件中心。
- GCP。谷歌爲GCP服務提供了自己的Service Broker實現。這個文檔提供了一組入門示例。
- AWS。Amazon Web Services提供與Kubernetes、Openshift和Cloud Foundry兼容的AWS Service Broker。因爲實現還很新，所以還沒有很詳細的文檔。
未來和替代方案
Open Service Broker API/Service Catalog有可能會成爲一個得到良好支持的標準，用於從Kubernetes部署多雲服務，遵循具有Kubernetes API擴展的聲明性模型。OSBAPI由獨立的項目管理委員會管理，Service Catalog項目由SIG（Kubernetes項目的一部分）管理，並從IBM、Azure、谷歌和其他組織的開發人員那裏獲得支持。儘管如此，自首次發佈以來已經過去了一年半，但尚未得到廣泛採用，所以社區要努力克服這些限制。
Service Catalog目前不適用於真正的多雲解決方案，其中一個原因是連接服務的方式取決於Service Broker和特定服務的實現。例如，綁定Azure MySQL實例時創建的祕鑰schema與綁定Google Cloud SQL實例時創建的祕鑰schema不同。由於這兩種schema不一樣，開發人員將無法讓應用程序連接到通用的Service Catalog MySQL實例（並決定以後使用哪個雲），或者無法輕鬆地從一個雲遷移到另一個雲而無需重寫Kubernetes的manifest。在意識到這些限制後，SIG小組（定義如何在Kubernetes中部署和管理應用程序的小組）提出了一個叫作“Portable Service Definitions”的Kubernetes增強建議（KEP）。這個KEP試圖提供一種方法來定義請求外部服務（例如MySQL數據庫）的常用方法。這個定義對於任意MySQL服務來說都是通用的，不需要考慮是哪個雲提供的服務。有了這個功能，開發人員在開發應用程序時只需要知道它需要外部的MySQL實例，但不需要事先知道是哪些雲會提供這些服務。
另一個問題是Service Catalog API服務器及其控制器的穩定性。如前所述，API服務器及其控制器目前相當不穩定。Service Catalog社區正在討論是否要轉向CRD，這可能會進一步延遲穩定版本的發佈，因爲它幾乎需要完全重寫。然而，從長遠來看，這樣做是有益的，因爲Kubernetes在CRD以及與之相關的工具上投入越來越多。
Service Broker的不同實現（每個都由不同的開發人員開發和管理）也使得開發人員很難在不瞭解每個代理及其不同的實現和文檔的情況下使用它們。Kubernetes以外的一些社區正在創建具有類似目標的項目：提供聲明性API來請求和管理Kubernetes之外的服務。其中的一個項目Crossplane提供了一個通用的API，在不需要考慮服務提供者的情況下向服務發出請求。開發人員可以將他們的應用程序定義爲需要某種服務，而不需要知道是哪個雲提供該服務。在將一個或多個雲供應商部署到集羣中時，這將由集羣管理員來決定。
結論
Kubernetes中的Service Catalog需要克服當前的一些限制才能被廣泛應用於生產環境。與此同時，Kubernetes社區內外也在創建其他項目，作爲Service Catalog和Open Service Broker API的補充或競爭對手。
關於作者
Ara Pulido是一名工程經理，擁有10年多與開源公司一起工作的經驗。目前，她負責管理Bitnami的Kubernetes和站點可靠性工程（SRE）團隊。她是經過認證的Kubernetes管理員。
查看英文原文：https://www.infoq.com/articles/service-catalog-kubernetes