基于K8S容器云平台的微服务部署方案

基于 K8S 容器云平台的微服务部署方案

K8S是第一个将“一切以服务为中心，一切围绕服务运转”作为指导思想的创新型产品，它的功能和架构设计自始至终都遵循了这一指导思想，构建在K8S上的系统不仅可以独立运行在物理机、虚拟机集群或者企业私有云上，也可以被托管在公有云中。

微服务架构的核心是将一个巨大的单体应用拆分为很多小的互相连接的微服务，一个微服务背后可能有多个实例副本在支撑。单体应用微服务化以后，服务之间必然会有依赖关系，在发布时，若每个服务都单独启动会非常痛苦，简单地说包括一些登录服务、支付服务，若想一次全部启动，此时必不可少要用到编排的动作。

K8S完美地解决了调度，负载均衡，集群管理、有状态数据的管理等微服务面临的问题，成为企业微服务容器化的首选解决方案。使用K8S就是在全面拥抱微服务架构。

那么，基于K8S的容器云平台如何部署微服务？

以下内容由社区专家顾文俊根据线上交流活动整理，由多位社区专家和会员贡献分享。

一、K8S容器云部署实践篇

Q1:现阶段容器云部署框架是什么？

@Garyy:

• 在DMZ和内网分别部署彼此独立的2套Openshift，分别为内网和DMZ区两个网段，两套环境彼此隔离。

• DMZ区的Openshift部署对外发布的应用，负责处理外网的访问

• 内网的Openshift部署针对内网的应用，仅负责处理内网的访问

-权限管理

对于企业级的应用平台来说，会有来自企业内外不同角色的用户，所以灵活的、细粒度的、可扩展的权限管理是必不可少的。OCP从设计初期就考虑到企业级用户的需求，所以在平台内部集成了标准化的认证服务器，并且定义了详细的权限策略和角色。

1. 认证：

OCP平台的用户是基于对OCP API的调用权限来定义的，由于OCP所有的操作都是基于API的，也就说用户可以是一个开发人员或者管理员，可以和OCP进行交互。OCP内置了一个基于OAuth的通用身份认证规范的服务器。这个OAuth服务器可以通过多种不同类型的认证源对用户进行认证。

2. 鉴权：

权策略决定了一个用户是否具有对某个对象的操作权限。管理员可以设置不同规则和角色，可以对用户或者用户组赋予一定的角色，角色包含了一系列的操作规则。

除了传统的认证和鉴权功能，OCP还提供了针对pod的细粒度权限控SCC（security

context constraints），可以限制pod具备何种类型的权限，比如容器是否可以运行在特权模式下、是否可以挂在宿主机的目录、是否可以使用宿主机的端口、是否可以以root用户运行等。

-多租户管理

租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。

在OCP中，project是一个进行租户隔离的概念，它来源于kubernetes的namespace，并对其进行了功能的扩展。利用Project，OCP平台从多个层面提供了多租户的支持。

1. 权限控制。通过OCP平台细粒度的权限管理机制，管理员可以对不同的用户和组设置不同project的权限，不同用户登录以后只能操作和管理特定的project

2. 网络隔离。OCP平台使用openvswitch来管理内部的容器网络，提供两种类型的网络模式，一种是集群范围内互通的平面网络，另一种是project级别隔离的网络。每个project都有一个虚拟网络ID（VNID），不同VNID的流量被openvswitch自动隔离。所以不同项目之间的服务在网络层不能互通。

3. Router隔离。Router是OCP平台一个重要软件资源，它提供了外部请求导入OCP集群内部的能力。OCP提供了Router分组的功能，不同的project可以使用独立的Router，不互相干扰，这样就避免了由于某些应用流量过大时对其他应用造成干扰。

物理资源池隔离。在多租户的环境中，为了提高资源的利用率一般情况下物理资源池是共享的，但是有些用户也会提供独占资源池的需求。针对这种类型的需求，OCP平台利用nodeSelector的功能可以将基础设施资源池划分给特定的project独享，实现从物理层面的隔离。

-日志和监控

（1）传统应用日志

有别于当前流行的容器应用，的传统应用同时一个中间件会运行多个应用，且应用通过log4j等机制保存在文件中方便查看和排错。因为容器运行的特性，对于这部分的日志我们需要持久化到外置存储中。

日志的分类如下：

• 中间件日志

• dump文件

• 应用日志

日志保存在计算节点上挂载的NFS存储。为了规范和方便查找。日志将会按OCP平台中的namespace建立目录，进行划分。

（2）新应用日志

应对分布式环境下日志分散的解决办法是收集日志，将其集中到一个地方。收集到的海量日志需要经过结构化处理，进而交给需要的人员分析，挖掘日志的价值信息。同时不同的人员对日志的需求是不一样的，运营人员关注访问日志，运维人员关注系统日志，开发人员关注应用日志。这样就需要有一种足够开放、灵活的方法让所有关心日志的人在日志收集过程中对其定义、分割、过滤、索引、查询。

OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力：

¡ö 日志采集，将日志集中在一起

¡ö 索引日志内容，快速返回查询结果

¡ö 具有伸缩性，在各个环节都能够扩容

强大的图形查询工具、报表产出工具

EFK是Elasticsearch(以下简写为ES)+ Fluentd+Kibana的简称。ES负责数据的存储和索

引，Fluentd负责数据的调整、过滤、传输，Kibana负责数据的展示。

Fluentd无论在性能上，还是在功能上都表现突出，尤其在收集容器日志领域更是独树一帜，成为众多PAAS平台日志收集的标准方案。

（3）监控

PaaS平台的监控包括系统监控、容器监控等。监控流程由信息收集、信息汇总和信息展示等几个部分组成。

在Openshift中默认使用kubenetes的监控信息收集机制，在每个节点上部署cadvisor的代理，负责收集容器级别的监控信息。然后将所有信息汇总到heapster，heapster后台的数据持久化平台是Cassandra。最后由hawkular从Cassandra获取信息进行统一的展示。

1. 组件说明

Openshift的监控组件，用于对pod运行状态的CPU、内存、网络进行实时监控，和Kubernetes使用的监控技术栈一样，包括三个部分：

HEAPSTER

用于监控数据的采集

/kubernetes/heapster

HAWKULAR METRICS

属于开源监控解决方案Hawkular，基于JSON格式管理、展示监控数据

/

CASSANDRA

Apache Cassandra是一个开源的分布式数据库，专门用于处理大数据量业务

/

-DMZ区计算节点

在DMZ区应用部署遵循以下策略：

• 已有应用迁移至容器云平台时的资源申请按现有配置设置，申请的服务器将仅供该使用

• 如果需要横向扩展，也仅在已分配的计算节点上，如果资源不足，应用项目组可再申请新的计算资源

• 本期项目中，XXX部署在DMZ区平台上，使用2个计算节点；XXX部署在内网平台上，使用2个计算节点

• 在实施时需要为相应的计算节点标记标签，使应用部署时部署到指定的计算节点上。

例如在DMZ网段对XXX应用所使用的2台计算节点打上标签

在部署XXX应用使，nodeSelector需要指明使用的节点的标签为XXX=XXX。

-传统应用访问策略

• Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。

• 在F5 VS的Pool Member中配置所有节点，通过Keepalived来实现HA

• 应用系统和用户不用改变现有的访问方式

-应用访问及防火墙

内网计算节点可以直接访问数据库

DMZ区计算节点访问数据库有2种方案：

• 计算节点直接通过内网防火墙访问该应用数据库

内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期项目，xxx应用仅使用2个节点，则防火墙仅开通这2个节点访问xxx数据库的权限

• 计算节点经Outbound 路由通过内网防火墙访问内网数据o

这oOutbound路由在Openshift中称之为Egress Routero

因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限

Q2: 容器平台建设过程中，如何利用好已有云平台，从技术、架构等层次，需要注意哪些事项？

@ynwssjx：

容器跑在物理机上，还是跑在云平台虚机上，这是个值得讨论的话题。

