k8s两种部署架构，你们是哪一种？为什么面试官会问你你们怎么部署微服务的呢？
k8s部署的两种策略
干货：
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配置，忘记的话我贴一张图就知道了。
server name：域名 proxy_pass: 反向代理 upstream：负载均衡 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为例：
用户先创建Pod运行自己的服务。 然后创建service关联相关Pod。 最后研发人员提交ingress.yaml创建ingress对象，关联service。 ingress controller就会实时watch到ingress的变化然后创建upstream负载均衡和反向代理。
按照1-4创建完成之后我们接下来做两件事：
创建slb负载均衡器(后面挂载Node)，拿到公网IP地址。 申请域名解析，将域名解析到slb上(A记录)。
到这里我们的服务就算是搭建起来了，接下来跑通它：
用户先访问baidu.com dns解析返回slb地址是192.169.1.1 slb选择一台机器，假如选中Node1 请求转发到Node1这个机器上 Node1上的ingress controller就会收到用户的请求 ingress controller就会根据server name(baidu.com)通过proxy_pass代理到upstream这个负载均衡上 upstream就会按照RR或者其它方式去访问后端的Pod IP Pod将请求转到服务进程(iptables的portmapping插件实现的) 服务进程处理完成之后做出响应
那大家可能会问，既然将请求转发到一个Node上了，为啥这个Node可以轮训或者别的方式访问别的Node的Pod呢？答案就是CNI，这个大家自己下去了解哈，听有意思的。
好了，至此我们微服务部署架构就搭建好了，赞。
3. gateway+registry+pod 模式
从上图可以看出基于网关的这套架构模式基本上也是利用k8s核心对象构建起来的，只不过将原来的ingress用现在的网关代替了而已。
服务搭建流程：
先创建pod，把服务跑起来 pod将自己的服务名称以及IP:Port注册到注册中心，这里以nacos为例 注册中心记录服务名称到Pod IP：Port的映射 网关也将自己的地址注册到服务注册中心
用户访问流程：
用户访问网关地址http://baidu.com/order dns返回网关ip 发起tcp连接(网关ip+端口) 网关收到服务请求之后根据path(/order)路由到nacos-order-service 网关去服务注册中心去找nacos-order-service的映射 根据pod IP:Port发起后端服务请求 Pod将请求转到服务进程(iptables的portmapping插件实现的) 服务进程处理完成之后做出响应
4. 小结
目前据我了解就是这两种基于k8s的部署方案，这两套部署方案都在被广泛使用，所以谁好谁坏不好说，因为业务不同或者场景不同可能选择的部署架构方案有差别，但是无论选择那种部署方案，相关人员都要有基本的维护能力，否则出了问题就两眼抹黑了。