k8s两种部署架构,你们是哪一种?为什么面试官会问你你们怎么部署微服务的呢?

k8s两种部署架构,你们是哪一种?为什么面试官会问你你们怎么部署微服务的呢?_第1张图片

k8s部署的两种策略-[公粽号:堆栈future]

原文
干货:


domain+slb+ingress+svc+pod 模式

gateway+registry+pod 模式


通过这篇文章我们可以看出,为啥上篇文章需要讲解网关了,因为这篇文章需要用到它,网关很重要哦。

还有一个问题就是面试官老是会问你们的部署架构是怎样的,其实这个问题挺简单的,只不过各大公司业务不同,体量不同还有场景不同选择的部署架构有差别,但是总体而言基于k8s的部署无非就这两种,只不过细节上略有差别,今天主要聊聊这两种最基本的基础部署架构。

1. 名词介绍

1. ingress

ingress是公开了集群外部访问集群内部服务的HTTP(S)路由,流量路由ingress定义的规则控制。

也就是说:ingress是创建一组路由规则,这个规则会经过k8s API Server存储到etcd中,而处理ingress规则的controller就是ingress controller。它实时监听ingress资源对象,然后在本地生成反向代理upstream负载均衡配置,这里大家可以想像下Nginx的upstream配置,忘记的话我贴一张图就知道了。

k8s两种部署架构,你们是哪一种?为什么面试官会问你你们怎么部署微服务的呢?_第2张图片

  1. server name:域名

  2. proxy_pass: 反向代理

  3. upstream:负载均衡

  4. server:就是后端服务IP,对应在k8s中就是一组pod ip。

2. service 即svc

有ingress必须得有svc,因为ingress中的upstream必须要有server ip,而这些server ip就是来自svc的endpoints(pod ip集合)。

3. pod

真正运行docker容器的(我们的服务就跑在这个上面),它有自己的ip地址,在建立svc之后,当我们通过yaml资源创建pod的时候,pod根据label会走自动挂载到svc上,这样svc就能获取到后端pod ip列表,即endpoints。

好了,有了这些概念我们就开启讲解两套部署模式吧。

2. domain+slb+ingress+svc+pod 模式

k8s两种部署架构,你们是哪一种?为什么面试官会问你你们怎么部署微服务的呢?_第3张图片从上图可以看出基于ingress的这套架构模式基本上是利用k8s核心对象构建起来的。

我们这里以nginx为例:

  1. 用户先创建Pod运行自己的服务。

  2. 然后创建service关联相关Pod。

  3. 最后研发人员提交ingress.yaml创建ingress对象,关联service。

  4. ingress controller就会实时watch到ingress的变化然后创建upstream负载均衡和反向代理。

按照1-4创建完成之后我们接下来做两件事:

  1. 创建slb负载均衡器(后面挂载Node),拿到公网IP地址。

  2. 申请域名解析,将域名解析到slb上(A记录)。

到这里我们的服务就算是搭建起来了,接下来跑通它:

  1. 用户先访问baidu.com

  2. dns解析返回slb地址是192.169.1.1

  3. slb选择一台机器,假如选中Node1

  4. 请求转发到Node1这个机器上

  5. Node1上的ingress controller就会收到用户的请求

  6. ingress controller就会根据server name(baidu.com)通过proxy_pass代理到upstream这个负载均衡上

  7. upstream就会按照RR或者其它方式去访问后端的Pod IP

  8. Pod将请求转到服务进程(iptables的portmapping插件实现的)

  9. 服务进程处理完成之后做出响应

那大家可能会问,既然将请求转发到一个Node上了,为啥这个Node可以轮训或者别的方式访问别的Node的Pod呢?答案就是CNI,这个大家自己下去了解哈,听有意思的。

好了,至此我们微服务部署架构就搭建好了,赞。

3. gateway+registry+pod 模式

k8s两种部署架构,你们是哪一种?为什么面试官会问你你们怎么部署微服务的呢?_第4张图片从上图可以看出基于网关的这套架构模式基本上也是利用k8s核心对象构建起来的,只不过将原来的ingress用现在的网关代替了而已。

服务搭建流程:

  1. 先创建pod,把服务跑起来

  2. pod将自己的服务名称以及IP:Port注册到注册中心,这里以nacos为例

  3. 注册中心记录服务名称到Pod IP:Port的映射

  4. 网关也将自己的地址注册到服务注册中心

用户访问流程:

  1. 用户访问网关地址http://baidu.com/order

  2. dns返回网关ip

  3. 发起tcp连接(网关ip+端口)

  4. 网关收到服务请求之后根据path(/order)路由到nacos-order-service

  5. 网关去服务注册中心去找nacos-order-service的映射

  6. 根据pod IP:Port发起后端服务请求

  7. Pod将请求转到服务进程(iptables的portmapping插件实现的)

  8. 服务进程处理完成之后做出响应

到这里基于网关的这套部署架构就讲解完了,赞。

4. 小结

目前据我了解就是这两种基于k8s的部署方案,这两套部署方案都在被广泛使用,所以谁好谁坏不好说,因为业务不同或者场景不同可能选择的部署架构方案有差别,但是无论选择那种部署方案,相关人员都要有基本的维护能力,否则出了问题就两眼抹黑了。

k8s两种部署架构,你们是哪一种?为什么面试官会问你你们怎么部署微服务的呢?_第5张图片

公粽号:堆栈future

使很多处于迷茫阶段的coder能从这里找到光明,堆栈创世,功在当代,利在千秋
k8s两种部署架构,你们是哪一种?为什么面试官会问你你们怎么部署微服务的呢?_第6张图片

你可能感兴趣的:(架构,微服务,microservices,k8s,面试)