helm部署doris这里可以优化下在Operator里面完成fe、be的注册吗？

[anthony-yau]

当前fe、be节点的注册都是使用shell脚本来完成的，是否可以优化下使用operator来完成，不放到启动脚本里面更好些？到时缩容的时候也在operator进行判断完成缩容逻辑？

[intelligentfu]

no, operator 的定位在调谐资源，这种业务逻辑嵌入到 operator 会将调谐和业务处理耦合，代码逻辑就会不清晰，处理边界将会被模糊掉。放到启动脚本里最合适，因为就是一锤子买卖一次操作。调谐是一个不断循环的逻辑，调谐的本质是处理下放的资源，检测底层的调谐是否达到预期。两种逻辑完全不同，糅合不是一种很好的架构思维。 试举一例危险case：如果operator因为某些原因不能正常工作，很大概率也会影响到doris集群，耦合性这么大不符合架构设计的原则。 缩容，目前的设计方案是只让 operator 处理资源变更，这也符合调谐的定位，其他逻辑我们暂时还不能透漏详细的设计方案。可以等待我们的设计文档，我们预期下个月会实现缩容能力。

[anthony-yau]

no, operator 的定位在调谐资源，这种业务逻辑嵌入到 operator 会将调谐和业务处理耦合，代码逻辑就会不清晰，处理边界将会被模糊掉。放到启动脚本里最合适，因为就是一锤子买卖一次操作。调谐是一个不断循环的逻辑，调谐的本质是处理下放的资源，检测底层的调谐是否达到预期。两种逻辑完全不同，糅合不是一种很好的架构思维。 试举一例危险case：如果operator因为某些原因不能正常工作，很大概率也会影响到doris集群，耦合性这么大不符合架构设计的原则。 缩容，目前的设计方案是只让 operator 处理资源变更，这也符合调谐的定位，其他逻辑我们暂时还不能透漏详细的设计方案。可以等待我们的设计文档，我们预期下个月会实现缩容能力。

好的，那期待方案哈。

[anthony-yau]

但是据了解，mongodb、mysql等数据库类的operator是会来完成replicate、集群的架构维护逻辑的。

[intelligentfu]

这个我不了解，我可以去看看。你可以帮忙分享一下相关的设计文章我们学习一下，但我理解他们应该也不会在调谐里嵌入集群搭建的逻辑，比如节点注册能力。

[intelligentfu]

但是据了解，mongodb、mysql等数据库类的operator是会来完成replicate、集群的架构维护逻辑的。

Hi, 我看了一下 MongoDB 有关 kubernetes 的文档，我理解出以下事实，mongodb operator 主要是负责资源的调度和校验，并没有涉及业务处理的事情，比如注册，mongodb 实例的终态检查。所有的这一切都是放到 agent 服务来做，agent 服务应该没开源我没找到对应的代码，operator 中有关 agent 的代码是从 pod 上获取信息，并没有检查 mongodb 的逻辑。以下，是我主要参考的资料. https://www.mongodb.com/docs/cloud-manager/reference/api/agents/ https://www.mongodb.com/docs/kubernetes-operator/current/tutorial/mdb-resources-arch/#std-label-mdb-resources-arch https://www.mongodb.com/docs/kubernetes-operator/current/tutorial/plan-k8s-op-architecture/ 限于我知识的有限，我依旧没有理解你所说 mongodb operator 维护架构的逻辑指的是啥，在我的理解中应该就是指的节点注册，节点的自动摘除这些。 如果你有任何关于 mongodb operator 在调谐流程中处理架构维护的文档和代码，非常感谢你分享促进我们的进度。

[anthony-yau]

但是据了解，mongodb、mysql等数据库类的operator是会来完成replicate、集群的架构维护逻辑的。

Hi, 我看了一下 MongoDB 有关 kubernetes 的文档，我理解出以下事实，mongodb operator 主要是负责资源的调度和校验，并没有涉及业务处理的事情，比如注册，mongodb 实例的终态检查。所有的这一切都是放到 agent 服务来做，agent 服务应该没开源我没找到对应的代码，operator 中有关 agent 的代码是从 pod 上获取信息，并没有检查 mongodb 的逻辑。以下，是我主要参考的资料. https://www.mongodb.com/docs/cloud-manager/reference/api/agents/ https://www.mongodb.com/docs/kubernetes-operator/current/tutorial/mdb-resources-arch/#std-label-mdb-resources-arch https://www.mongodb.com/docs/kubernetes-operator/current/tutorial/plan-k8s-op-architecture/ 限于我知识的有限，我依旧没有理解你所说 mongodb operator 维护架构的逻辑指的是啥，在我的理解中应该就是指的节点注册，节点的自动摘除这些。 如果你有任何关于 mongodb operator 在调谐流程中处理架构维护的文档和代码，非常感谢你分享促进我们的进度。

