<p>I was doing some research about ingress and it seems I have to create a new ingress resource for each namespace. Is that correct? </p>

<p>I just created 2 separate ingress resources in different namespaces in my GKE cluster but it seems to use the same LB in(which is great for cost) but I would think it is possible to have clashes then. (when using same path). I just tried it and the first one I've created is still working on the path, the other newer one on the same path is just not working. </p>

<p>Can someone explain me the  correct setup for ingress?</p>

DenCowboy
<p>As Kubernetes works, ingress controller won't pass a packet to a service that is in a different namespace from the ingress resource. So, if you create an ingress resource in the default namespace, all your services must be in the default namespace as well.</p>

<p>This is something that won't change. EVER. There has been a feature request years ago, and kubernetes team announced that it's not going to happen. It introduces a security hole when ingress controller is being able to transpass a namespace.</p>

<p>Now, what we do in these situations is actually pretty neat. You will have to do the following:</p>

<ol>
<li>Say you have 2 services in the namespaces you need. e.g. <code>service1.foo</code> and <code>service2.bar</code>.</li>
<li>create 2 headless services without selectors and 2 <code>Endpoint</code> objects pointing to the IP addresses of the services <code>service1.foo</code> and <code>service2.bar</code>, in the same namespace as the ingress resource. The headless service without selectors will force kube-dns (or coreDNS) to search for either <code>ExternalName</code> type service or an <code>Endpoint</code> object. Now, the only requirement here is that your headless service and the <code>Endpoint</code> object must have the same name.</li>
<li>Create your ingress resource pointing to the headless services.</li>
</ol>

<p>It should look like this (for 1 service):</p>

<p>Say the IP address of <code>service1.foo</code> is <code>10.10.10.10</code>. Your headless service and the <code>Endpoint</code> object would be:</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: bait-svc
spec:
  clusterIP: None
  ports:
  - name: http
    port: 80
    targetPort: 80

---

apiVersion: v1
kind: Endpoints
metadata:
  name: bait-svc
subsets:
- addresses:
  - ip: 10.10.10.10
  ports:
  - port: 80
    protocol: TCP
</code></pre>

<p>and <code>Ingress</code> resource:</p>

<pre><code>apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - secretName: ssl-certs 
  rules:
  - host: site1.training.com
    http:
      paths:
      - path: /
        backend:
          serviceName: bait-svc
          servicePort: 80
</code></pre>

<p>So, the <code>Ingress</code> points to the <code>bait-svc</code>, and <code>bait-svc</code> points to <code>service1.foo</code>. And you will do this for each service.</p>

<p><strong>UPDATE</strong></p>

<p>I am thinking now, it might not work with GKE Ingress Controller, as on GKE you need a <code>NodePort</code> type service for the HTTP load balancer to reach the service. As you can see, in my example I've got nginx Ingress Controller.</p>

<p>Independently if it works or not, I would recommend using some other Ingress Controller. It's not that GKE IC is not good. It is quite robust, but almost always you end up hitting some limitation. Other ICs are more flexible.</p>
