这个在线体验地址，要手机验证码，直接劝退。

从部署层面来说，都是在解决“如何用起来”，但是现在上 k8s 或者容器化，我觉得不是难在 “Need full container/K8s stack skills ”，因为只是部署一个东西，问一下 chatgpt ，搓一下 yaml ，也能部署起来了。
反而是难在出现问题是如何排查，比如还是以“Need full container/K8s stack skills”为例，如果没有 container 的经验，那部署业务的时候，containerd 一直在启动失败，那如何排查？所以我认为无论上层如何封装，k8s 原始的 kubectl 和 crictl 都是必备的知识。

其次是内置了很多模板（比如 golang 、php 的标准流程），这种方式虽然容易上手，但是毕竟不够灵活，现实中的需求千奇百怪，随着屎山的堆砌，大概率你预设的模板不满足业务要求，从而退化成原始的 kubectl （举个例子，比如我需要远程 ceph 存储，或者对接我自家的 csi ，我应该如何操作？）；同时这些模板也引入了新的学习成本。

我觉得你上述提到的“Rainbond 的 “一站式” 是否不够聚焦”很对，可以看到其他“热门”产品，很少出现这种固定模式的大一统产品（也许是我用得少了，我即使在 homelab 里面玩玩，也是自己搓 yaml 、自己配 Prometheus 采集）；这种大一统的方案，容易在做方案选择的时候就因为“不清楚你能做什么，但是看上去用你的人不多的样子”而被毙掉。