Docker 使用https和；AKS（azure kubernetes）中的letsencrypt出于某种原因阻止mvcclient设置cookie

到目前为止我的一周： 在过去的几天里，我致力于将identityserver4.net核心应用程序部署到Azure Kubernetes集群（AKS）。出了几个问题后，一切似乎都很好。我们不使用内置的http路由功能，因为出于某种原因，我们不想使用子域进行路由；当启用http路由时，我们似乎无法让letsencrypt工作。我们正在使用https://访问使用nginx托管在AKS中的服务

无论如何。。 当我将一个mvc客户端应用程序部署到AKS时，问题就出现了。客户端的主页按预期工作。当客户端将我重定向到我们的idsrv4服务的登录页面，并且我使用我的凭据登录时：重定向循环开始。我知道这意味着AuthCookie没有正确设置

问题 我发现认证往返在Google Chrome和Firefox中有效，在这些浏览器中没有重定向循环。Edge、IE和Safari不工作，重定向到signin oidc时会导致重定向循环

迄今为止的发现：

我使用本地docker for windows安装测试了mvcclient应用程序。使用HTTP连接（而不是https），往返可以在所有浏览器中工作

当我使用Fiddler和HTTPS decrypt来诊断使用远程AKS中托管的服务的往返时：往返在所有浏览器中都有效

当我断开Fiddler并测试远程AKS中托管的服务时，往返在Edge、IE和Safari中不起作用

---

有人知道我如何配置Nginx以支持所有浏览器设置cookie并转发正确的头文件吗？在这种情况下，IdentityServer 4的要求是什么？在我的clientapplication或identityserver4中是否需要nginx或Cookie身份验证的任何其他配置（除了在startup.cs的identityserveroptions中设置publicorigin）？

在我重新安装了一个新的AKS群集并再次尝试使用标准addon http路由进行加密后，我开始工作，我试了又试，最后想：为什么我的重定向到/signin oidc在Edge和IE中注册为HTTP/2。这是我上周遇到的一系列问题中的主要部分。。。。无论如何：我做了一些研究，并找出了如何将配置的某些部分更新到内置入口控制器（AddonHTTP路由）。适用于在使用AKS（Azure Kubernetes服务）时遇到signin oidc循环的任何人。您可以覆盖AKS中提供的标准http路由插件的配置，并手动禁用http/2（默认情况下启用！）

因为web上几乎没有关于在Azure上配置AKS群集以及Let's Encrypt and addon http routing的信息，这让我有点沮丧&因为我找不到任何关于在Azure的AKS群集中部署IdentityServer 4的信息。我制作了一些.yaml文件（我用来启动和运行所有东西的所有文件），用注释扩展了它们，并将它们发布给希望在Azure Kubernetes服务中安全托管IdentityServer 4的任何人。 这是我有史以来第一次，尽管规模很小，公开捐款。如果有人在使用我的基本Readme.txt实现我的.yaml文件时遇到问题：请告诉我，我会看看我能做些什么