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

Kubernetes: What's the idiomatic way in K8s to setup a custom proxy between ingress and its services?

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

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

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

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

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

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

Ocelot 放在 nginx ingress 后面完全符合要求

Ocelot 是一个 .NET API 网关。该项目针对使用 .NET 运行微服务/面向服务的体系结构的人们，这些体系结构需要一个统一的入口点进入他们的系统。但是，它可以在 ASP.NET Core 支持的任何平台上与任何使用 HTTP 和运行的东西一起使用。

Ocelot目前被微软和腾讯使用

自定义中间件和header/query/claims转换解决了我的问题。这里有一些有价值的链接

有关 Ocelot 功能的快速列表，请参阅 documentation。