建模Kubernetes自定義類型資源

我在Kubernetes生態系統之上構建了一種有意義的PaaS服務。建模Kubernetes自定義類型資源

我有一個SSHService和SSHUser建模的願望，我會無論是註冊新的類型擴展Kubernetes API服務器/通過ThirdPartyResource http://kubernetes.io/v1.1/docs/design/extending-api.html

我以前的模式（看起來很簡單），或使用自定義的資源建立了自己的非kubernetes基礎設施上的API服務器。我模仿它的方式是有些下面，讓管理員將通過寧靜的行動做：

1）創建SSH服務 2）創建SSH用戶 3）添加用戶到SSH服務

第三行動將運行在SSH服務資源上，它將檢查Universe以確保在將Universe添加到其允許的用戶數組屬性之前，具有名稱ref的SSH用戶存在於Universe中。

在Kubernetes中，我不認爲支持交叉資源事務，或者有意查看其他事物是如何建模的**（例如，我可以創建帶有祕密卷的吊艙，指的是不存在的祕密名稱，這是公認）。

所以在世界Kubernetes我打算 1）創建SSH服務.Spec.AllowedGroups [STR] 2）創建與.Spec.BelongToGroups SSH用戶[STR]其中基團僅僅是組名稱的數組作爲字符串

一個kubernetes客戶端將觀看在套改更新回API祕密卷的passwd /陰影的變化ssh服務，SSH用戶（後configmap量）在SSH容器

是使用這是一種理想的方法來模擬自定義資源？

來源

2016-03-02 Mâtt Frëëman

第一反應是，如果您已經擁有自己的API服務器，並且工作正常，則不需要以kubernetes風格重寫API。我只是試着重複使用的東西。

如果你想重寫，這裏是我的想法：

如果您需要大量SSHServices的，你需要大量的人使用你的API來創建SSHServices，然後是有意義的代表的參數ssh服務作爲ThirdParty資源。

但是，如果您只有一個或幾個SSHServices，並且您不經常更新它，那麼我不會爲它創建ThirdParty資源。我只需編寫一個運行SSH服務的RC，然後以您選擇的格式安裝一個包含配置文件的祕密（以後的configMap）卷。配置文件將包含AllowedGroups。一旦你擁有配置映射的v1.2，就像在一個月內一樣，你將能夠通過在apiserver上發佈一個新的配置映射來更新配置，而不需要重啓SSH服務。（它應該看配置文件的變化）。基本上，您可以將configMap視爲ThirdParty資源的更簡單版本。

就SSHUsers而言，您可以使用ThirdParty資源並讓SSH控制器監視SSHUsers端點以進行更改。（想想看，我不確定你是如何看第三方資源的。）

或者你可能只想把BelongToGroups信息放到同一個ConfigMap中。這給你你想要的「事務性」。這只是意味着對配置的更新是序列化的，並且需要操作員或cron作業來推送配置。也許這不是很糟糕？

來源

2016-03-02 22:26:48

感謝您提供一些清晰的內容，我還想知道您是否知道Kubernetes api服務器的API設計（resourceVersion，元數據，規格/狀態，標籤/註釋，手錶界面，條件..）的靈感是什麼似乎是一種可能在使用方面更不可知（不僅僅是容器管理）的模型 –

同意K8s APi可能是其他json API的模型。查看http://kubernetes.github.io/docs/api/和https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/devel/api-conventions.md瞭解詳細說明。 –

建模Kubernetes自定義類型資源

回答

相關問題