CODEWITHSUNDEEP
kuberneteskubernetes-ingressnginx-ingress
Duncan Fairley
Duncan Fairley

Reputation: 65

Kubernetes ingress wildcard no longer working

After updating onprem kubernetes from 1.18 to 1.22.5, I had to switch the ingress api versions from v1beta1 to v1, and selected ImplementationSpecific as the new, required pathType.

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: wx-ing-example
spec:
  rules:
    - host: "*.example.com"
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: wx-example
                port:
                  number: 80

Since the update, subdomains beyond one level aren't being sent to the service, and instead return a 404. I.e. bar.example.com is working, but foo.bar.example.com is not.

I've tried changing pathType to Prefix with no change in behaviour.

k8s.gcr.io/ingress-nginx/controller:v1.1.0

Upvotes: 1

Views: 1839

Answers (1)

The Fool
The Fool

Reputation: 20420

What you are descibing is expected behavior according to the official kubernetes ingress documentation.

Host Host header Match?
*.foo.com bar.foo.com Matches based on shared suffix
*.foo.com baz.bar.foo.com No match, wildcard only covers a single DNS label
*.foo.com foo.com No match, wildcard only covers a single DNS label

PathType has nothing to do with that. This is about the host header.

The only option I know of, is leaving the host completely away. So it will match any request that is able to find its way to your ingress controller. Depending on your situation, this may not be desirable.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: any-host
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: sample
            port:
              number: 80

Upvotes: 2

Related Questions