---

抱歉，辛苦您进行了调研。

整理下相关诉求： 1、将FE、BE节点的ALTER SYSTEM ADD FOLLOWER/BACKEND操作集成在operator中(之前描述是架构，或者是说doris集群拓扑的维护？)；同时还能支持备份元数据等操作？ 2、通过yaml文件的定义来满足集群的常规管理等操作； 3、对需要构建自定义镜像的用户来说，只需要替换镜像中的doris版本包文件，不需要将operator项目的自定义的脚本启动文件打包到镜像了，这样可以降低Operator和doris的耦合性？

比如 mysql operator这里： 支持yaml定义备份操作：https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-backups.html 通过sidecar来维护mysql mgr集群的拓扑：https://github.com/mysql/mysql-operator/blob/4a80d27486c36a1ba1262d79cddbb99be21e52ba/mysqloperator/sidecar_main.py#L19

mongodb operator这里： 通过Initcontainer和agent来实现(如你所说)： https://github.com/mongodb/mongodb-kubernetes-operator/blob/a87bda54cad0d635dbec1883f24579aac11c364f/docs/architecture.md

[intelligentfu]

第一点和第三点是一个事情，主要是说镜像的通用性，无论谁怎么打image都能够部署，这个点是不对的。不能随意打镜像，这种不确定性更高。举一例：doris现在已经优化到操作系统以及cpu指令集层次，很多基础镜像是不能用的，我们自己的基础镜像都需要经过相关验证，所以构建自定义镜像本身就不合理。 另外，耦合性的事情，把alter 的命令放到operaotr 反而增加了耦合性，一个服务出现问题可能影响另一个。脚本只是稍微增加了用户打镜像的一个繁琐步骤，但是将operator和doris的耦合性大大降低了，对于耦合性抱歉我不并认可你的理解。 从mongodb来说，我们的脚本相当于mongodb的agent，和mysql 的 sidecar。 这和他们的设计理念是一致，他们都没有把业务管理能力放到operator中。同时我们认为脚本相对于写一个agent来说性价比更大，灵活性更强，只是bash的可读性和学习成本会比较高。 另外你说的打镜像的事情，我们正在考虑将dockerfile以及用的脚本合到doris仓库，用户直接用doris下docker的目录就可直接打镜像，反而比自己制作更方便。

[intelligentfu]

补充上述说的备份的诉求，我们会搞，但是doris比较特别，doris几乎将备份精简到一条命令，在这种情况下在写一个yaml是不合适的，增加一个yaml是为了更简单，如果反而产生了负担这是不合理，非常欢迎你对backup的提醒，我们会尽快提上日程。

[anthony-yau]

第一点和第三点是一个事情，主要是说镜像的通用性，无论谁怎么打image都能够部署，这个点是不对的。不能随意打镜像，这种不确定性更高。举一例：doris现在已经优化到操作系统以及cpu指令集层次，很多基础镜像是不能用的，我们自己的基础镜像都需要经过相关验证，所以构建自定义镜像本身就不合理。 另外，耦合性的事情，把alter 的命令放到operaotr 反而增加了耦合性，一个服务出现问题可能影响另一个。脚本只是稍微增加了用户打镜像的一个繁琐步骤，但是将operator和doris的耦合性大大降低了，对于耦合性抱歉我不并认可你的理解。 从mongodb来说，我们的脚本相当于mongodb的agent，和mysql 的 sidecar。 这和他们的设计理念是一致，他们都没有把业务管理能力放到operator中。同时我们认为脚本相对于写一个agent来说性价比更大，灵活性更强，只是bash的可读性和学习成本会比较高。 另外你说的打镜像的事情，我们正在考虑将dockerfile以及用的脚本合到doris仓库，用户直接用doris下docker的目录就可直接打镜像，反而比自己制作更方便。

能将脚本合并到doris仓库中也挺不错哈；另一个现在镜像的版本、使用operator部署doris的charts版本能否跟进doris的发布版本进度？

[intelligentfu]

operator 部署doris的helm chart版本不会和doris的发布版本对齐，helm charts会跟operator版本发布对齐。