Ingress-Control中的Path问题记录

最新推荐文章于 2024-03-18 17:16:16 发布

KaffeeVenus

最新推荐文章于 2024-03-18 17:16:16 发布

阅读量3.1k

点赞数 2

分类专栏： k8s、docker

本文链接：https://blog.csdn.net/justinhuo/article/details/102676958

版权

本文记录了2019年10月22日遇到的一个问题，即在使用IngressControl暴露服务时，配置Path后服务无法访问。通过分析Nginx配置、IngressControl配置和日志，发现Ingress的annotations将Path '/V1' 替换成了 '/', 导致服务找不到匹配路径。解决方案是正确理解和使用Ingress的annotations，确保Path配置无误。" 107774041,8187414,CAN通讯故障排查与解决,"['CAN总线', '通信故障', '电子工程', '嵌入式系统', '硬件配置']

摘要由CSDN通过智能技术生成

时间记录：2019-10-22

问题描述：在使用IngressControl的方式进行服务的暴露的时候发现在Ingress中配置了Path这一项后发现服务无法被访问。

Nginx中的配置
在nginx的配置文件中有location项配置和proxy_pass，而我们通常在配置proxy_pass的时候为了动态的使用源都会配置upstream,然后在proxy_pass中会不注意以 / 结尾和不以其结尾的区别。

假设我们有一个http://xxx.com/v1/的路径需要转发代理，这里v1后面是具体的服务的路径
配置的upstream名假设为xxx.com,以/结尾和不以/结尾的两种不同方式的实际访问的路径的区别
proxy_pass为http://xxx.com/v1
那么实际访问的为http://xxx.com/v1
proxy_pass为http://xxx.com/v1/
那么实际访问的为http://xxx.com/
这里其实是ngnix自己一个方式，假设我们实际的服务里面就存在v1这个路径那么我们就可以直接使用，当然如果不存在则404

当我们碰到这种问题的时候，就可以在nginx的日志文件中查看实际访问的地址，然后确定某一个环节出现的问题

IngressControl的配置
ingressControl对nginx进行配置的文件

{
   
  "kind": "Ingress",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
   
    "name": "ingress-myapp",
    "namespace": "default",
    "selfLink": "/apis/extensions/v1beta1/namespaces/default/ingresses/ingress-myapp",
    "uid": "5664cda0-0cf8-45a4-a255-87a4c72ee31e",
    "resourceVersion": "15972",
    "generation": 15,
    "creationTimestamp": "2019-10-21T08:32:51Z",
    "annotations": {
   
      "kubernetes.io/ingress.class": "nginx",
      "nginx.ingress.kubernetes.io/rew