问题标签 [ingress-nginx]

我们将 Kubernetes 入口与外部服务JWT 身份验证一起auth-url用作入口的一部分。

现在我们要使用auth-cache-key注解来控制 JWT 令牌的缓存。目前，我们的外部身份验证服务只是通过查看令牌来响应200/ 。401我们所有的组件都是带有rest api的后端微服务。传入的请求可能不是 UI 请求。我们如何为传入的 JWT 令牌填写“auth-cache-key”。

看例子，$remote_user$http_authorization在K8s文档中被指定为例子。但是不确定是否$remote_user会在我们的案例中设置。因为这不是外部基本身份验证。在这种情况下，我们如何决定 auth 缓存键？

这方面没有足够的示例/文档。

我注意到在ingress-nginx pod 创建/终止期间，创建了大量事件。进一步“调查”表明每个 nginx pod 创建

每个入口对象的事件。

为了透视，用一些近似的虚数：

• 所有 ingress-nginx pod 都将终止的那一刻kubectl rollout restart ingress-nginx（不是同时，因为有适当的 PDB 设置）。
• 在重启期间，每个 pod 都会sync为集群中的每个入口对象创建事件对象。
• 因此，如果有 100 个带有 500 个入口对象的 ingress-nginx pod，那将跨越 50k 个同步事件。

我在 docs/ingress-nginx 问题中找不到任何关于它的提及

问题：这是预期的行为吗？

我最近升级ingress-nginx到版本 1.0.3。

结果，我kubernetes.io/ingress.class从我的入口中删除了注释，并.spec.ingressClassName改为放置。

我正在跑步cert-manager-v1.4.0。

今天早上我收到一封电子邮件，说我的 Let's Encrypt 证书将在 10 天后过期。我试图弄清楚它有什么问题 - 不能肯定这完全是由于 ingress-nginx 升级造成的。

我删除了CertificateRequest，看看它是否会自行修复。我得到了一个新Ingress的挑战，但是：

1. 挑战入口的kubernetes.io/ingress.class注释设置正确，即使我的入口有.spec.ingressClassName- 不知道如何或为什么，但似乎应该没问题。

2. 但是，入口控制器没有接收到挑战入口，它说：

ingress class annotation is not equal to the expected by Ingress Controller

我想它只需要.spec.ingressClassName即使我认为注释也应该工作。

所以我手动设置.spec.ingressClassName了挑战入口。入口控制器立即看到了它，其余的过程运行顺利，我得到了一个新的证书 - 耶。

在我看来，这种情况会再次发生，所以我需要知道如何：

1. 说服使用而不是cert-manager创建挑战入口。也许这在 1.5 或 1.6 中已修复？.spec.ingressClassNamekubernetes.io/ingress.class

2. 说服ingress-nginx尊重kubernetes.io/ingress.class挑战入口的注释。我不知道为什么这不起作用。

有时候我们会遇到一些 nginx 漏洞，所以需要修复 ingress-nginx 内部的 nginx 漏洞，但是 docker build -t 镜像太慢了。原因是dockerfile内部会make compile和make install过程。如何添加一些参数可以使 docker build 过程更快？

虽然docker构建过程提示make添加-j参数增加线程来加速进程，但是dockerfile里面并没有make相关的参数。直接修改 dockerfile 不是一个好主意。

dockerfile 的来源。

我在为我为多个子域创建的入口对象设置入口控制器 LB IP 时遇到问题。

当我检查创建的入口时，我可以看到附加的外部 IP。我想为他们使用入口控制器 LB IP。

你能帮忙吗？

如标题所述，我目前在 gke v1.20.10 上有 2 个 ingress-nginx v1.0.0 的配置。

当我单独部署一个配置时，配置正在工作并且我没有问题，但是当我部署第二个验证webhook然后尝试部署一个入口时，2个验证webhook尝试评估新创建的入口。

这会导致此错误：

我检查了一下，一切似乎都正确分离了，我的验证网络钩子就是这样部署的，{{ ingress_type }} 是 -public 或 -private 的占位符：

我似乎找不到解决方案，有一个旧的 github 问题没有答案，也许我做错了什么，但我看不到它。

正如评论中所问的，这是我正在尝试部署的入口示例，只有一个入口，而不是两个入口，这工作得很好：

