关于云计算:深入浅出-Kubernetes-项目网关与应用路由

KubeSphere 我的项目网关与利用路由提供了一种聚合服务的形式，将集群的外部服务通过一个内部可拜访的 IP 地址以 HTTP 或 HTTPs 裸露给集群内部。利用路由定义了这些服务的拜访规定，用户能够定义基于 host 主机名称和 URL 匹配的规定。同时还能够配置 HTTPs offloading 等选项。我的项目网关则是利用路由的具体实现，它承载了流量的入口并依据利用路由规定将匹配到的申请转发至集群内的服务。

整体架构

用户的服务和利用路由的架构密不可分，因而咱们须要联合用户服务来了解我的项目网关的整体架构。一个典型生产环境中，我的项目网关架构如下图所示：

图中组件共分为四个局部:

1. Nginx Ingress Controller 是利用网关的外围组件。KubeSphere 我的项目网关基于 Nginx Ingress Controller 实现，它通过获 Ingress 对象生成 Nginx 反向代理规定配置并配置利用于 Nginx 服务。利用路由是一个 Ingress 对象。利用网关依赖于 Service 对外裸露 Nginx 服务，因而 Service 在生产环境中个别设置为 LoadBalancer 类型，由云服务商配置其私有云 IP 地址及内部负载均衡器，用以保障服务的高可用性。
2. 内部负载均衡器，利用网关的 Service 生成的内部负载均衡器，个别由各个云服务商提供。因而每种负载均衡器的个性有很多差异，比方 SLA、带宽、IP 配置等等。咱们个别能够通过服务商提供的注解对其进行配置，在设置网关时，咱们通常须要理解这些个性。
3. DNS 域名解析服务，个别由域名服务商提供服务，咱们能够配置域名解析纪录将域名指向 LoadBalancer 的公网 IP。如果子域名也指向同一 IP，咱们能够可应用泛域名解析形式。
4. 用户服务与利用路由，用户须要为应用程序创立 Service 用于裸露集群内的服务，而后创立利用路由对外裸露服务。注，Nginx Ingress Controller 并不通过 Kube-proxy 拜访服务 IP。它通过服务查找与之关联 POD 的 EndPoint，并将其设置为 Nginx 的 Upstream。Nginx 间接连贯 POD 能够防止由 Service 带来的额定网络开销。

利用路由 vs Service(type=LoadBalancer)

在实际过程中，利用路由与 Service 的利用场景经常令人混同。它们都能够向集群外裸露集群内服务，并提供负载平衡性能。并且利用路由看起来也是 依赖 于服务的，那么他们到底有何区别呢？这个问题咱们须要从以下几个角度了解。

1. Service 最后的设计动机是将某个服务的后端 (Pod) 进行形象并公开为网络服务。它通常是以一个服务为单位的，所有后端均运行雷同的服务端。而 利用路由 的设计指标是对 API 对象进行治理。它尽管也能够裸露一个服务，然而它更弱小的性能在于其能够将一系列服务进行聚合，对外提供对立的拜访 IP、域名、URL 等。
2. Service 工作在 TCP/IP 协定的第四层，因而它应用 IP+ 端口 + 协定 三元组作为服务的惟一标识。因而当咱们须要裸露一个服务时，它不能与其余已存在的服务抵触。例如，咱们裸露基于 HTTP/HTTPs 的服务时，通常这类服务都会占用 80、443 端口，为了防止端口抵触，就须要为每个裸露的服务申请一个独立的 IP 地址，导致资源节约。 利用路由 工作在七层，所有通过利用路由裸露的服务都能够共享我的项目网关的 IP 地址和 80、443 端口。每个 利用路由 应用 Host+URL 作为服务的惟一标识, 将 HTTP 申请转发到后端服务中。
3. Service 反对 TCP 与 UDP 协定并且对下层协定没有限度，而利用路由目前只反对 HTTP/HTTPs 或 HTTP2 协定，无奈转发基于 TCP 或 UDP 的其余协定。

