Rancher2.0+Kubernetes(k8s)+Docker+SpringCloud 部署分布式服务 (1)
SpringCloud:一般使用SpringCloud写好每个Service后,使用jar包的形式部署,一般架构为Eureka+Config+Feign+Sleuth+Zipkin的形式,常用的还有Zuul实现路由网关的功能,由于项目中没用,这里不做介绍Eureka(client+server)提供了服务注册和服务发现的功能Config(client+server)提供每个servic...
SpringCloud:
一般使用SpringCloud写好每个Service后,使用jar包的形式部署,一般架构为Eureka+Config+Feign+Sleuth+Zipkin的形式,常用的还有Zuul实现路由网关的功能,由于项目中没用,这里不做介绍
Eureka(client+server)提供了服务注册和服务发现的功能
Config(client+server)提供每个service的相关配置动态获取
Feign:提供了负载均衡和熔断的功能,即 Ribbon和Hystrix的功能
Sleuth+Zipkin:提供了每个service之间相互调用的链路追踪的功能
整个架构的流程大致是这样的:
1、先启动服务注册中心(eureka server),单独的一个service
2、再启动配置中心(config server+eureka client),单独的一个service
3、启动Zipkin.jar,这是官方提供的一个jar包,在启动时指定mysql路径,为了方面这里我们称为zipkin server
3、启动业务service-1(包含了eureka client+config client+sleuth+zipkin client),service-1提供一个接口(定义为接口A)供service-2调用
4、启动service-2(包含了eureka client+config client+sleuth+zipkin client+feign)
每当service-1、service-2启动的时候通过eureka client向服务注册中心注册服务,通过config client向配置中心请求数据,配置中心则通过远端的git仓库拉取数据,service-2通过feign调用service-1的接口A,如果我们启动了两个service-1,则feign就会根据默认的负载均衡规则选择调用恰当的service-1实例,如果接口A超过一定时间没有响应则会进入熔断(Hystrix)的逻辑。Feign是这么知道service-1的地址呢?就是通过注册中心(eureka server),service-2调用service-1的A接口,这条接口调用记录会被sleuth+zipkin client 采集并通过ip+端口的形式传给 zipkin server 最终写入zikpin server关联的数据库中,不可能每条都要被记录,这样会很耗性能,所以可以设置采样率,一般设置为1%。
由上面的流程可以清楚的知道注册中心和配置中心的重要性,因此都要做成高可用模式
补充:
config 是支持实时刷新的,即,远端git仓库更新了service的相关配置,会自动更新每个service的配置,看起来很高大上,其实没啥卵用,因为service的配置很多都是不支持热更新的,即,在运行状态下不可修改,支持热更新的配置很少很少,大部分配置都是在启动后不可修改
SpringCloud 入门可以参考这篇文章:点击打开链接
在学习SpringCloud之前建议先看看《微服务:从设计到部署》这本书,对微服务有个整体的认知
Docker(已改名为 Moby):
什么是Docker?Docker有哪些优势?这类问题,网上一搜有很多答案,用了Docker后最大的感觉就是不用因为要换服务器而再重复的配置各种东东啦,像我之前要部署ELK,换台服务器就要重配置一下,费事费力,用了Docker以后只要pull一下已经做好的image 然后run 一下就行了,省时省力,当然docker还有其他许多优点,比如:隔离性,一致性环境 ,便于排错等等。
Docker中的几个概念:
1、dockerfile:制作image的DSL
2、layer:在dockerfile文件中每一行就是一层,每一层最终会变成文件,所以在dockerfile中不要存在不必要的东西,少换行
3、image:将应用打包好之后的存储方式,一个image包含多层layer
4、镜像仓库:存放image的地方,便于image的重复利用,别人要是想用这个image直接pull就可以了
5、container:容器,run后的image,包含了文件资源(image展开)和系统资源(变成process存在于系统中)
6、docker-compose:一中编排工具,用于一次性 run 多个image
7、docker swarm:docker自己的容器调度平台
8、kubernetes:google推出的容器调度平台,渐渐成为主流
docker是不支持容器的跨主机通信的,同宿主机中得不同container之间通过docker0网桥进行通信,如果要实现container的跨主机通信,需要另行配置一些东西
Docker学习推荐《Docker-从入门到实践》在线阅读地址:点击打开链接
Kubernetes:
当容器部署的越来越多,部署到不同的宿主机,怎么去管理这些容器?怎么更有效率的进行业务的平行扩展?等等一系列问题,有了K8s就很方便的处理。Kubernetes是Google的开源系统,用来自动部署、缩放和管理容器应用。它可以使用多语言并且提供原语服务开通、运行、缩放和分布式系统管理。
Kubernetes学习 推荐《Kubernetes权威指南:从Docker到Kubernetes实践全接触(第二版)》,对K8s有个整体的认知,虽然K8s更新的很快,但是主体架构是不会变的,更多的是逐步完善。
由上图可知K8s中分为Master节点和Work节点,Master管理这些Work节点,Work节点实际上就是跑容器的主机
K8s中有几个很重要的概念:
Pod:
K8s最小的调度单位,里面存放的是业务容器,一个pods拥有一个IP,内部可以有一个或多个业务容器(容器解耦),endpoint 是pod的入口,在pod里会运行一个特殊的容器,pod中的其他业务容器共享该容器的网络栈和volume挂载卷
Service:
是对一组Pod的抽象,它会根据访问策略(如负载均衡策略)来访问这组Pod。每个Service都有个Cluster IP用于集群内部通信,当然也可以映射一个端口到宿主机,使得外部能访问,一个Service相当于实现了某个功能的微服务,而Pod副本的个数相当于这个微服务有多少个实例。
NameSpace:
Namespace在很多情况下用于实现多租户的资源隔离。Namespace通过将集群内部的资源对象“分配”到不同的Namespace中,形成逻辑上分组的不同项目、小组或用户组,便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。
下面三个是在Master节点上运行的服务
ApiServer:
对内:集群内各个模块之间数据交互和通信的中心枢纽,在master上执行的yaml文件通过apiserver与node节点的kubelet交互,通过kubelet在node节点上创建相应的pod
对外:提供了API入口(URL地址),用于查看pod的详细信息等等
Schedule:
主要功能是选择恰当的Work节点,并执行Pod副本
ControllerManager:
集群内部的管理控制中心,包含多个Controller,比如 ReplicationController、ResourceQuotaController、NameSpaceController等等
下面两个Work节点上运行的服务:
Kubelet:
配合API Server 完成Pod的创建、删除、管理等操作
kubelet作为连接Kubernetes Master和各节点机之间的桥梁,管理运行在节点机上的Pod和容器。kubelet将每个Pod转换成它的成员容器,同时从cAdvisor获取单独的容器使用统计信息,然后通过该REST API暴露这些聚合后的Pod资源使用的统计信息。
Kube-proxy:
kube-proxy进程获取每个Service的Pod副本的Endpoints,核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上,实现了Service的负载均衡功能。
配置好K8s后work节点相关信息会被保存到master节点中的etcd中,如果想要运行某个微服务大致过程是这样的。这里以ReplicationController为例(其核心作用是确保在任何时候集群中一个RC所关联的Pod副本数量保持预设值),编写好相应的RC.yaml文件,和Service.yaml文件,在Master节点上使用kubectl命令运行RC.yaml文件该命令,首先会通过scheduler选择合适的work节点,然后通过apiserver和work节点的kubelet交互,由kubelet创建对应得Pod,假如Pod中需要运行2个容器,但实际上k8s会运行3个容器,2个业务容器和一个特殊的容器,这两个业务容器会共享这个特殊容器的ip和volume。
额外补充:
1、K8s本身并不会对跨主机容器网络进行设置,需要额外的工具实现容器的跨主机通信,比如 Flannel。
2、在Kubernetes中,每个Service之间是通过Cluster IP进行通信的,为了能够通过服务的名字在集群内部进行Service的相互访问,则需要创建一个DNS服务完成服务名到Cluster IP的解析
Rancher:
Rancher是一个开源的企业级容器管理平台。通过Rancher,企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台。
简单来说,Rancher可以让我们快速的部署K8s,Rancher有两个版本1.6和2.x,主要区别在于1.6的版本支持多种容器调度工具,
比如:Docker Swarm、Kubernetes、Mesos和Rancher自己的Cattle,要支持那么多容器调度工具是很吃力的,2.x重心放在了K8s上,可见Rancher在压宝K8s。
rancher官网点击打开
本文只做简单的概述,下一篇将使用Rancher2.0将SpringCloud项目部署到K8s上
更多推荐
所有评论(0)