<p>I have a couple of questions</p>

<ol>
<li><p>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 <code>kubectl apply -f &lt;file_name&gt;</code> sufficient? </p></li>
<li><p>When I add the host attribute without <code>www i.e. (my-domain.in)</code>, I am not able to access my application but with <code>www i.e. (www.my-domain.in)</code> it works, what's the difference?</p></li>
</ol>

<p>Below is my ingress resource</p>

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

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

<pre><code>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
</code></pre>

opensource-developer
<ul>
<li>First answering your question 1:

<blockquote>
  <p>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?</p>
</blockquote></li>
</ul>

<p><strong>In theory, yes, the <code>kubectl apply</code> is the correct way</strong>, either it will show <code>ingress unchanged</code> or <code>ingress configured</code>. </p>

<p>Other valid <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/#updating-an-ingress" rel="nofollow noreferrer">documented</a> option is <code>kubectl edit ingress INGRESS_NAME</code> which saves and apply at the end of the edition if the output is valid.</p>

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

<ul>
<li>Now the blurrier question 2:

<blockquote>
  <p>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?</p>
</blockquote></li>
</ul>

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

<p><strong><em>Endpoint > Domain Provider> Cloud Provider > Ingress > Service > Pod.</em></strong></p>

<ol>
<li>DNS Resolution (Domain Provider)</li>
<li>DNS Resolution (Cloud Provider)</li>
<li>Kubernetes Ingress (Ingress > Service > Pod)</li>
</ol>

<hr>

<h2>DNS Resolution</h2>

<hr>

<p><strong>Domain Provider:</strong></p>

<p>To the Internet, who answers for <code>my-domain.in</code> is your Domain Provider.</p>

<ul>
<li>What are the rules for <code>my-domain.in</code> and it's subdomains (like <code>www.my-domain.in</code> or <code>admin.my-domain.in</code>)?
You said <em>"domain is on a different provider and I have added CNAME (www) pointing to DNS name of my ALB."</em> 

<ul>
<li>Are <code>my-domain.in</code> and <code>my-domain.in</code> being redirected to the ALB address instinctively?</li>
<li>How does it handle URL subdomains? how the request is passed on to your Cloud?</li>
</ul></li>
</ul>

<p><strong>Cloud Provider:</strong></p>

<p>Ok, the cloud provider is receiving the request correctly and distinctly.</p>

<ul>
<li>Does your ALB have generic or specific rules for subdomains or path requests?</li>
<li>Test with another host, a different VM with a web server.</li>
<li><a href="https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html" rel="nofollow noreferrer">Check  ALB Troubleshooting Page</a></li>
</ul>

<h2>Kubernetes Ingress</h2>

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

<p>You can check the <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/#types-of-ingress" rel="nofollow noreferrer">Types of Ingress Docs</a> to get a few examples of how it should work.</p>

<p><strong>Bottom Line:</strong> I believe  your DNS has a route for  <code>www.my-domain.in</code> 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.</p>
