问题标签 [nginx-ingress]

我有一个带有 Docker 容器的微服务架构，现在想迁移到使用 Kubernetes 进行部署。我无法使用 Kubernetes 运行应用程序。网关服务器未连接到服务发现和转发请求。

作为一个演示应用程序，我创建了 4 个服务： - Zuul 服务 - Eureka 服务 - 联系服务 - 用户服务

Githube 存储库 - https://github.com/dhananjay12/spring-microservice-k8s

该应用程序使用 docker-compose 运行良好。我已经创建了图像并推送到了 Dockerhub。

K8s 文件 - https://github.com/dhananjay12/spring-microservice-k8s/tree/master/k8s

为了转发请求，我设置了 Ingress-nginx。

我通过运行以下命令启动了服务：

然后

入口服务.yaml：

请求转到zuul，但日志中出现以下错误：

如果我设置 eureka.instance.preferIpAddress=true 我得到以下异常：

这可能是因为服务必须通过 pod 名称注册。如何处理这种情况，以便每个下游服务通过其集群 IP 进行注册？

我可以nginx ingress controller访问NodePort. 我的目标是在port 80.

的输出kubectl -n ingress-nginx describe service/ingress-nginx

我对解决这个问题的想法很少：

• 将端口 30734 上的流量重定向到端口 80 通过iptables
• 调整节点端口的范围，使端口 80 也可以是节点端口

我不确定这些是否是常见的方法，所以我很想听听您通常如何处理这个问题。可能还需要另一个组件？

环境：Ubuntu 18.06裸机，用kubeadm搭建集群（单节点）

我想通过端口 80 访问集群。目前我可以通过 nodePort：domain.com:31668/但不能通过端口 80 访问它。我正在使用metallb是否需要其他东西来处理传入流量？

所以当前的拓扑是：

负载平衡器 > 入口控制器 > 入口 > 服务

kubectl -n ingress-nginx 描述服务/ingress-nginx：

当我使用裸机环境时，我正在使用metallb.

metallb 配置：

入口控制器 yml 的：

curl -v http://192.168.1.240的输出（在服务器内部执行）

kubectl 描述入口文章服务入口

curl -vH '主机：elpsit.com' http://192.168.1.240/articleservice/system/ipaddr

我已经使用 kops 在 AWS 上设置了一个私有 K8 集群，该集群具有 1 个主节点和 5 个节点。主节点和工作节点位于具有172.20.*.*子网的 vpc 上。我们有另一个用于开发环境的 vpc，它在172.17.*.*子网上有实例。

除了使用堡垒主机之外，无法从 172.17 实例访问 172.20 子网上的节点。现在，我已经安装了 kube-dashboard 并配置了一个服务来公开仪表板，以便 172.17 上的实例可以访问它，但它不工作。

创建服务的脚本：

