K8S目前是否有可视化的服务编排组件？

K8S目前最大的弊端，有点类似OpenStack的早期，使用起来太复杂了，一款好的产品如果仅是功能强大，但是不便于使用，对用户而言，他就不是真正意义上的好产品。目前，K8S中好像也没什么可视化编排组件，满世界的YAML让人眼花缭乱。我的理解，单纯的K8S使用是很难构建一套平台出来的，要构建一套自动化编排平台，应该是以K8S为kernel，集成外围诸多生态圈软件，这样才能实现满足终端用户要求的自动化调度、编排、CI/CD平台。这就好比单纯使用Linux内核来自己构建系统的，都是极为熟悉内核的大牛一样，如果内核外面没有很多tools、utilities供你使用，普通用户是没法使用Linux系统的。从这个角度来看，Openshift就是容器微服务时代的“Linux”。K8S可以去研究，但是如果是拿来使用的话，还是OpenShift吧！

不知道我理解的对不对：您是想要一个类似于openstack 的heat工具，或者vmware的blueprint的工具。目前，为了适应快速的业务需求，微服务架构已经逐渐成为主流，微服务架构的应用需要有非常好的服务编排支持，k8s中的核心要素Service便提供了一套简化的服务代理和发现机制，天然适应微服务架构，任何应用都可以非常轻易地运行在k8s中而无须对架构进行改动；
k8s分配给Service一个固定IP，这是一个虚拟IP(也称为ClusterIP)，并不是一个真实存在的IP，而是由k8s虚拟出来的。虚拟IP的范围通过k8s API Server的启动参数 --service-cluster-ip-range=19.254.0.0/16配置;虚拟IP属于k8s内部的虚拟网络，外部是寻址不到的。在k8s系统中，实际上是由k8s Proxy组件负责实现虚拟IP路由和转发的，所以k8s Node中都必须运行了k8s Proxy，从而在容器覆盖网络之上又实现了k8s层级的虚拟转发网络。
服务代理：
　　在逻辑层面上，Service被认为是真实应用的抽象，每一个Service关联着一系列的Pod。在物理层面上，Service有事真实应用的代理服务器，对外表现为一个单一访问入口，通过k8s Proxy转发请求到Service关联的Pod。
Service同样是根据Label Selector来刷选Pod进行关联的，实际上k8s在Service和Pod之间通过Endpoint衔接，Endpoints同Service关联的Pod；相对应，可以认为是Service的服务代理后端，k8s会根据Service关联到Pod的PodIP信息组合成一个Endpoints。
　Service不仅可以代理Pod，还可以代理任意其他后端，比如运行在k8s外部的服务。加速现在要使用一个Service代理外部MySQL服务，不用设置Service的Label Selector。
微服务化应用的每一个组件都以Service进行抽象，组件与组件之间只需要访问Service即可以互相通信，而无须感知组件的集群变化。这就是服务发现；

--service发布
k8s提供了NodePort Service、 LoadBalancer Service和Ingress可以发布Service；

　　NodePort Service

　　　　NodePort Service是类型为NodePort的Service， k8s除了会分配给NodePort Service一个内部的虚拟IP，另外会在每一个Node上暴露端口NodePort，外部网络可以通过[NodeIP]:[NodePort]访问到Service。

　　LoadBalancer Service 　　(需要底层云平台支持创建负载均衡器,比如GCE)

　　LoadBalancer Service是类型为LoadBalancer的Service，它是建立在NodePort Service集群基础上的，k8s会分配给LoadBalancer；Service一个内部的虚拟IP，并且暴露NodePort。除此之外，k8s请求底层云平台创建一个负载均衡器，将每个Node作为后端，负载均衡器将转发请求到[NodeIP]:[NodePort]。

可以根据应用类型指定对应的yaml模板，通过制作前端页面调用k8s api动态更新资源描述并使其生效，至于拖拽组合功能在前端做设计(招专业前端啊)对应到后端需要调用哪些api
以上仅是个人经验

可视化的服务编排组件没用过