k8s,spring cloud gateway,nginx搭建随笔

hyxinyu 2020-06-10

最近完成了基于k8s的springcloud搭建,记录下过程。

K8S的组件介绍

Pod

一个Pod是一组容器的集合,它们共享网络,我们的微服务注册中心是Consul,微服务的容器和Consul客户端的容器组成了一个Pod.这样微服务访问Consul客户端就像访问本地一样了.使用localhost就可以访问到Consul.然后Consul客户端再和服务端通信.

Service

Service是Pod提供的服务的抽象,因为K8S的Pod的容器是不稳定的,可能会挂掉,这种情况下,K8S就会为我们重新启动POD,维持着指定的状态。Pod里的容器分配的IP是不同的,这就需要通过Service给不同的服务的IP绑定到一个Service名字上,以后通过Servie就能解析出对应的Pod的IP。在同一个K8S集群中,Service的name还充当着DNS-Name,需要在Pod-A里访问另一个Service里的Pod-B时(比如应用需要访问另一个Service提供的Redis的服务),使用Servie name就可以解析出名字。

Deployment

Deployment控制RS,RS控制Pod,这一整套,向外提供稳定可靠的Service。至于什么是RS,笔者目前还没有深入了解,项目中这个概念也比较淡化,先搁置了。

ConfigMap

ConfigMap可以把配置或者配置文件挂载到容器中,生命周期和Pod独立

PersistVolume(PV)和PersisteVolumeClaim(PVC)

k8s中的存储系统,生命周期和容器独立的存储。可以声明把pvc挂载到容器的某一个目录。pv是由集群管理员管理的,我们不用管。

Ingress

Ingress主要负责路由。项目由于是前后端分离,所有的请求都要先经过nginx,所以Ingress这一层需要先把所有请求都转发到nginx。有没有更好的路由方式笔者还不知道,需要继续学习。

Nginx

请求转发到Nginx之后,Nginx继续对请求进行转发:如果请求的是页面,css,html这些静态资源,就直接在nginx服务器中访问;如果要访问RestApi,就对请求进行转发,转发到Spring cloud gateway里。
这里要注意的地方是localtion的配置,请求api需要在location那里加上proxy_pass ,server_name配置的是nginx的service的name。
这里我们对proxy_pass的location设计是使用了/webapi这个来进行动静分离。

Spring cloud gateway

微服务的网关接到来自nginx的请求,会根据网关的application.yml中配置的转发规则进行转发。对/webapi开头的,会使用 -StripPrefix=1的fitler,这样网关转发到微服务的时候就会把/webapi去掉

相关推荐