本文講的是<b>Kubernetes服務目錄的設計</b>【編者的話】OpenShift 3.6新版本包括新的服務目錄和服務中介技術預演版。它們是基于Kubernetes的孵化項目Kubernetes Service Catalog project。服務目錄通過Open Service Broker API內建服務中介，由服務中介管理服務的建立和管理；這篇文章将深入介紹服務目錄的設計。
<a href="http://dockone.io/article/2526">【3 天燒腦式基于Docker的CI/CD實戰訓練營 | 北京站】本次教育訓練圍繞基于Docker的CI/CD實戰展開，具體内容包括：持續內建與持續傳遞（CI/CD）概覽；持續內建系統介紹；用戶端與服務端的 CI/CD 實踐；開發流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及實踐經驗分享等。</a>
服務目錄是基于Kubernetes的Open Service Broker API實作。 它包括如下功能：
服務中介注冊到Kubernetes上；
服務中介指定一組服務（或這些服務的變體），提供給Kubernetes使用者；
Kubernetes使用者可以發現可用的服務；
Kubernetes使用者可以請求新的服務執行個體；
Kubernetes使用者可以連結服務執行個體到一組Pods上；
這種底層機制允許在Kubernetes中運作的應用程式與它們使用的服務之間松耦合。 服務中介是一個黑盒實體，可以運作在Kubernetes外。 服務中介允許應用專注于自己的業務邏輯，将服務的管理交給服務中介。
應用（Application）：服務目錄中的服務與Kubernetes中的“服務”是不同的。為避免混淆，我們使用“應用”表示Kubernetes的服務執行個體；
綁定或服務綁定（Binding）：服務執行個體和應用之間的連結。它表示應用引用和使用特定服務執行個體的意圖；
中介或服務中介（Broker）：一個實體，用于管理一組或多個服務，可以通過網絡端點通路服務中介；
憑證（Credentials）：應用與服務執行個體通信所需的資訊；
執行個體或服務執行個體（Instance）：服務的實作稱為服務執行個體；
服務類或服務（Service Class）：服務中介提供的一種服務類型；
計劃或服務計劃（Plan）：服務類型的變體。例如，服務可以暴露一組計劃，它們提供不同程度的服務品質（QoS）；
服務目錄的設計如下圖所示：
請注意，該項目的目前狀态并不完全支援設計中所述的所有内容，但我們從目标開始，然後指出目前項目狀态，通過[DIFF]标記不同。
作為服務目錄的核心，與Kubernetes核心一樣，它是一個API伺服器和一個控制器。 API伺服器是用于存儲元件HTTP（REST）RESTful的前端。系統的使用者及系統的其他元件與API伺服器進行互動，以便在服務目錄資源模型上執行CRUD類型的操作。與Kubernetes本身一樣，kubectl指令行工具可用于與服務目錄資源模型進行互動。
[DIFF]到目前為止，API伺服器隻能使用etcd作為其持久存儲。在不久的将來，API伺服器的rest.storage接口将添加對TPRs的支援。
服務目錄資源模型在pkg/apis/servicecatalog/types.go的檔案中定義，模型的初始（目前）版本在pkg/apis/servicecatalog/v1alpha1/中。到目前為止，隻有一個版本的模型，但随着時間的推移，将會建立其他版本，每個版本都将有自己的pkg/apis/servicecatalog /的子目錄中。
控制器是服務目錄的大腦。它監視資源模型（通過API伺服器上watches接口），并根據其檢測到的更改采取适當的操作。
要了解服務目錄資源模型，最好通過一個典型的工作流程：
在應用使用服務之前，服務中介首先向Kubernetes平台注冊。服務中介管理服務，我們首先通過建立Broker執行個體來注冊服務中介：
broker.yaml内容如下：
建立中介資源後，服務目錄控制器将收到資料存儲區添加資源的事件。然後，控制器将查詢服務中介（指定的URL）以擷取可用服務清單。然後，每個服務都将建立一個相應的服務資源：
請注意，每個服務可以有一個或多個與之相關聯的計劃。
使用者可以查詢可用服務清單：
在使用服務之前，必須建立一個新的執行個體。建立一個新的Instance資源：
instance.yaml内容如下：
在執行個體資源内可以指定使用的計劃。允許使用者指定他們想使用的服務的變體 - 可能是基于QoS的服務類型變體。
一旦Instance資源被建立，控制器會與指定的服務中介協商來建立一個所需服務的新的執行個體。
對于同步操作，向服務中介送出請求，并且在成功完成請求（200 OK）後，服務執行個體可以被應用使用。
一些服務中介支援異步方式。當控制器向服務中介發出create/update/deprovision請求時，服務中介以202 ACCEPTED響應，并提供GET請求端點：GET /v2/service_instances/<service_instance_id>/last_operation，控制器可以輪詢請求狀态。
服務中介為每個last_operation請求發送傳回一個last_operation字段。輪詢請求的狀态為“in_progress”時，控制器将繼續輪詢。控制器會考慮輪詢請求的最大逾時，并将停止輪詢并将建立标記為失敗。
雖然服務執行個體正在進行異步操作，但控制器必須確定沒有其他操作（提供，取消，更新，綁定，取消綁定）。
在使用服務執行個體之前，必須将其綁定到應用程式。這意味着應用和服務執行個體之間的連結或使用意圖必須建立。建立一個新的Binding資源：
binding.yaml内容如下所示：
控制器，接到新的Binding資源通知後，将與服務中介通信，為指定的服務執行個體建立一個新的綁定。從服務中介傳回的Binding對象中有一組憑據。這些憑據包含應用程式與服務執行個體通信所需的所有資訊。例如，它可能包括以下内容：
服務執行個體的URL
使用者ID和密碼來通路服務執行個體
OSB API規範不要求在憑據中顯示什麼屬性，是以需要應用了解傳回的指定資料以及如何正确使用它們。這通常通過閱讀服務的文檔來完成。
憑證不會存儲在服務目錄的資料存儲中。相反，它們将作為秘密存儲在Kubenetes中，并且将Secret的引用儲存在Binding資源中。如果未指定Binding的Spec.SecretName，則控制器将使用Binding Name屬性作為Secret的名稱。
綁定不需要與服務執行個體位于相同的Kubenetes命名空間中。允許跨應用和命名空間共享服務執行個體。
除了Secret之外，控制器還将在Kubernetes中建立一個Pod注入政策（PIP）資源。有關更多資訊，請參閱PIP提案，但簡而言之，PIP定義了在建立Pod時如何修改Pod的規範以包含其他卷和環境變量。特别地，服務目錄将使用PIPs來允許應用程式所有者訓示Secret應該如何提供給其Pods。例如，他們可以定義一個PIP來訓示Secret安裝到Pod中。或者Secret的名稱/值應該被暴露為環境變量。
PIP将使用标簽選擇器來訓示哪些Pod将被修改。例如：
定義一個PIP，添加一個名為DB_PORT的環境變量，值為6379，所有具有Role标簽的Pods都具有此前端值。
最終，OSB API規範将希望有關于憑證的額外中繼資料，以指出哪些字段被認為是“Secret”，哪些不是。當該支援可用時，期望将非Secret資訊放入ConfigMap而取代Secret。
一旦Secret提供給應用Pods中，那麼應用代碼就可以使用該資訊與服務執行個體進行通信。
與Kubernetes中的資源一樣，可以通過對資源執行HTTP DELETE來删除服務目錄資源。 但是，請注意，有相關的綁定存在時，服務執行個體不能被删除。 換句話說，在删除服務執行個體之前，必須先删除其所有綁定。 删除具有綁定的執行個體将失敗并産生錯誤。
删除綁定也将自動删除與之相關聯的Secret或ConfigMaps。
上述各節描述了服務目錄的目前設計。 但是，有些尚未到位，代碼不一定與之對齊。 目前的設計實際上更像是這樣：
不同的方面：
API伺服器隻能使用etcd作為其持久存儲。
API伺服器沒有連接配接到控制器，這意味着它并沒有被實際作為運作系統的一部分。 隻是通過與API伺服器通信完成資源的建立和存儲。
可以使用Kubernetes的API伺服器建立服務目錄資源的TPRs版本是目前系統的工作方式。 然後，控制器将與Kubernetes中API伺服器進行通信，并監視服務目錄資源的TPRs版本，采取一切适當的措施。
===============================================================
譯者介紹：範彬，從事微服務、Docker和Kubernetes容器技術等方面的工作。可以關注譯者的微信公衆号：範範米飯。
原文釋出時間為：2017-08-15
本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。
原文标題：Kubernetes服務目錄的設計