Kubernetes:在 K8s 中，在入口及其服务之间设置自定义代理的惯用方式是什么？

Question

目前，我们有很多托管在本地的 ASP.net WebAPI 服务应用程序。我们计划将这些移动到 Azure AKS。我们已经确定了这些应用程序中的许多通用代码，这些代码主要是作为 ASP.Net 可重用中间件组件实现的，因此逻辑不会在代码中重复。

在 K8s 环境中，将这一通用功能卸载到一个或多个代理应用程序是有意义的，这些代理应用程序拦截从入口转发到服务的请求(假设这是正确的方法)。一些请求检查/操作逻辑基于要在入口中定义的服务主机和路径，甚至基于传入请求中的 header 。

例如我考虑过使用 OAuth2_proxy，但发现即使身份验证很容易实现，基于 Azure AD 组的授权也不可能开箱即用。那么设置这样一个自定义代理应用程序的惯用方式是什么？ (我熟悉在 ASP.Net 中使用 ProxyKit 中间件等库来开发 http 代理。)

想到的一种方法是在每个服务应用程序 pod 中部署这样的代理作为 sidecar 容器，但这意味着每个 pod 中的所有此类重复容器实例都会使用不必要的资源。我看不到使用前面提到的中间件组件的好处。 :(

理想的设置是入口 --> 自定义代理 1 --> 自定义代理 2 --> 自定义代理 n --> 服务，其中自定义代理可以单独部署和扩展。

Answer 1

因此，经过大量阅读和谷歌搜索后，我发现解决方案是使用可用作库的 API 网关(最好基于 .Net):

Ocelot放置在 nginx 入口后面完全符合要求

Ocelot 是一个 .NET API 网关。该项目面向使用 .NET 运行微服务/面向服务的架构的用户，他们需要一个统一的系统入口点。但是，它适用于任何使用 HTTP 并在 ASP.NET Core 支持的任何平台上运行的东西。

Ocelot 目前被微软和腾讯使用。

自定义中间件和 header /查询/声明转换解决了我的问题。这里有一些有值(value)的链接

Microsoft Docs: Implement API Gateways with Ocelot

Ocelot on Github

Ocelot Documentation

特征

有关更多信息的 Ocelot 功能快速列表，请参阅 documentation .

路由

请求聚合

Consul 和 Eureka 的服务发现

服务结构

Kubernetes

网络套接字

认证

授权

限速

缓存

重试策略/QoS

负载均衡

记录/跟踪/关联

标题/查询字符串/声明转换

自定义中间件/委托(delegate)处理程序

配置/管理 REST API

平台/云不可知