当我尝试连接到 lb ` https://internal-a29aca39505ba11e9b822124a0b1194c-219044523.us-east-1.elb.amazonaws.com:443时，它会超时。

请让我知道我做错了什么以及如何访问仪表板。谢谢你。

这是一个示例 WebSocket 应用程序，我试图让它从 Kubernetes ingress-nginx 控制器工作。

Kubernetes yaml：

我收到此错误：

当我尝试使用这样的 WebSocket 客户端网页连接时http://www.websocket.org/echo.html

ingress-nginx 的版本是 0.14.0。此版本支持 WebSockets。

更新，当我从本地主机端口转发到 pod 的端口时，我可以直接访问运行 pod 的 websocket。

我有像这样用Dockerfile定义的laravel图像......

我已经像这样安装了带有 helm 的 nginx 入口...

使用此配置，502 Bad Gateway当我访问 www.myweb.com 时它会返回

我应该告诉 nginx 根文件夹在/var/www/public..?? 我怎么做？

我应该告诉 nginx 索引文件在index.php..？？我怎么做？

我的参考是这个https://www.digitalocean.com/community/tutorials/how-to-set-up-laravel-nginx-and-mysql-with-docker-compose。但我不想使用自定义 nginx，而是想使用来自 helm 的 nginx 入口。

谢谢...

我正在尝试 使用本指南进行配置，设置类型为LoadBalancer的 ingress-nginx-controller。 我正在观察的几个问题 - 问题#1）它不会创建 ELB 并将其部署到 AWS 上。 问题#2)外部 IP状态永远显示为待处理。

我已经按照那里提到的每一步

这是来自 pod 的日志 -

上面的错误表明服务没有正常运行。描述服务输出中也没有出现任何事件-

我知道有一个服务规范标签externalIPs但这里的期望是一旦创建 ELB 实例，它将自动填充 -

如果我在这里遗漏了什么，请告诉我。

集群在 Ubuntu 18.06 机器 (VPS) 上运行。它在前面使用金属负载平衡器。

那么，到目前为止我尝试了什么：

• curl 192.168.0.12:8080/system/ipaddr工作正常！（卷曲吊舱）
• curl 10.97.125.155:31001/system/ipaddr工作正常！（卷曲服务）
• curl 192.168.1.240/articleservice/system/ipaddr 失败-> 404

的日志ingress-nginx：

下面你会看到 pod、service 和 ingress 的描述输出。

的输出kubectl describe pod articleservice

的输出kubectl describe service articleservice

的输出kubectl describe ingress articleservice-ingress

我正在使用 kubectl 将我们的系统部署到 AKS。我部署了以下内容：

命名空间：kube-system - Kubernetes NGINX 控制器 - 默认后端

命名空间：默认 - 3 个入口对象，每个包含多个规则。每个都绑定到不同的子域。当我 ping 子域时，设置了正确的 IP（即入口控制器） - 要访问的服务也部署在此命名空间中。

入口控制器已成功创建、接收和 EIP 等，当我转到此 IP 时，我得到默认后端。到现在为止还挺好。

但是，然后我开始添加 Ingress 对象 - 在入口控制器日志中看起来一切都很好，添加规则并使用所有适当的规则重新加载后端但是当我尝试访问任何新 URL 时，即 http:// ingress1.ourdomain.com/ingressrule1请求刚刚超时。

我已在入口控制器上将调试级别设置为 v3，并且在日志中看起来都符合预期。我唯一能想到的是控制器和入口及相关服务位于不同的命名空间中？但这似乎是设置它的正确方法。我现在浏览了许多网页，尽管文档位于：https ://kubernetes.github.io/ingress-nginx/how-it-works/和https://kubernetes.github.io/ingress-nginx/troubleshooting /很有帮助，他们没有为我的情况提供线索。

有没有人遇到过类似的事情？

问题

我可以让 Nginx 在 AKS k8s 内调用另一个微服务，然后再路由到请求的 api 吗？- 目标是加快请求（更少的跃点）并简化构建和部署（更少的服务）。

解释

在我们当前部署的 Azure AKS (Kubernetes) 集群中，我们有一个额外的服务，我希望用 nginx 替换。它是一个路由微服务，在执行路由之前调用身份 API。

Authorization原因是我想像的一个常见原因，我们通过一些预定义的标头（标准标头，或者有时一些用于调试令牌和模拟的定制标头）接收某种身份验证令牌，我们从使用这些预定义的标头将 API 路由到身份 API 并获得用户身份对象作为回报。

然后，我们将这个基本用户身份对象传递给微服务，以便它们可以快速轻松地访问用户和角色。

一个简短的解释是：

• Nginx 接收请求，卸载 SSL 并路由到请求的服务。
• 路由 API 获取授权标头并调用 Identity API。
• 身份 API 验证授权信息并返回授权错误（当身份验证失败时）或序列化的用户身份对象。
• 路由器 API 要么返回那里，然后，如果失败，要么路由到请求的微服务（通过破解请求路径），并将用户身份对象作为标头附加。
• 例如，在 .NET Core 的情况下，请求的微服务可以将该用户身份对象转换为声明主体。

显然有合并 Router.API 和 UserIdentity.API 的选项，但保持关注点分离似乎是一个更好的举措。我只想删除 Route.API，以保持这种分离，但让 nginx 为我完成这项工作。