对于公有云而言，毫无疑问，肯定是跑在云主机上的。那么，有的客户在上线容器微服务之前，已经有了自己的私有云平台，那么这个时候是购买一堆物理机来另起炉灶，还是基于已有云平台快速部署，这就值得斟酌了。

其实也没什么好纠结的，无非就是一个问题:性能！

跑在物理机上，性能肯定是最佳的，但是你真的需要所谓的性能吗？测过没有，是否真的只

有物理机才能满足你的容器微服务应用，根据我的经验，以金融行业来说，大部分用户物理机资源常年处于低负荷状态！以性能为借口，恶意拉动GDP，就是耍流氓啊！

如果你决定跑在已有云平台上，那么，你要考虑的问题如下：

1、充分利用LaC（Infrastructure as Code）实现自动化编排部署，这是云平台最大的优势（比如openstack中的heat），也是裸机集群最大的劣势；

2、网络性能。在IaaS层上面跑容器，网络是个需要认真考虑的问题，calico最佳，但是基础设施改动大，不是所有客户都能接收，flannel+hostgw是个不做选择，原则就是尽量防止二次封装叠加，致使网络性能下降过多。

3、架构上具备后续扩展性，这里指的不仅仅是scale-out扩展，更是功能上的向后扩展，比如随着微服务不多扩大，网络负载不断增加，后续你可能会打算使用service mesh，那么前期就靠考虑清楚兼容性问题

4、最后，也是最朴素的一点，简单、好用、高可用原则，不要为了高大上而“高大上”，搞得自己完全hold不住，得不偿失，一个好的平台选型就是成功的80%

@nuaays：

1.需要看已有云平台提供了哪些功能或接口可以供容器平台使用，比如CMDB、比如权限管理、比如应用或者中间件配置等。

2.应用以容器方式和传统方式的部署方式和流程看是否可以抽象统一化，不管是升级回滚扩容等，在运维层面行为一致就能利用已有平台但是自己要实现底层与编排系统的对接。

Q3: K8S集群如何实现集群安全？双向认证or简单认证？

@Garyy：

Kubernets系统提供了三种认证方式：CA认证、Token认证和Base认证。安全功能是一把双刃剑，它保护系统不被攻击，但是也带来额外的性能损耗。集群内的各组件访问API

Server时，由于它们与API Server同时处于同一局域网内，所以建议用非安全的方式访问API Server，效率更高。

-双向认证配置

双向认证方式是最为严格和安全的集群安全配置方式，主要配置流程如下：

1）生成根证书、API Server服务端证书、服务端私钥、各个组件所用的客户端证书和客户端私钥。

2）修改Kubernetts各个服务进程的启动参数，启用双向认证模式。

-简单认证配置

除了双向认证方式，Kubernets也提供了基于Token和HTTP Base的简单认证方式。通信方仍然采用HTTPS，但不使用数字证书。

采用基于Token和HTTP Base的简单认证方式时，API Server对外暴露HTTPS端口，客户端提供Token或用户名、密码来完成认证过程。

@nuaays：

不仅仅是API层面，还有每个节点kubelet和应用运行时的安全，可以看下这里

/docs/tasks/administer-cluster/securing-a-cluster/

@ynwssjx：

K8S的认证相对来说还是个比较复杂的过程，如下这篇文章，详细介绍了K8S中的认证及其原理：

/

Q4: K8S在容器云上的负载均衡策略和总体思想是什么？

@Garyy：

高可用主要分为如下几个：

-外部镜像仓库高可用

外部镜像仓库独立于OCP平台之外，用于存储平台构建过程中所使用的系统组件镜像。因为外部无法直接访问OCP平台的内部镜像仓库，所以由QA环境CD推送到生产环境的镜像也是先复制到外部镜像仓库，再由平台导入至内部镜像仓库。

为了保证外部镜像仓库的高可用， 使用了2台服务器，前端使用F5进行负载均衡，所有的请求均发至F5的虚拟地址，由F5进行转发。后端镜像仓库通过挂载NFS共享存储。