联合以上三点，咱们不难得看出：利用路由更实用于应用 HTTP 协定的微服务架构的场景中，而 Service 尽管对 HTTP 协定没有深度的反对，然而它能够反对更多其余协定。

利用路由 vs Spring Cloud Gateway 或 Ocelot

Java、.net Core 的开发人员对 Spring Cloud Gateway 或 Ocelot 肯定不会感到生疏，他们是各自语言畛域中最罕用的 API 网关。那么到咱们是否能够间接应用这些网关呢？了解这个问题，咱们首先要晓得什么是 API 网关，在 Wiki 百科中 API Gateway 并没有一个明确的定义，但咱们从各个大厂的服务阐明中能够得出一个根本的论断：

API 网关作为用户与后端服务之间的惟一入口治理后端服务，即 API 网关提供了一个方向代理服务将后端服务进行聚合，将客户端申请路由到后端服务并将后果返回给客户端。同时,API 网关可提供身份认证、监控、负载平衡、HTTPS offloading 等高级性能。

因而，利用路由承当了 API 网关的职责，即它与 Spring Cloud Gateway 或 Ocelot 等 API 网关具备等同位置。诸如 Spring Cloud Gateway 类的 API 网关通过 Service 的形式裸露到集群内部也可代替局部利用路由性能。咱们接下做一个简要的比照，并剖析一下他们的优缺点:

1. 作为利用网关的根本职责，它们均具备路由转发性能。并且以上提到的网关均反对基于 HOST、URL 的路由转发规定设置。
2. 服务注册与发现，Spring Cloud Gateway 等全家桶式解决方案提供了十分丰盛的反对选项，对于 java 开发者更为敌对，网关上的服务均可通过注册核心服务无缝连接。而 Ocelot 尽管未内置服务发现与注册计划，然而能够通过 Ocelot + Consul 的形式实现。比照之下 Kubernetes 集群中部署利用，个别采纳基于 DNS 的服务发现形式，但并没有为客户端提供一个对立的服务注册发现形式。对外裸露的服务须要显示的创立 Ingress 规定。相比之下 Spring Cloud Gateway 类的 API 网关应用雷同技术栈，这能够极大的简化开发人员的学习老本。
3. 通用性上，Ingress 是云原生背景下 Kubernetes 社区定义的 API 治理标准。KubeSphere 默认采纳 Nginx Ingress Controller实现。同时咱们能够应用任何兼容的第三方 Ingress 控制器进行替换。Ingress 中只定义了根本共性的性能，但网关通常会提供日志、监控、平安等更多通用的运维工具。相比之下，与语言紧密结合的 API 网关通常与开发平台进行绑定，语言互相替代性较差(不愿引入更多技术栈或无客户端集成反对)。性能绝对固定，但大多提供了良好的插件机制，开发人员应用本人相熟的语言进行拓展。
4. 性能方面，毋庸置疑，以基于 Nginx 的 Ingress Controller 为代表的通用型 API 网关，比 Spring Cloud Gateway、Ocelot 等有非常明显的性能劣势。

总体来讲，每种网关都有其优缺点或局限性。在我的项目初期应首先思考利用网关的架构。在基于云原生的场景下，利用路由会是一个不错的抉择。而如果您的团队依赖于开发技术栈，那么罕用技术栈中的 API 网关通常也会作为首选。但这并不意味着它们必须进行二选一，在一些简单场景下咱们能够联合二者的劣势，开发人员应用本人熟知的 API 网关用于服务聚合、认证鉴权等性能，同时在其后方搁置利用网关实现日志监控，负载平衡,HTTPs offloading 等工作。

微软官网微服务架构示例 eShopOnContainers 即采纳了该种混合架构。

入手实战

