基于K8S的容器云平台如何部署微服务？
|
银联搞了一个基于容器的DBaaS，是供应商做的，这里是ppt可以参考，主要点:SAN 和 SR-IOV
Q5: K8S目前是否有可视化的服务编排组件 A5： K8S目前最大的弊端，有点类似OpenStack的早期，使用起来太复杂了，一款好的产品如果仅是功能强大，但是不便于使用，对用户而言，他就不是真正意义上的好产品。目前，K8S中好像也没什么可视化编排组件，满世界的YAML让人眼花缭乱。我的理解，单纯的K8S使用是很难构建一套平台出来的，要构建一套自动化编排平台，应该是以K8S为kernel，集成外围诸多生态圈软件，这样才能实现满足终端用户要求的自动化调度、编排、CI/CD平台。这就好比单纯使用Linux内核来自己构建系统的，都是极为熟悉内核的大牛一样，如果内核外面没有很多tools、utilities供你使用，普通用户是没法使用Linux系统的。从这个角度来看，Openshift就是容器微服务时代的“Linux”。K8S可以去研究，但是如果是拿来使用的话，还是OpenShift吧！ 可以根据应用类型指定对应的yaml模板，通过制作前端页面调用k8s api动态更新资源描述并使其生效，至于拖拽组合功能在前端做设计(招专业前端啊)对应到后端需要调用哪些api 类似于是想要一个类似于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]。 Q6: service mesh和spring cloud的优缺点 A6 2018年以前，扛起微服务大旗的，可能是Spring Cloud。Service Mesh作为一种非侵入式API的框架。比侵入式的Spring Cloud，虽然还在处于成长期，但是应该更有前景。 关于service mesh的定义，通常以Buoyant 公司的 CEO Willian Morgan 在其文章 WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE? 中对 Service Mesh的定义为参考： A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. 就行业而言，Docker和Kubernetes解决的了服务部署的问题，但是运行时的问题还未解决，而这正是Service Mesh的用武之地。Service Mesh的核心是提供统一的、全局的方法来控制和测量应用程序或服务之间的所有请求流量(用数据中心的话说，就是“east-west”流量)。对于采用了微服务的公司来说，这种请求流量在运行时行为中扮演着关键角色。因为服务通过响应传入请求和发出传出请求来工作，所以请求流成为应用程序在运行时行为的关键决定因素。因此，标准化流量管理成为标准化应用程序运行时的工具。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
