建模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自定义类型资源

回答

相关问题