了解以上利用场景和整体架构后，咱们接下来演示如何在 KubeSphere 中配置我的项目网关和利用路由。以下内容将基于 Weaveworks 的微服务演示我的项目 SockShop 实现。SockShop 是一个典型的前后端拆散架构，它由前端服务 front-end 和若干后端服务 catalogue、carts、orders 等组成。在以后架构下，front-end 除了承当动态页面服务的性能，还承当了后端 API 代理转发的工作。咱们假如以下场景，即由 Nodejs 转发 API 造成服务异步阻塞，从而影响页面性能。因而咱们决定应用 ingress 间接转发服务 catalogue 用以晋升性能。上面咱们看一下具体配置步骤。

筹备工作

1. 在部署 SockShop 之前，咱们首先要配置一个用于演示的企业空间 workspace-demo 和我的项目 sock-shop。具体步骤请参考《创立企业空间、我的项目、帐户和角色》

2) 实现我的项目 sock-shop 的创立后，咱们接下来应用 kubectl 部署 SockShop 的相干服务。您能够应用本地的控制台或 KubeSphere web 工具箱中的 kubectl执行以下命令。

kubectl -n sock-shop apply -f https://github.com/microservices-demo/microservices-demo/raw/master/deploy/kubernetes/complete-demo.yaml

执行过后能够进入 sock-shop 的 工作负载 页面查看部署的状态，期待所有的部署都失常运行后，咱们再进行下一步操作。

我的项目网关配置

1. 进入 sock-shop 我的项目，从左侧导航栏进入我的项目设置下的高级设置页面，而后点击设置网关。
2. 在接下来弹出的对话框中，须要依据 KubeSphere 的装置环境进行设置。如果您应用的是本地开发环境或公有环境能够抉择 NodePort 的形式裸露网关。如果是托管 Kubernetes 云服务，个别抉择 LoadBalancer。

利用路由配置

1. 首先，咱们抉择左侧导航栏 利用负载 中的 利用路由 ，点击右侧的创立。在根本信息中填写名称 frontend。在路由规定中，增加一条新的规定。因为是演示我的项目，咱们应用主动生成模式。KubeSphere 主动以 < 服务名称 >.< 项目名称 >.< 网关地址 >.nip.io 格局生成域名，该域名由 nip.io 主动解析为网关地址。在门路、服务、端口上顺次抉择 “/”、”front-end”、”80″。点击 下一步 后，持续点击 创立。

2. 路由创立实现后，能够在利用路由列表页面点击 frontend 进入详情。并在规定中能够点击 点击拜访 拜访按钮。在新的浏览器 tab 下，应该呈现如下的网站：

3. 为了与上面的步骤进行比照，咱们在 SockShop 的网站页面关上调试性能查看网络申请，以 Chrome 为例只需点击键盘的 F12 键。刷新一下页面后咱们找到如下 catalogue API 申请：

该申请头中的 X-Powered-By:Express 表明了这条申请是由前端的 Nodejs 利用转发。

4. 接下来，在 frontend 的详情页面点击左侧的 更多操作 ，并抉择 编辑规定。在弹出的编辑规定页面，抉择刚刚减少的规定，并点击左侧的编辑图标。新增一条门路，在门路、服务、端口上顺次抉择 ”/catalogue”、”catalogue”、”80″。保留该设置。编辑后的规定如下：

5. 咱们再次拜访 SockShop 的网站页面，该页面并没有任何变动。咱们应用浏览器调试器，再次查看网络申请，catalogue 的申请如下：

咱们发现该申请曾经没有了 X-Powered-By:Express 申请头，这阐明了咱们下面利用的规定曾经失效，catalogue相干的 API 申请曾经通过利用路由间接转发 catalogue 服务了，而不须要再通过 fron-tend 服务进行直达。以上的配置咱们利用了路由规定的最长匹配规定。“/catalogue”比更门路具备更高的优先级。

更多配置内容能够参考《利用路由》

总结

本篇内容简述了利用路由的根本架构，并与 Kubernetes Service 及其他利用网关别离做了比照。最初通过 SockShop 这个案例解说的利用路由的配置办法。心愿读者对利用路由能有进一步的了解，依据利用的个性抉择适合的内部服务裸露形式。

本文由博客一文多发平台 OpenWrite 公布！