-master主控节点高可用

Openshift的Master主控节点承担了集群的管理工作

-计算节点（容器应用）高可用

计算节点高可用指计算节点上运行的容器应用的高可用。一个计算节点异常停机后，其上的容器将会被逐步迁移到其他节点上，从而保证了高可用。

同时可以通过标签的方式来管理计算节点，在不同的计算节点划分为不同的可用区或组。在部署应用时，使用节点选择器将应用部署至带有指定标签的目标计算节点上。为了保证高可用，标签组合的目标计算节点数要大于1。这样可以避免一台目标节点宕机后，调度器还能找到满足条件的计算节点进行容器部署。

-应用高可用

基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。

由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。

@ynwssjx：

简单一点来说，就是内部服务的动态发现、负载均衡、高可用和外部访问的路由；

通过service，解耦动态变化的IP地址，POD可以随意关停，IP可以任意变，只要DNS正常，服务访问不受影响，但是这里面你的随时保证有个可用的POD,这个时候你就得需要LB了，或者说LB干的就是这个事情。

内部服务之间访问通过service解决了，那么外部访问集群内服务，则通过router即是解

决，外网访问要不要负载均衡，大规模高并发情况下是肯定的，当然，外部负载均衡通常需要用户自己搞定了，F5或者开源的HAproxy都行！

Q5: 多租户在kubernets/openshift的实现和管理？

@Garyy：

租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。

在OCP中，project是一个进行租户隔离的概念，它来源于kubernetes的namespace，并对其进行了功能的扩展。利用Project，OCP平台从多个层面提供了多租户的支持。

1. 权限控制。通过OCP平台细粒度的权限管理机制，管理员可以对不同的用户和组设置不同project的权限，不同用户登录以后只能操作和管理特定的project

2. 网络隔离。OCP平台使用openvswitch来管理内部的容器网络，提供两种类型的网络模式，一种是集群范围内互通的平面网络，另一种是project级别隔离的网络。每个project都有一个虚拟网络ID（VNID），不同VNID的流量被openvswitch自动隔离。所以不同项目之间的服务在网络层不能互通。

3. Router隔离。Router是OCP平台一个重要软件资源，它提供了外部请求导入OCP集群内部的能力。OCP提供了Router分组的功能，不同的project可以使用独立的Router，不互相干扰，这样就避免了由于某些应用流量过大时对其他应用造成干扰。

物理资源池隔离。在多租户的环境中，为了提高资源的利用率一般情况下物理资源池是共享的，但是有些用户也会提供独占资源池的需求。针对这种类型的需求，OCP平台利用nodeSelector的功能可以将基础设施资源池划分给特定的project独享，实现从物理层面的隔离。

@ynwssjx：

openshift里面对多租户问题有比较好的解决方案，openshift默认使用OVS来实现SDN，高级安装里面默认使用ovs-subnet SDN插件，网络实现类似于flat网络，因此要实现多租户可以在安装过程中设置参数：

os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'

这样openshift将使用ovs-multitenant多租户插件，实现租户之间的安全隔离，另外，在openshift的多租户和容器中心化日志实现中，每个租户都只能查看属于自己项目的日志，这个确实有亮点的！

除了OVS插件，openshift是完全支持CNI标准的，因此，是要是符合CNI标准的三方

SDN插件，都是可以在openshift中使用的，目前支持的SDN插件有：

1、Cisco Contiv；

2、Juniper Contrail；

3、Nokia Nuage；

4、Tigera Calico ；

5、VMware NSX-T ；

另外，openshift是支持部署在物理机、虚拟机、公有云和私有云上的，可能有些用户会利用已有的公有云或私有云来部署。这个时候，如果使用OVS插件，你OpenShift中的SDN可能出现overlay on overlay的情况，此借助三方SDN插件是个不错的选择，比如flannel+hostgw在性能上肯定就优于默认的ovs-multitenant。

Q6: elasticsearch在K8S中部署？

@ynwssjx：

不论是IaaS还是PaaS，手工部署ELK都是不推荐的，通过ansible可以自动实现，至于如何实现，可以参考redhat文档：

/3.9/install_config/aggregate_

至于说分布式存储、本地存储还是集中存储，这个没有既定答案，都是可以参考行业实现，比如Redhat就是参考对象

@nuaays：

不建议elasticsearch采用分布式存储，日志亮大情况下如果是分布式存储es写会是瓶颈。

@Garyy：

根据你的描述，应该是有两个方面的问题：

1）es的后端存储的选择

2）Pod的创建

问题一：

分布式，本地，集中存储不管是在传统环境，还是在容器的环境中，都有使用。目前对于数据库应用，我们看到还是传统存储-集中存储，占了绝大多数的市场。

分布式存储，随着云计算的兴起，诞生的一种存储架构。它的优势很明显，无中心节点，弹性伸缩，适合云应用，等等。传统的厂商，netapp，emc，ibm，hp都有分布式存储，都

是基于其传统的技术；新兴的开源分布式存储ceph，已经成为分布式存储的领军技术，有redhat，suse，xsky，联想，华三等。

分布式存储的劣势主要是，还处于发展阶段，技术有待成熟，有待市场的接受。

本地存储，一般使用的应该比较少。主要是数据复制同步方面的问题。

集中存储，目前用的最多的，不管是FCSAN还是IPSAN，其稳定性和安全性都是能够满足要求的。但是，在性价比，可扩展性方面都存在很大的问题。

问题二：

K8S的所有的流程都不是手动完成的，都是基于自动化完成。可以使用chef/ansible/puppt等工具完成。

Q7: K8S集群中的各受管节点以及其中的容器如何做监控？

@Garyy：

kubernetes已成为各大公司青i睐的容器编排工具，各种私有云公有云平台基于它构建，其监控解决方案目前有三种：

（1）heapster+influxDB

（2）heapster+hawkular

（3）prometheus

prometheus作为一个时间序列数据收集，处理，存储的服务，能够监控的对象必须直接或间接提供prometheus认可的数据模型，通过http api的形式发出来。我们知道cAdvisor支持prometheus,同样，包含了cAdivisor的kubelet也支持prometheus。每个节点都提供了供prometheus调用的api。

prometheus支持k8s

prometheus获取监控端点的方式有很多，其中就包括k8s，prometheu会通过调用master的apiserver获取到节点信息，然后去调取每个节点的数据。

@nuaays：

k8s节点的kubelet服务自带cadvisor用来收集各节点容器相关监控信息，然后通过heapster收集，这样在dashboard上可以看到容器使用CPU和Memory。

为了长期监控，可以采用prometheus监控方案nodeExporter收集主机监控信息cadvisor收集容器监控信息

k8s中需要给kubelet配合kube-reserved和system-reserved相关参数给系统预留内存

@ynwssjx：

监控领域，无非就是E*K，heapster、influxDB、heapster、hawkular、prometheus、grafana这些东西了，就目前来看，prometheus应该是最具前景的监控工具，在openshift 3.12里面，heapster将由prometheus替换，未来应该是prometheus的天下吧！

二、微服务部署篇

Q1: 微服务架构按照什么细粒度拆分？

@Steven99：

既然理解微服务是用来重构业务应用的，这个问题就很简单，以业务应用为核心，构建业务服务。忘掉，重构！

业务服务需要数据服务、计算服务、搜索服务、算法服务……以及基本的日志、监控、配置、注册发现、网关、任务调度等组件。

至于数据服务怎么实现，看你团队能力。这才涉及数据分拆，模型重构。

服务通信可以考虑事件驱动机制，也是后期业务数据处理，态势感知，智能风控，智能营销，智能运维等的基础。

@ynwssjx：

感觉这是个没有标准答案的问题，如何拆？按什么套路来拆？问答这两个问题的基础一定要十分熟悉你的业务逻辑才行。微服务这东西，尤其是那种已经运行多年的老系统，一不小心就能拆出问题。

