我正在 Kubernetes 生态系统之上构建一个固执己见的类似 PaaS 的服务。
我渴望对 SSHSer 和 SSHUser进行建模，我将通过注册新类型/模式（看起来很简单）或通过第三方资源 http://kubernetes.io/v1.1/docs/design/extending-api.html 使用自定义资源来扩展 Kubernetes api 服务器
我之前在非 kubernetes 基础设施上构建了自己的 API 服务器。我的建模方式如下，因此管理员将通过休息操作来执行：
1） 创建 SSH 服务2） 创建 SSh 用户3） 将用户添加到 SSH 服务
第三个操作将在 SSH 服务资源上运行，该资源将检查域以确保在将名称为 ref 的 SSH 用户添加到其允许的用户数组属性之前存在于域中。
在 Kubernetes 中，我认为不支持跨资源事务，或者有意查看其他事物的建模方式**（例如，我可以创建一个带有秘密卷的 pod，引用不存在的秘密名称，这被接受）。
所以在 Kubernetes 的世界里，我打算1） 使用 创建 SSh 服务。Spec.AllowedGroups [str]2） 使用 创建 SSH 用户。Spec.BelongToGroups [str] 其中组只是作为字符串的组名数组
kubernetes 客户端将监视对 ssh 服务和 ssh 用户的更改，其中集合更改更新回 API 一个秘密卷（后来的配置映射卷），用于在 SSH 容器中使用的 passwd/shadow
这是对自定义资源进行建模的理智方法吗？
第一反应是，如果你已经有了自己的 API 服务器，并且它可以工作，那么就没有必要以 kubernetes 风格重写 API。 我只是尝试重用有效的东西。
如果你确实想重写，以下是我的想法：
如果您需要大量的 SSH 服务，并且需要很多人使用您的 API 来创建 SSH 服务，那么将 ssh 服务的参数表示为第三方资源是有意义的。
但是，如果您只有 1 个或几个 SSH 服务，并且您不经常更新它，那么我不会为它创建第三方资源。 我只会编写一个运行 SSH 服务 Pod 的 RC，以您选择的格式挂载一个包含配置文件的秘密（后来的 configMap）卷。 配置文件将包含允许的组。 一旦你有了带有配置映射的 v1.2，就像一个月后一样，你将能够通过将新的配置映射发布到 apiserver 来更新配置，而无需重新启动 SSH 服务。 （它应该监视配置文件的更改）。 基本上，您可以将 configMap 视为第三方资源的简化版本。
就 SSHUsers 而言，您可以使用第三方资源并让 SSH 控制器监视 SSHUsers 端点的更改。 （想想看，我不确定你是如何观看第三方资源的。
或者，也许您只想将BelongToGroups信息放入同一个ConfigMap中。 这为您提供了所需的"事务性"。 这只是意味着对配置的更新是序列化的，并且需要操作员或 cron 作业来推送配置。 也许这还不错？