目前，我们有很多托管在本地的 ASP.net WebAPI 服务应用程序。我们计划将这些移动到 Azure AKS。我们已经确定了这些应用程序中的许多通用代码，这些代码主要是作为 ASP.Net 可重用中间件组件实现的，因此逻辑不会在代码中重复。
在 K8s 环境中，将这一通用功能卸载到一个或多个代理应用程序是有意义的，这些代理应用程序拦截从入口转发到服务的请求(假设这是正确的方法)。一些请求检查/操作逻辑基于要在入口中定义的服务主机和路径，甚至基于传入请求中的 header 。
例如我考虑过使用 OAuth2_proxy，但发现即使身份验证很容易实现，基于 Azure AD 组的授权也不可能开箱即用。那么设置这样一个自定义代理应用程序的惯用方式是什么？ (我熟悉在 ASP.Net 中使用 ProxyKit 中间件等库来开发 http 代理。)
想到的一种方法是在每个服务应用程序 pod 中部署这样的代理作为 sidecar 容器，但这意味着每个 pod 中的所有此类重复容器实例都会使用不必要的资源。我看不到使用前面提到的中间件组件的好处。 :(
理想的设置是入口 --> 自定义代理 1 --> 自定义代理 2 --> 自定义代理 n --> 服务，其中自定义代理可以单独部署和扩展。
最佳答案
因此，经过大量阅读和谷歌搜索后，我发现解决方案是使用可用作库的 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 .
关于Kubernetes:在 K8s 中，在入口及其服务之间设置自定义代理的惯用方式是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57782492/