首页  思维导图  详情

为什么面试官会问你怎么部署k8s微服务的呢？

2023-11-07 18:39:28   11  举报





AI智能生成

如何为服务网格选择入口网关？负载均衡、反向代理、SSL终止、TLS终止、网络路由、服务路由、监控检查网关、注册中心 domain+slb+ingress+svc+pod 模式 gateway+registry+pod 模式

k8s service负载均衡

k8s 微服务

网关部署方案

注册中心的集群部署架构

作者其他创作

大纲/内容

1. 名词介绍

ingress

介绍

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

ingress生产的背景，应用场景和竞争对手、相关的技术

ingress是干什么的？

Ingress是Kubernetes集群中的服务入口，提供负载均衡、SSL终止和基于名称的虚拟主机等功能。

ingress的诞生背景

它诞生于Kubernetes社区，是Kubernetes资源类型之一，用于实现通过域名访问Kubernetes内部应用。

ingress的应用场景

Ingress可以配置提供服务外部访问的URL、负载均衡、终止SSL，并提供基于域名的虚拟主机，但不会暴露任意端口或协议。

在生产环境中，Ingress通常部署在所有的Node节点上，为Kubernetes集群中的服务提供入口。

它可以与负载均衡器、反向代理等工具集成，以提供更高级的负载均衡和安全性功能。

Ingress还支持多种协议和端口，可以满足不同类型的应用需求。

ingress的竞争对手

Ingress的竞争对手包括其他反向代理和负载均衡器，例如Nginx、HAProxy等。 这些工具也提供了类似的功能，包括负载均衡、SSL终止和虚拟主机等。

ingress的优势

然而，Ingress具有与Kubernetes集成的优势，可以更方便地管理和扩展集群中的服务。

ingress相关的技术

相关的技术包括Kubernetes的Service和Deployment对象。

Service对象定义了如何将流量转发到后端Pod的规则，而Deployment对象则用于管理Pod的创建、更新和删除。

Ingress与Service和Deployment对象一起使用，可以提供更灵活和可扩展的服务入口解决方案。

总结ingress

总之，Ingress是Kubernetes集群中服务入口的一种解决方案，提供了负载均衡、SSL终止和基于名称的虚拟主机等功能。

它具有与Kubernetes集成的优势，可以方便地管理和扩展集群中的服务。

在生产环境中，Ingress通常部署在所有的Node节点上，可以与负载均衡器、反向代理等工具集成， 以提供更高级的负载均衡和安全性功能。

nginx upstream配置示例

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

说明

server name

域名

proxy_pass

反向代理

upstream

负载均衡

server

就是后端服务IP，对应在k8s中就是一组pod ip。

service 即 svc

说明

有ingress就必须得有svc，因为ingress中的upstream必须要有server ip，而这些server ip 就是来自svc的endpoints（ pod ip集合）

pod

说明

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

服务入口解决方案（如ingress/nginx/HaProxy）的架构包括以下组件

负载均衡器：负载均衡器是将流量分发到后端服务的组件。它可以根据不同的算法和策略来决定流量分配的方式。

负载均衡器是将流量分发到后端服务的组件，他可以根据不同的算法和策略来决定流量分配的方式。

反向代理：反向代理是位于客户端和服务器之间的中间件，用于接收客户端的请求并转发到后端服务。它还可以缓存响应，以提高性能。

反向代理是位于客户端和服务器之间的中间件，用于接收客户端的请求并转发到后端服务。 它还可以缓存响应以提高性能。

SSL/TLS终止：在安全方面，服务入口解决方案需要提供SSL/TLS终止功能，将加密的HTTPS请求转换为普通的HTTP请求，并将请求转发到后端服务。

SSL/TLS终止是指在安全方面，服务入口解决方案需要提供SSL/TLS终止功能， 将加密的HTTPS请求转换为普通的HTTP请求，并将请求转发到后端服务。

路由和负载均衡规则：服务入口解决方案需要提供路由和负载均衡规则，以决定如何将请求转发到后端服务。这些规则可以根据不同的条件和策略进行配置。

路由和负载均衡规则是决定如何将请求转发到后端服务。 这些规则可以根据不同的条件和策略进行配置。

健康检查：服务入口解决方案需要提供健康检查功能，以检查后端服务的可用性和性能。如果后端服务出现故障或性能下降，负载均衡器可以将其从服务列表中移除。

健康检查是指检查后端服务的可用性和性能。 如果后端服务出现故障或者性能下降，负载均衡器可以将其从服务列表中剔除。

总结

不同的服务入口解决方案可能采用不同的架构和技术来实现这些组件。

例如，一些解决方案可能使用Nginx作为反向代理和负载均衡器，而其他解决方案可能使用HAProxy或其他开源软件。

此外，一些解决方案可能使用自定义软件来实现负载均衡、路由和健康检查等功能。

总之，不同的服务入口解决方案可能有不同的架构和技术实现方式，需要根据具体需求进行评估和选择。

两种部署架构

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，这个大家自己下去了解哈，听有意思的。

CNI 即 Container Networking interface

容器网络

说明

一种将多个容器连接在一起的网络技术。

应用场景

 用于实现容器之间的网络通信和数据传输

CNI（Container Network Interface）是一种插件，可以用于在Kubernetes集群中创建和管理容器网络。 在Kubernetes集群中，每个Node都可以通过CNI插件连接到其他Node上的Pod。

CNI插件可以分为三种：Overlay、路由及Underlay。

它们分别提供了不同的网络层解决方案，可以根据实际需求进行选择。

其中，Overlay插件通过叠加网络覆盖整个集群，

路由插件通过路由转发请求，

Underlay插件则通过直接连接物理机来提供网络服务。

总结

总之，Node可以通过CNI访问别的Node上的Pod，并且可以根据实际需求选择不同的CNI插件来实现网络连接。

gateway+registry+pod 模式

从上图可以看出基于网关的这套架构模式基本上也是利用k8s核心对象构建起来的，只不过将原来的ingress用现在的网关gateway代替了而已。

一、服务搭建流程：

先创建pod，把服务跑起来

pod将自己的服务名称以及 ip:port 注册到注册中心，这里以nacos 为例子 

注册中心记录服务名称到 ip:port 的映射

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

二、用户访问流程

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

DNS 返回网关IP

发起TCP连接网关（网关 ip + port）

网关收到服务请求之后根据 path （/order）路由到 nacos-order-service

网关去注册中心去找 nacos-order-service 的映射

网关根据 Pod ip:port 发起后端服务请求

Pod 将请求转到服务进程（通过iptables 的 portmapping 插件实现的）

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

总结

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

 收藏

立即使用