如果对云计算，对OpenStack有了解，建议以OpenStack中的Kolla项目为微服务入门学习对象，Kolla干的事情就是把OpenStack服务拆分成微服务的形式跑在容器中，OpenStack号称全球最大开源Python项目，由几十个开源子项目组成，如果能把这样复杂的集群项目都拆分成微服务，那么一定会得到很多别人给不了的心得体会。

这里以OpenStack为例，Kolla这个项目对OpenStack的拆分，大概如下：

1、先按服务功能划分，得到粗粒度，如计算服务、网络服务、存储服务，这些租粒度模块通常会共享同一个base镜像，这个base镜像中预置了服务模块的共性依赖；

2、基于服务模块的“原子性”拆分，如把计算服务Nova拆分为noav-api、nova-

scheduler、nova-compoute、nova-libvirt等等，所谓原子性拆分，就是拆分到不能再往下拆为止，原子拆分后通常就是彼此独立的单进程了，也可以把他们称为是叶子节点了，他们的镜像都是针对自己依赖的“个人”镜像，不能被其他进程共享了。

如果从镜像的角度来看，大概是这样：

父镜像：centos-base

一级子镜像：centos-openstack-base

二级子镜像：centos-nova-base

叶子节点镜像：centos-nova-api

这几个镜像的继承关系是这样的：centos-base->centos-openstack-base->centos-nova-base->centos-nova-api

以上只是举个例子供参考，建议深入了解下Kolla这个项目，对于微服务的拆分就会更有底气些！

@t3573393：

先将系统模块化解耦，别的微服务还是一体都只是部署的问题。 常见的耦合方式有 逻辑耦合 功能耦合 时间耦合等， 感觉从码农的角度来分析解决耦合是基于微服务还是soa化的最大区别。 soa化的系统更多的是业务系统，领域模型级别的。 在分布式系统中远远不够需要考虑性能，安全，事务等，最起码的cap原则还是要把控的。 码农解耦的角度有 接口化，动静分离（查询和修改等），元数据抽取等等，更多的是代码上，设计模式上的真功夫 。 很多架构的估计没这个水平， 只看大象不看大腿。

@ppqq：

需要明确：

1、充分分析拆分的目的是什么，需要解决什么问题。

2、是否具备微服务技术能力，是否已选型好相应的技术框架，技术变化对企业有什么影响。

3、是否有完善的运维设施保障，比如快速配置、基础监控、快速部署等能力。

Q2: svn环境下实现CI/CD？

@yeefone：

svn可以使用hook(post commit)的方式来实现，但是需要编写hook脚本，灵活度存在问题；

这在svn-repo的粒度较细的情况下还可行，如何一个大的repo，管理起来较复杂，不建议使用；

建议使用jenkins 轮询scm的方式触发pipeline/job

@ynwssjx：

能不能实现CI/CD与SVN无关，关键是你如何构建pipeline，微服务理念下大致这样：

gitlab/svn->Jenkins->build images->push images->docker-registry->pull

images->containers

Q3: K8S DNS服务配置如何实现微服务的发布？

@Garyy：

配置k8s dns

DNS (domain name system),提供域名解析服务，解决了难于记忆的IP地址问题，以更人性可读可记忆可标识的方式映射对应IP地址。

Cluster DNS扩展插件用于支持k8s集群系统中各服务之间发现与调用。

组件：

•SkyDNS 提供DNS解析服务

•Etcd 存储DNS信息

•Kube2sky 监听kubernetes，当有Service创建时，生成相应的记录到SkyDNS。

@nuaays：

如访问外部DNS，可以设置external_dns 到configmap实现

Q4: 请问在K8S中部署数据库现在有好的解决方案了么？

@nuaays：

银联搞了一个基于容器的DBaaS，是供应商做的，这里是ppt可以参考，主要点:SAN 和

SR-IOV

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

@ynwssjx：

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

@nuaays：

可以根据应用类型指定对应的yaml模板，通过制作前端页面调用k8s api动态更新资源描

述并使其生效，至于拖拽组合功能在前端做设计(招专业前端啊)对应到后端需要调用哪些api

@Garyy：

类似于是想要一个类似于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。