K
Q

Adding host without www not working with Ingress resource

2/26/2020

I have a couple of questions

  1. When we make changes to ingress resource, are there any cases where we have to delete the resource and re-create it again or is kubectl apply -f <file_name> sufficient?

  2. When I add the host attribute without www i.e. (my-domain.in), I am not able to access my application but with www i.e. (www.my-domain.in) it works, what's the difference?

Below is my ingress resource

When I have the host set to my-domain.in, I am unable to access my application, but when i set the host to www.my-domain.in I can access the application.

my domain is on a different provider and I have added CNAME (www) pointing to DNS name of my ALB.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: eks-learning-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:a982529496:cerd878ef678df
  labels:
    app: eks-learning-ingress
spec:
  rules:
  - host: my-domain.in **does not work**
    http:
      paths:
        - path: /*
          backend:
            serviceName: eks-learning-service
            servicePort: 80
-- opensource-developer
amazon-web-services
kubernetes
kubernetes-ingress

Similar Questions

gRPC streaming inter instance communication
AWS EKS Deployment updating the existing deployment
I get a crash loopback error when creating a pod. but I didn't know any solution
Kubemq-go missing tags in response to query via GRPC

1 Answer

2/26/2020

  • First answering your question 1:

    When we make changes to ingress resource, are there any cases where we have to delete the resource and re-create it again or is kubectl apply -f sufficient?

In theory, yes, the kubectl apply is the correct way, either it will show ingress unchanged or ingress configured.

Other valid documented option is kubectl edit ingress INGRESS_NAME which saves and apply at the end of the edition if the output is valid.

I said theory because bugs happen, so we can't fully discard it, but bug is the worst case scenario.

  • Now the blurrier question 2:

    When I add the host attribute without www i.e. (my-domain.in), I am not able to access my application but with www i.e. (www.my-domain.in) it works, what's the difference?

To troubleshoot it we need to isolate the processes, like in a chain we have to find which link is broken. One by one:

Endpoint > Domain Provider> Cloud Provider > Ingress > Service > Pod.

  1. DNS Resolution (Domain Provider)
  2. DNS Resolution (Cloud Provider)
  3. Kubernetes Ingress (Ingress > Service > Pod)

DNS Resolution

Domain Provider:

To the Internet, who answers for my-domain.in is your Domain Provider.

  • What are the rules for my-domain.in and it's subdomains (like www.my-domain.in or admin.my-domain.in)? You said "domain is on a different provider and I have added CNAME (www) pointing to DNS name of my ALB."
    • Are my-domain.in and my-domain.in being redirected to the ALB address instinctively?
    • How does it handle URL subdomains? how the request is passed on to your Cloud?

Cloud Provider:

Ok, the cloud provider is receiving the request correctly and distinctly.

  • Does your ALB have generic or specific rules for subdomains or path requests?
  • Test with another host, a different VM with a web server.
  • Check ALB Troubleshooting Page

Kubernetes Ingress

Usually we would start the troubleshoot from this part, but since you mentioned it works with www.my-domain.in, we can presume that your service, deployment and even ingress structure is working correctly.

You can check the Types of Ingress Docs to get a few examples of how it should work.

Bottom Line: I believe your DNS has a route for www.my-domain.in but the root domain has no route to your cloud provider that's why it's only working when you are enabling the ingress for www.

-- willrof
Source: StackOverflow