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

Wildcard in host #987

Closed
s2504s opened this issue Aug 6, 2019 · 7 comments
Closed

Wildcard in host #987

s2504s opened this issue Aug 6, 2019 · 7 comments

Comments

@s2504s
Copy link

s2504s commented Aug 6, 2019

Hi all!
My issue is related on #960

I've tried to use wildcard for setting the host:

  - host: 'api-*.*'
    http:
      paths:
      - path: /*
        backend:
          serviceName: api
          servicePort: 443

That regexp works in AWS (using aws console) but when I make

kubectl apply -f ...

I get the issue

The Ingress "c" is invalid: spec.rules[1].host: Invalid value: "api-*.*": a wildcard DNS-1123 subdomain must start with '*.', followed by a valid DNS subdomain, which must consist of lower case alphanumeric characters, '-' or '.' and end with an alphanumeric character (e.g. '*.example.com', regex used for validation is '\*\.[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
@s2504s s2504s changed the title Wildcard Wildcard in host Aug 6, 2019
@omgapuppy
Copy link

Interested in this as well.
Potentially allowing to specify listener rules in annotations instead of host. We're in the process of migrating legacy workloads to EKS, and use weighted r53 DNS records to achieve no downtime traffic shifting of public facing endpoints.

The issue is that having component*.example.com complains in k8s about the DNS name not conforming to RFC spec.
As the AWS api & ALB's support this format for listener rules for host header checks, there should really be an option to define listener rules via annotations to avoid clashing with Kubernetes APIs.

As it stands, we've to either allow too broad a hostname range, or manage DNS manually which is far from ideal.
As AWS advertise alb-ingress-controller as their method of achieving ALB provisioning from k8s, their feedback / contribution would be appreciated.

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 14, 2019
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Dec 14, 2019
@s2504s
Copy link
Author

s2504s commented Dec 15, 2019

/remove-lifecycle rotten

@k8s-ci-robot k8s-ci-robot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Dec 15, 2019
@slithernix
Copy link

This would greatly simplify configurations...

@M00nF1sh
Copy link
Collaborator

M00nF1sh commented Feb 21, 2020

@jmcdonagh @s2504s
It's forbidden by Ingress's spec. With #1088 (it's in v1.1.5), we are supporting this (Note: it's not standard Ingress usage, but there is no standard Ingress nowadays..... :D)

@M00nF1sh
Copy link
Collaborator

M00nF1sh commented Feb 21, 2020

variant A: use a real service. (conditions is matched against service name)

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: "2048-ingress"
  namespace: "2048-game"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/conditions.service-2048: >
      [{"Field":"host-header","HostHeaderConfig":{"Values":["api-*.*"]}}]
  labels:
    app: 2048-ingress
spec:
  rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: "service-2048"
              servicePort: 80

variant B: use a fake Service.(conditions is matched against service name), so the only the first path got the extra host condition(while both of them are routed to same target group for service-2048). Disclaimer: I really don't like this hack personally, but it works for now

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: "2048-ingress"
  namespace: "2048-game"
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/conditions.fake-service-2048: >
      [{"Field":"host-header","HostHeaderConfig":{"Values":["api-*.*"]}}]
    alb.ingress.kubernetes.io/actions.fake-service-2048: >
      {"Type":"forward","ForwardConfig":{"TargetGroups":[{"ServiceName":"service-2048","ServicePort":"80"}]}}
  labels:
    app: 2048-ingress
spec:
  rules:
    - http:
        paths:
          - path: /path1
            backend:
              serviceName: "fake-service-2048"
              servicePort: use-annotation
          - path: /path2
            backend:
              serviceName: service-2048
              servicePort: 80

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

No branches or pull requests

6 participants