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