3同行回答
（1）helm
它是一个命令行工具，帮你同时编排多个K8S资源（比如：Deployment+Service+Ingress这样的经典组合），统一发布到K8S。底层原理就是调用K8S的apiserver，逐个YAML推送给K8S，和我们手动去做没多少差别，所以 其弊端就是缺乏对资源的全生命期监控
（2）CRD，
它就是自定义K8S资源类型。 内置的资源类型包含POD、Deployment、Configmap等等，我们可以通过CRD机制注册新的资源类型到K8S中。
（3）operator
是开发CRD的一个脚手架项目，目的是帮我们实现CRD
（4）operator+helm
operator实现了一套针对Helm的通用CRD controller，我们可以直接把提前写好的helm编排配置随着CRD controller一起打包成docker镜像，然后把它部署到K8S里运行。 此后，我们只要创建CRD对应的资源对象，在YAML的spec里填写helm的模板参数，那么CRD controller就会把值填充到helm模板里，然后按照helm的方式发布到K8S集群里
容器部署模板是容器化平台实现 CI/CD DevOps 的基础，业务场景部署到容器PaaS平台时，最佳实践是通过模板来控制整体部署，包括环境变量的匹配和混搭。大部分业务场景 OpenShift 提供的Template构建足以应付常见业务编排场景。但您提到的复杂产品确实是在混合编排时比较难于标准化的关键实现，有些足够复杂的业务场景会导致模版编排的过于复杂，或导致有些参数无法完全灵活应对各种场景。针对这种情况 Redhat 自去年起就在社区生态环境中大力推动 Operator Framework。 Operator Framework 是针对复杂产品的标准化实现的最佳途径。由于 Operator 的构造中可以混入代码，因此可以保障在初始供应时实现更加复杂的判断与配置等操作。因此现在主流的复杂组件大都提供了 Operator 来强化使用体验，例如 MySQL 就有很多 Operator 可以帮助用户构建复杂的集群关系，以保证 Admin Node，SQL Node， Storage Node 可以快速有效的协同工作，同时也能够保证为最终用户供应集群时可以有更好的操作体验。同时还可以将复杂组件的开发维护、运维维护、使用维护任务区分供应来提升 DevOps 的整体工作效率。 因此我个人推荐在容器PaaS平台上定制复杂产品结构，进行一定程度的任务封装，通过 Operator 来对部分可原子化的复杂组件操作进行合理的封装虽然会加大初期设计实现投入，但会有效降低真正运维期的使用难度和工作压力。
当 Operator 的抽象设计相对合理时，一方面可以保证面对复杂产品结构的一键管理性，另一方面通过重组的参数交互式制定可以有效保障创建的灵活性。这是一种将复杂度转嫁给产品提供者的技术。但通常产品提供者会更了解产品的各种复杂场景下的合理应对方式，从这个角度讲 Operator Framework 是一种更合理的技术难度分配框架。