Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The spec for Ingress resource is incorrect #2066

Closed
tlliddle opened this issue Jun 10, 2021 · 8 comments · Fixed by #2068
Closed

The spec for Ingress resource is incorrect #2066

tlliddle opened this issue Jun 10, 2021 · 8 comments · Fixed by #2068

Comments

@tlliddle
Copy link
Contributor

The manifest for apiVersion: networking.k8s.io/v1 has the incorrect specs.

spec:
rules:
- http:
paths:
- path: /*
backend:
serviceName: service-2048
servicePort: 80

The spec should conform to the spec referenced here:
https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource

spec:
  rules:
    - http:
        paths:
        - path: /*
          pathType: Prefix
          backend:
             service:
               name:  service-2048
               port:
                 number: 80
@kishorj
Copy link
Collaborator

kishorj commented Jun 10, 2021

In v2.2.0, If pathType is not specified, it will default to ImplementationSpecific. The spec you provided will fail validation since pathType: Prefix will not allow wildcards ? or *.

Did you encounter any issues with the provided manifest?

@tlliddle
Copy link
Contributor Author

@kishorj - You are correct. Copy/Paste error from my last test. This is the error you are referring too?

{"level":"error","ts":1623347854.85268,"logger":"controller","msg":"Reconciler error","controller":"ingress","name":"ingress-2048","namespace":"game-2048","error":"ingress: game-2048/ingress-2048: prefix path shouldn't contain wildcards: /*"}

I did have to specify a pathType because I received this error when I didn't.

The Ingress "ingress-2048" is invalid: spec.rules[0].http.paths[0].pathType: Required value: pathType must be specified

This is the correct spec that tested successfully.

spec:
  rules:
    - http:
        paths:
        - path: /
          pathType: Prefix
          backend:
             service:
               name:  service-2048
               port:
                 number: 80

@M00nF1sh
Copy link
Collaborator

M00nF1sh commented Jun 10, 2021

i think we should revert this PR: #2040

networking/v1 is not supported in 1.16 yet, but this file needs to support all supported eks versions as it's used in docs.
also, the backend schema changed in networking/v1 and it's incorrect.

@ns0092
Copy link

ns0092 commented Jul 29, 2021

@M00nF1sh To confirm, what is the fix for this?
If I have the path as /, I get 404 for /foo as the Ingress does not treat / as /*.

Having path /* seems to solve the routing problem but I see the error on aws-alb-controller logs:

{"level":"error","ts":1627597396.9217522,"logger":"controller","msg":"Reconciler error","controller":"ingress","name":"sample-ingress","namespace":"default","error":"ingress: default/sample-ingress: prefix path shouldn't contain wildcards: /*"

@fert-f
Copy link

fert-f commented Aug 17, 2021

Had the same problem. Seems that changing pathType will allow wildcards in hosts:
path: /* pathType: ImplementationSpecific

@sergioteixeirabasecone
Copy link

Hi, someone could solve the issue with /* ?

@goddini91
Copy link

no

@insideClaw
Copy link

Had the same problem. Seems that changing pathType will allow wildcards in hosts: path: /* pathType: ImplementationSpecific

This works well and made my prefix path shouldn't contain wildcards: /* error go away, but I went with changing the pathType to just / (as tlliddle suggested earlier).

As is listed in the Ingress Examples, this is the correct pattern for "match everything". Only problem is that it's a breaking change that requires the new aws controller version already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants