我正在Kubernetes生态系统之上构建一个自以为是的PaaS服务。
我希望为SSHService和SSHUser建模，我会通过注册新的类型/模式（看起来非常简单）或通过ThirdPartyResource http://kubernetes.io/v1.1/docs/design/extending-api.html使用自定义资源来扩展Kubernetes api服务器
我之前在非kubernetes基础架构上构建了自己的API服务器。我建模的方式有点如下，所以管理员可以通过宁静的行动来做：
1）创建SSH服务 2）创建SSh用户 3）将用户添加到SSH服务
第三个操作将在SSH服务资源上运行，该资源将检查Universe以确保在将Universe添加到其允许的用户数组属性之前，Universe中存在名为ref的SSH用户。
在Kubernetes中，我不认为支持跨资源交易，或者故意查看其他事物是如何建模的**（例如，我可以使用秘密名称创建一个不存在的秘密名称的pod，这个被接受了。）
所以在Kubernetes世界，我打算 1）使用.Spec.AllowedGroups创建SSh服务[str] 2）使用.Spec.BelongToGroups [str]创建SSH用户，其中groups只是一个组名称数组作为字符串
kubernetes客户端将监视对ssh服务和ssh用户的更改，其中集合将更新更新回API，以便在SSH容器中使用passwd / shadow的密钥卷（稍后的configmap卷）
这是一种模拟自定义资源的理智方法吗？
答案 0 :(得分：1)
第一反应是，如果您已经拥有自己的API服务器，并且它有效，则无需以kubernetes样式重写API。我只是尝试重复使用有效的东西。
如果你想改写，我的想法是这样的：
如果您需要大量SSH服务，并且需要很多人使用您的API来创建SSH服务，那么将ssh服务的参数表示为ThirdParty资源是有意义的。
但是如果你只有一个或几个SSH服务，并且你不经常更新它，那么我就不会为它创建一个ThirdParty资源。我只想编写一个运行SSH服务的RC，安装一个包含配置文件的秘密（以后的configMap）卷，格式为您选择的格式。配置文件将包含AllowedGroups。一旦你有v1.2配置映射，就像一个月一样，你将能够通过将新配置映射到apiserver来更新配置，而无需重启SSH服务。 （它应该观察配置文件的更改）。基本上，您可以将configMap视为ThirdParty资源的更简单版本。
就SSHUser而言，您可以使用ThirdParty资源并让SSH控制器监视SSHUsers端点以进行更改。 （想想看，我不确定你是如何看第三方资源的。）
或者您可能只想将BelongToGroups信息放入同一个ConfigMap中。这为您提供了所需的“交易性”。它只是意味着对配置的更新是序列化的，并且需要操作员或cron作业来推送配置。也许那不是那么糟糕？