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

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配置，忘记的话我贴一张图就知道了。

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 模式

从上图可以看出基于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核心对象构建起来的，只不过将原来的ingress用现在的网关代替了而已。

服务搭建流程：

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

2. pod将自己的服务名称注册到注册中心，这里以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的部署方案，这两套部署方案都在被广泛使用，所以书谁好谁坏不好说，因为业务不同或者场景不同可能选择的部署架构方案有差别，但是无论选择那种部署方案，都要有基本的维护能力，否则出了问题就两眼抹黑了。