1、天宫paas分布式服务架构演进及K8S基础知识培训目录2第一部分EDAS原理架构第三部分EDAS ON K8S 架构演进第四部分未来Service Mesh 之路第二部分K8S概念架构与kubectl命令3高性能去中心化的分布式服务框架传统”中心化”服务框架服务调用者服务调用者 服务调用者服务调用者企业服务总线服务提供者服务提供者服务提供者服务提供者 服务调用者服务调用者服务提供者服务提供者服务调用者服务调用者服务提供者服务提供者服务提供者服务提供者服务调用者服务调用者 EDAS”去中心化”服务框架4EDAS介绍-EDAS在PaaS中的定位天宫平台是总部省分协同一体化的公共云化平台，是高效的一2、体化IT生态系统，而EDAS为SaaS层提供的分布式服务解决方案。IaaS资源池计算设备PaaS存储设备网络设备安全设备物理机虚拟机I-PaaSDocker容器一体化运营平台服务治理平台监控天梯平台资源提供资源类型建维门户SaaS号卡中心自然人中心沃行销政企中台天宫数据治理资源管理告警通知统计分析数据归集分布式缓存分布式数据服务分布式服务框架分布式搜索引擎数据恢复数据传输评估系统反馈系统分布式文件系统消息中间件报表工具权益中心共享服务5EDAS介绍企业级分布式应用服务（Enterprise Distributed Application Service，简称 EDAS）是企业级互联网架构解决方3、案的核心产品。是阿里巴巴中间件团队多款久经沙场的分布式产品作为核心基础组件。充分利用阿里云现有资源管理和服务体系，引入中间件成熟的整套分布式计算框架（包括HSF 分布式服务化框架、服务治理、运维管控、链路追踪和稳定性组件等），以应用为中心，快速帮助企业级客户轻松构建大型分布式应用服务系统。应用容器 集成多款中间件高性能服务框架 服务鉴权服务基础设施 配置推送应用生命周期 大规模集群管理 应用分组发布 弹性伸缩 灰度发布账号与权限 主子账号 自定义角色 资源组 分布式调用链跟踪 应用监控 IPAAS基础监控 容器层监控 业务监控大盘服务治理 限流降级智能应用诊断 实时日志 容器运行时诊断6EDA4、S架构原理-高性能服务框架 HSF的调用原理-面向RPC(远程过程)调用组件服务注册中心ConfigerServer服务提供者HSF-Provider地址服务器AddressServer服务消费者HSF-Consumer配置推动中心DiamondServermysql8.规则配置推送9.Hsf服务调用7EDAS架构原理-EDAS逻辑架构8大规模分布式服务调用的链路跟踪9EDAS架构原理-大规模分布式服务调用的链路跟踪服务提供者集群JStorm 集群实时收集日志实时收集日志Hbase实时统计展示服务器写入统计数据离线计算存储MapReduce计算结果读取原始日志与分析结果数据输出与展现Hadoo5、p全量日志（每小时）日志文件带埋点的中间件日志收集agent读取写入实时配置infobright10运维管控EDAS 中的限流降级主要用于解决后端核心服务因压力过大造成系统反应过慢或者崩溃问题，通常用于例如商品秒杀、抢购、大促、防刷单等大流量场景。目录11第一部分EDAS原理架构第三部分EDAS ON K8S架构 演进第四部分未来Service Mesh 之路第二部分K8S概念架构与kubectl命令12Kubernetes 概要 Kubernetes：Google开源的容器集群管理系统，为容器化应用提供了一整套功能，如：自动化部署、调度、服务发现、扩缩容及维护更新等，使容器化应用的部署和管理6、简单并高效Kubernetes MasterREST API ServerKubelet容器容器Controller ManagerSchedulerETCDKube-ProxyPodsKubelet容器容器Kube-ProxyPodsKubelet容器容器Kube-ProxyPods用户服务（Zookeeper、Nginx、HSF）服务管理容器分布弹性伸缩故障迁移节点管理Kubernetes-master节点节点类型运行组件描述master节点（管控节点）etcd集群kube-apiserver提供了k8s各类资源对象（pod,RC,Service等）的增删改查等HTTP Rest接口，是整7、个系统的数据总线和数据中心。kube-scheduler从kube-apiserver中获取的未被调度的pod通过一系列调度算法找到最适合的node来完成调度kube-controller-manager（节点控制器/副本集控制器/端点控制器等）负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。etcd保存集群所有的网络配置和对象的状态信8、息Kubernetes-node节点节点类型运行组件描述node节点（计算节点）kubelet负责pod的管理、健康检查和监控kube-proxy主要是负责service的实现，具体来说，就是实现了内部从pod到service和外部的从node port向service的访问。概念运行kubelet的k8s节点命令查看：kubectl get node owide资源对象：node概念通过将k8s系统内部的对象分配到不同的Namespace中，形成逻辑上的隔离，便于不同的分组在共享集群资源的同时还能被分别管理。同一Namespace下的Kubenetes对象的Name必须唯一。命令创建：kub9、ectl create ns xxx查看：kubectl get ns 删除：kubectl delete ns xxx资源对象：namespace概念pod是k8s创建和管理的最小计算单元，由多个(至少两个)容器组成.pod中的容器共享容器存储、网络和容器运行配置项，pod中的容器可以通过localhost通信。Pod中的容器总是被同时调度，可以把单个Pod想象成是运行独立应用的“逻辑主机”。命令创建：kubectl apply f pod.yaml查看：kubectl get pod -n xxx-owide删除：kubectl delete pod xxx -n xxx或kubectl 10、delete f pod.yaml资源对象：pod概念用作定义和更新pod的状态、副本数、资源等。命令创建：kubectl apply f deployment.yaml查看deployment：kubectl get deployment n xxx owide查看pod：kubectl get pod -n xxx owide删除pod：kubectl delete pod xxx n xxx资源对象：deployment概念service：k8s的服务发现方式，将一组pod暴露为一个域名或者一个ip供其他服务调用。endpoints：与svc一同被创建，与svc同名，是实现实际服务的端点11、集合，也就是service绑定的一组pod的ip列表。命令创建：kubectl apply f service.yaml查看：kubectl get svc n xxx owide kubectl get endpoints n xxx-owide删除：kubectl delete svc xxx n xxxservice调用流程service类型三种port资源对象：service与endpoints类型访问方式适用范围clusterIPclusterIP：port访问服务集群内服务调用nodePortnodeIP:nodePort访问服务集群外服务调用类型描述port集群内通过cluste12、rIP+port访问服务nodePort集群外通过nodeIP+nodePort访问服务targetPortpod中提供服务的端口客户端程序调用服务名或者域名coreDns服务名或域名解析为clusterIP使用负载均衡算法选取endpoints中的某个podIP转发到某一个具体的pod中概念用来管理和存储应用程序的配置文件的kubernetes资源对象，将配置从应用程序和镜像中解耦，有利于应用程序的可以执行。命令创建1.从命令行创建：kubectl create configmap cm-1 -from-literal=db.host=172.168.0.1 -from-literal=db13、.port=3306 -n test 从文件中创建：kubectl create configmap cm-2 -from-file=./db.conf-n test查看命令：kubectl get cm cm-2 -n test-oyaml使用configmap通过环境变量注入pod1.创建pod：kubectl apply f pod-configmap.yaml2.查看pod的环境变量通过volume挂在到pod中1.创建pod：kubectl apply f pod-configmap-volume.yaml2.查看pod中的挂载点注意，configmap更新后I.通过环境变量注入po14、d的方式，pod中的env不会热更新II.通过volume挂载到pod中的方式，挂载点的文件内容会热更新资源对象：configMap描述默认情况下，k8s不会限制pod的内存，只要pod中应用程序需要，pod完全可以占用node的所有内存资源。举例创建一个限制内存资源的pod：kubectl apply f pod-memory.yamlrequests：容器使用的最小内存资源需求,作为容器调度时的依据，当node节点剩余内存大于request时pod才有可能调度到该node上。limits：容器能使用内存的最大值容器使用内存超过limits会被内核oom_kill对于java程序，须设置jv15、m参数以防止oom_kill内存限制描述默认情况下，k8s不会限制pod的cpu，只要pod中应用程序需要，pod完全可以占用node的所有cpu资源。举例创建一个限制cpu资源的pod：kubectl apply f pod-cpu.yamlrequests：容器使用的最小cpu资源需求,作为容器调度时的依据，当node节点剩余cpu大于request时pod才有可能调度到该node上。limits：容器能使用cpu的最大值容器使用cpu超过limits，不会被kill，但是会限制不超过limit值。cpu限制默认情况下，一个namespace中所有pod使用的cpu/memory资源总量是16、没有限制的，为了合理地对cpu/memory资源进行规划使用，可以对某个namespace的资源总量进行限制。创建ResourceQuota：kubectl apply-f quota-mem-cpu.yaml-n test查看ResourceQuota为了防止因为忘记设置requests和limits而导致的资源浪费等问题，可以对namespace中的pod设置默认的requests和limits值创建LimitRange：kubectl apply-f cpu-mem-default.yaml-n test查看LimitRangenamespace限制pod创建流程目录25第一部分EDAS17、原理架构第三部分EDAS ON K8S架构 演进第四部分未来Service Mesh 之路第二部分K8S概念架构与kubectl命令cB2.0资源层容器化演进天 宫平台-能力支撑基础硬件层计算设备存储设备网络设备安全设备号卡自然人权益虚拟资源层RDS负载均衡分布式服务RDS应用服务新零售cB2.0资源使用现状cB2.0资源目标演进方向天 宫平台-能力支撑基础硬件层计算设备存储设备网络设备安全设备号卡自然人权益虚拟资源层RDS负载均衡分布式服务RDS应用服务新零售容器-资源支撑cBSS2.0平台除rds外其他组件已经全部容器化，平台运行稳定无故障。实践证明，基于EDAS的项目应用运行稳定，完全满18、足各项目的当前需求及未来发展要求。采用逐步替代的演进方式，将应用EDAS服务从虚拟机逐渐迁移到k8s容器环境,最终实行全容器化支撑。K8S部署方案27跨数据中心部署K8S集群数据中心内部K8S集群通过calico协议实现多节点互联；各节点的路由信息由路由反射器维护，每200台宿主机配置一个路由反射器。跨数据中心K8S集群通过VxLAN技术实现calico互联，最终实现统一管控（测试中）calico网络元数据由Etcd主备集群维护，保证网络状态的准确性和可靠性。K8S on dcos与K8S on PM混搭模式，满足不同需求廊坊廊坊K8S on dcosK8S on PM西咸K8S on PM统19、一管控平台Etcd集群Etcd备份calicocalicoVxLANVxLANTunnelTunnelRRRREtcd集群28K8S技术平台使用关键点（1）-EDAS纳管 手动维护项目信息+自动注册纳管EDAS-POD相结合的方式，实现纳管全流程的自动化处理 技术难点：EDAS纳管与K8S资源分配还未完全贯通，需要结合EDAS管理流程特点制定解决方案开始创建租户，EDAS应用、集群和资源组ecs启动空的tomcat创建POD绑定ECS资源组启动EDAS-agent进程EDAS自动为pod初始化运行环境并加载War包Pod加入指定应用加入EDAS集群应用是否已部署结束控制台手动K8S后台自动，无20、人工干预否否是是1.DTCENTER上创建项目租户2.EDAS控制台创建集群、ECS资源组和应用1.K8S中创建EDAS所需POD，集成EDAS的相关API按照EDAS管理流程实现POD启动后自动注册到EDAS，完成应用的自动部署和启动操作2.参照EDAS-POD创建纳管过程，实现POD销毁后重启和POD扩容过程。K8S技术平台使用关键点（2）-负载均衡演进29 前台应用界面采用SLB负载均衡的方式对外提供服务，目前手工配置。K8S集群内部REST或HTTP请求可通过K8S的SERVICE功能实现负载 技术难点：1.将POD纳管到SLB负载体系中。2.内部SERVICE需由调用IP方式改成DN21、S或者SERVICESLB手动1.手动创建SLB2.手动配置SLB端口监听3.手动配置绑定后端应用IPSLB自动化1.手动创建SLB2.EDAS的pod中自动调用slb的api自动绑定SVC访问1、容器启用service2、访问容器restful服务通过service域名形式目录30第一部分EDAS原理架构第三部分EDAS ON K8S架构 演进第四部分未来Service Mesh之路第二部分K8S基础概念架构与kubectl命令31Service Mesh由来“Service Mesh”概念还非常年轻，这个词在国内被翻译为“服务网格”或“服务啮合层”。和TCP/IP诞生的思想类似，在微服务使22、用多年后，人们发现需要独立地抽象出一层逻辑网络，专门用于“微服务通信与治理策略的落地”，让应用只关心业务，把服务治理的事情全部交由“这一层”去处理。图 1：传统微服务之间的微服务治理逻辑的位置图 2：微服务治理逻辑被独立出来之后的位置32Service Mesh基本概念Service Mesh服务网格是一个基础设施层，是层次化、规范化、无侵入的分布式服务治理技术平台。主要用于处理服务间的通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。层次化分为数据面和控制面两个概念，数据23、面是指所有数据流动的那个层面，控制面是用来控制这个数据面的，对服务去做处理。对数据面和控制面进行分层，带来的好处是，针对一个复杂的系统进行切分，可以获得更清晰的认识，这和devide and conque是同一个理念。规范化是指通过标准协议完成数据平面和控制平面的连接，同时，sidecar成为所有traffic互联、互通的约束标准。无侵入是指我们希望通过无侵入，当新增一个业务的时候，不需要考虑一个SDK去初始化，而是可以通过sidecar的进程方式来解耦。33Istio是什么Istio项目是Service Mesh概念的最新实现，是由Google、IBM、Lyft联合开发的开源项目，2017年24、5月发布第一个release 0.1.0，可以透明的分层到现有的分布式应用中，它也是一个平台，包括允许它集成到任何日志记录平台，遥测或策略系统的API。Istio 多样化功能集能够高效的运行在分布式微服务架构中，并同时提供保护、连接和监控微服务等方法。流量管理：控制服务之间流量和API调用，使得调用更可靠。可观察性：istio 强大的追踪、监控和日志记录的功能。策略执行：策略应用于微服务之间互动，确保访问策略得以执行（执行是通过配置网格而不是修改程序代码）。服务身份安全：Istio 提供底层安全通信信道，并大规模管理服务通信的认证、授权和加密34Istio架构Istio架构在网格逻辑上主要分为25、控制平面（Control Plane API）和数据平面（Data Plane）。控制平面：负责管理和配置代理来路由流量。主要分为三个组件Pilot、Mixer、Citadel。数据平面：由一组以sidecar方式部署的智能代理组成，这些代理可以调节和控制微服务及Mixer之间所有的网络通信。Istio默认使用Envoy做智能代理，当然也支持其它代理，例如Linkerd、Nginmesh等。Pilot：为Envoy sidecar提供服务发现功能，为智能路由和弹性提供管理功能，它将控制流量行为的高级路由转化为特定于Envoy的配置，并在运行时将它们传播到sidecar。Mixer：独立于平台，负责在Service Mesh上执行访问控制和使用策略，并从Envoy代理和其它服务中收集遥测数据。Istio-auth：通过内置身份和凭证管理以提供服务与服务间的身份验证并且可以升级ServiceMesh中未加密的流量。CHINAUNICOM谢谢！