<p>I have the following Ingress definition that works well (I use docker-for-mac): </p>

<pre><code>apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: zwoop-ing
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: localhost
    http:
      paths:
      - path: /
        backend:
          serviceName: posts-api-svc
          servicePort: 8083
</code></pre>

<p>Where I'm confused is how I would deal with multiple api microservices that I want to expose.  </p>

<p>The options that I had in mind: </p>

<ul>
<li>Multiple ingresses </li>
<li>Single ingress with different paths </li>
<li>Single ingress with different subdomains (when on the Cloud) </li>
</ul>

<p>I assume that multiple ingresses would cost more (?).<br>
For some reason, I have problems using a subpath segment (ingress-nginx).  </p>

<p>When I define: <code>- path: /api</code> in the ingress resource, I receive a 404 on GET request.<br>
It is unclear how to define a subpath (here I use /api, but that would be posts-api, users-api etc).  </p>

<p>For a single posts-api, I currently have the following setup: </p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: posts-api-svc
  # namespace: nginx-ingress
  labels:
    app: posts-api
    #rel: beta
    #env: dev
spec:
  type: ClusterIP
  selector:
    app: posts-api
    # rel: beta
    # env: dev
  ports:
    - protocol: TCP
      port: 8083
</code></pre>

<p>With a deployment: </p>

<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: posts-api-deployment
  # namespace: nginx-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: posts-api
  template:
    metadata:
      labels:
        app: posts-api
        # env: dev
        # rel: beta
    spec:
      containers:
        - name: posts-api
          image: kimgysen/posts-api:latest
          ports:
          - containerPort: 8083
          livenessProbe:
            httpGet:
              path: /api/v1/posts/health
              port: 8083
            initialDelaySeconds: 120
            timeoutSeconds: 1
</code></pre>

<p>The health check on the pod works fine for endpoint: /api/v1/posts/health</p>

<blockquote>
  <p>I assume that multiple ingresses would cost more (?).</p>
</blockquote>

<ul>
<li>Multiple ingress controllers like <a href="https://github.com/kubernetes/ingress-nginx" rel="noreferrer">nginx-ingress</a>: Yes, it would cost more if you are using an external <a href="https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer" rel="noreferrer">load balancer</a> and a cloud provider like AWS, GCP or Azure because you will be using as many load balancers as ingress controller. It would not cost more if you are using just a ClusterIP (accessing within the cluster) and it will vary if you are using a <a href="https://kubernetes.io/docs/concepts/services-networking/service/#nodeport" rel="noreferrer">NodePort</a> service to expose it.</li>
<li>Multiple <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="noreferrer">Ingress</a> Kubernetes resources: No it would not cost more if you are using the same ingress controller.</li>
</ul>

<blockquote>
  <p>When I define: - path: /api in the ingress resource, I receive a 404 on GET request.</p>
</blockquote>

<p>This means it's going to the default backend and likely because of this annotation <code>nginx.ingress.kubernetes.io/rewrite-target: /</code>. Essentially, that's stripping the <code>/api</code> from your request that is going to your backend. If you want to preserve the path, I suggest you remove the annotation.</p>

<p>You can always check the nginx ingress controller <code>nginx.conf</code> file with something like:</p>

<pre><code>$ kubectl cp &lt;pod-where-nginx-controller-is-running&gt;:nginx.conf .
$ cat nginx.conf
</code></pre>