我已经 helm 安装到我的 EKS 集群中的ingress-nginxpod 总是失败，它的日志表明应用程序无法绑定到0.0.0.0:8443( INADDR_ANY:8443)。我已经确认它0.0.0.0:8443确实已经绑定在容器中，但是我还没有对容器的 root 访问权限，我无法收集罪魁祸首进程/用户。

我在我正在使用的 kubernetes ingress-nginx 项目上创建了这个问题，但也想接触更广泛的 SO 社区，他们可能会为如何克服这个障碍提供见解、解决方案和故障排除建议。

作为 AWS/EKS 和 Kubernetes 的新手，可能存在一些环境配置错误导致此问题。例如，这可能是由错误配置的 AWS 主义（例如 VPC（其子网或安全组））引起的吗？预先感谢您的帮助！

链接的GitHub 问题提供了有关 Terraform 配置的 EKS 环境以及 Helm 安装的ingress-nginx. 以下是一些关键细节：

1. EKS 集群配置为仅使用 Fargate 工作程序，并具有 3 个公共子网和 3 个私有子网，所有 6 个子网均可供集群及其每个 Fargate 配置文件使用。
2. 还应该注意的是，集群是新的，ingress-nginx pod 是第一次尝试将任何东西部署到集群，除了 kube-system 项目，如 coredns，它已配置为在 Fargate 中运行。（这需要手动删除默认的 ec2 注释，如此处所述）
3. 有 6 个 fargate 配置文件，但目前只有 2 个正在使用：coredns和ingress. 这些分别专用于 kube-system/kube-dns 和 ingress-nginx。除了选择器的命名空间和标签之外，配置文件规范没有任何“自定义”。已确认选择器对 coredns 和 ingress 都有效。即，入口 pod 计划运行，但失败了。
4. 使用端口 8443的原因ingress-nginx是我第一次遇到了这个 Privilege Escalation 问题，其解决方法需要禁用allowPrivilegeEscalation并将端口从特权端口更改为非特权端口。我正在调用helm install以下值：

5. 正如我最初的观察结果（在我查看日志之前）是 K8s 活跃度/就绪度探测失败/超时，我首先尝试initialDelaySeconds在传递给 helm install 的值中扩展它们。但最终我查看了 pod/container 日志，发现无论 *ness 探针设置如何，每次我重新安装ingress-nginxpod 并稍等片刻，日志都会显示这里报告的相同绑定错误：

我正在尝试使用服务监视器部署入口控制器，我正在使用如下所示的 helm values 文件：

当我使用提供的值文件运行 helm 模板时，服务监视器不可见。

有没有人有类似的问题？提前感谢您的回复。

我在我的 GKE 集群中使用 ingress-nginx 来公开我的服务。我有 2 个不同的 GKE 集群（v1.19.12-gke.2101），它们都使用 ingress-nginx（图表 v4.0.6）。

在这些集群上，我使用 oauth-proxy 公开一些服务。它在第一个集群上完美运行，但在路径/test/上有 404 的第二个集群上却不行。我已经调查了很长时间，但没有找到可能导致此问题的原因。我发现的主要区别在于位置不同的nginx.conf文件。这是区别：

第一个集群（工作）：

第二个集群（不工作）：

这是用于此行的入口：

我检查了所有配置文件（入口、服务），没有发现任何差异。如果您知道问题可能出在哪里，请告诉我。

谢谢你的帮助。

我正在运行 2 个 ingress-nginx 控制器，一个是外部的，一个是内部的，一切正常，流量正在流动，但由于某种原因，我的 kubernetes 入口资源没有显示控制器的地址

一切正常，但地址没有显示让我很困扰；我的控制器已正确部署

ingress-nginx/ingress-nginx helm 图表的值如下所示

和

我的 kubernetes 入口资源看起来像这样

我的 IngressClass 看起来像这样

最重要的是，在此更改之前，我正在运行相同的外部和内部入口，controllerValue因此入口类看起来像这样

一切正常！！！！！！，但该场景中的入口显示错误的地址并显示它们与错误的入口控制器通信；像这样（注意外部和内部都显示外部IP）

而且他们工作正常！！，流量按预期进行-从我的角度来看，这只是一个视觉错误）-我的问题是，其他人也遇到过吗？或者知道如何修复它并使 kubernetes 正确显示入口从控制器获取的地址？