Rancher2.0+Kubernetes（k8s）+Docker+SpringCloud 部署分布式服务

最新推荐文章于 2024-08-12 10:36:02 发布

Creepin_

最新推荐文章于 2024-08-12 10:36:02 发布

阅读量597

点赞数 1

本文链接：https://blog.csdn.net/Creepin_/article/details/103802276

版权

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
4、启动业务service-1(包含了eureka client+config client+sleuth+zipkin client)，service-1提供一个接口（定义为接口A）供service-2调用
5、启动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的配置很多都是不支持热更新的，即，在运行状态下不可修改，支持热更新的配置很少很少，大部分配置都是在启动后不可修改

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的跨主机通信，需要另行配置一些东西

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的解析