<p>I hope all is well!</p>
<p>I'm trying to wrap my head around Ingresses and Services. I'm trying to reach my pod thru my ingress hostname:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: oc-backend
    app.kubernetes.io/version: 1.16.0
    helm.sh/chart: oc-backend-0.1.0
  name: oc-backend
  namespace: oc
spec:
  rules:
    - host: oc-backend.com
      http:
        paths:
          - backend:
              service:
                name: oc-backend
                port:
                  number: 80
            path: /
            pathType: ImplementationSpecific
</code></pre>
<p>And am exposing a service that would be reached by the ingress:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: oc-backend
    app.kubernetes.io/version: 1.16.0
    helm.sh/chart: oc-backend-0.1.0
  name: oc-backend
  namespace: oc
spec:
  ports:
    - port: 80
      targetPort: 3000
  selector:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/name: oc-backend
  type: LoadBalancer
</code></pre>
<p>The deployment the pods are running in run on port 3000:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: oc-backend
    app.kubernetes.io/version: 1.16.0
    helm.sh/chart: oc-backend-0.1.0
  name: oc-backend
  namespace: oc
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/instance: oc-backend
      app.kubernetes.io/name: oc-backend
  template:
    metadata:
      labels:
        app.kubernetes.io/instance: oc-backend
        app.kubernetes.io/name: oc-backend
    spec:
      containers:
        - envFrom:
            - secretRef:
                name: secrets
          image: 'registry.gitlab.com/open-concepts/open-concepts-backend:master'
          imagePullPolicy: Always
          name: oc-backend
          ports:
            - containerPort: 3000
          resources: {}
          securityContext: {}
      imagePullSecrets:
        - name: credentials
      securityContext: {}
      serviceAccountName: oc-backend-sa
</code></pre>
<p>Yet everytime I try to ping a route in <code>oc-backend.local</code>, I get a <code>getaddrinfo ENOTFOUND oc-backend.local</code> error. Am I missing something in the flow?</p>
<p>TIA!</p>
<p><strong>EDIT</strong></p>
<p>I'm adding some info about the Minikube tunnelling and ingress addons. I've confirmed that the add-on was enabled prior to this post, and for the sake of troubleshooting I've explicitly re-ran the commands:</p>
<pre class="lang-bash prettyprint-override"><code>➜ minikube addons enable ingress

💡  ingress is an addon maintained by Kubernetes. For any concerns contact minikube on GitHub.
You can view the list of minikube maintainers at: https://github.com/kubernetes/minikube/blob/master/OWNERS
💡  After the addon is enabled, please run &quot;minikube tunnel&quot; and your ingress resources would be available at &quot;127.0.0.1&quot;
    ▪ Using image k8s.gcr.io/ingress-nginx/controller:v1.2.1
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
🔎  Verifying ingress addon...
🌟  The 'ingress' addon is enabled
</code></pre>
<p>And made sure to keep the Minikube tunnel open:</p>
<pre class="lang-bash prettyprint-override"><code>➜ sudo minikube tunnel            
✅  Tunnel successfully started

📌  NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...

❗  The service/ingress argocd-server requires privileged ports to be exposed: [80 443]
🔑  sudo permission will be asked for it.
🏃  Starting tunnel for service argocd-server.
❗  The service/ingress oc-backend requires privileged ports to be exposed: [80]
🔑  sudo permission will be asked for it.
🏃  Starting tunnel for service oc-backend.
❗  The service/ingress oc-backend requires privileged ports to be exposed: [80 443]
🔑  sudo permission will be asked for it.
🏃  Starting tunnel for service oc-backend.
</code></pre>
<p>Thanks to the tunnelling, I get an external ip and I try to curl my endpoint, with no success:</p>
<pre class="lang-bash prettyprint-override"><code>➜ kubectl get svc -n oc
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
oc-backend   LoadBalancer   10.109.58.97   127.0.0.1     80:32026/TCP   26h

➜ curl 10.109.58.97 
curl: (56) Recv failure: Connection reset by peer
</code></pre>
<p><strong>EDIT 2</strong>:</p>
<p>Minikube tunnelling takes me to 127.0.0.1, and <a href="https://github.com/kubernetes/minikube/issues/7344#issuecomment-607318525" rel="nofollow noreferrer">apparently it's a &quot;feature&quot;</a>.</p>
<pre class="lang-bash prettyprint-override"><code>➜ curl -H 'Host: oc-backend.com' 192.168.49.2
curl: (56) Recv failure: Connection reset by peer
</code></pre>

Fares
<p><strong>Update 1</strong></p>
<p>Given this output:</p>
<pre><code>NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
oc-backend   LoadBalancer   10.109.58.97   127.0.0.1     80:32026/TCP   26h
</code></pre>
<p>You're trying to reach the service using the cluster ip. That's not going to work; the cluster ip is internal to Kubernetes and isn't something that you interact with.</p>
<p>You would normally expect to use either (a) the external ip for the service or (b) the address on which your ingress service is listening.</p>
<p>There's something awry with the external ip assigned to your service; it shouldn't be <code>127.0.0.1</code>. With <code>minikube tunnel</code> running, we expect to see something like this:</p>
<pre><code>NAME         TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE
oc-backend   LoadBalancer   10.99.21.223   10.99.21.223   80:31301/TCP   111s
</code></pre>
<p>Where that 10.99.21.223 address is on a private network created by minikube for this cluster to which we have access because of routes set up by the <code>minikube tunnel</code> command:</p>
<pre><code>$ ip route
[...]
10.96.0.0/12 via 192.168.49.2 dev br-577fbef29a21
192.168.49.0/24 dev br-577fbef29a21 proto kernel scope link src 192.168.49.1
</code></pre>
<p>However, you should also be able to access your service via your Ingress, since you've enabled the ingress addon. Running <code>kubectl get ingress</code> should yield something like:</p>
<pre><code>$ kubectl get ingress
NAME         CLASS   HOSTS            ADDRESS        PORTS   AGE
oc-backend   nginx   oc-backend.com   192.168.49.2   80      6m2s
</code></pre>
<p>That <code>192.168.49.2</code> is the address of our ingress service. Using the same deployment manifests as in the original answer (below), we can see that works as expected:</p>
<pre><code>$ curl -H 'Host: oc-backend.com' 192.168.49.2
Hostname: oc-backend-988c667f5-5v4pv
IP: 127.0.0.1
IP: 172.17.0.3
RemoteAddr: 172.17.0.5:49692
GET / HTTP/1.1
Host: oc-backend.com
User-Agent: curl/7.82.0
Accept: */*
X-Forwarded-For: 192.168.49.1
X-Forwarded-Host: oc-backend.com
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Scheme: http
X-Real-Ip: 192.168.49.1
X-Request-Id: 1315d986890020f4c8cfbba70a2a2047
X-Scheme: http
</code></pre>
<p>Here I'm providing an explicit <code>Host:</code> header, but we could achieve the same goal by adding an entry to <code>/etc/hosts</code>:</p>
<pre><code>192.168.49.2 oc-backend.com
</code></pre>
<p>With this in place, we can use the hostname in <code>curl</code> (or in our browser) to access the service:</p>
<pre><code>$ curl oc-backend.com
Hostname: oc-backend-988c667f5-5v4pv
IP: 127.0.0.1
IP: 172.17.0.3
RemoteAddr: 172.17.0.5:49414
GET / HTTP/1.1
Host: oc-backend.com
User-Agent: curl/7.82.0
Accept: */*
X-Forwarded-For: 192.168.49.1
X-Forwarded-Host: oc-backend.com
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Scheme: http
X-Real-Ip: 192.168.49.1
X-Request-Id: 2c5b2aac46e9641690485c93ec02dadf
X-Scheme: http
</code></pre>
<hr />
<p>I think there are a couple of issues here.</p>
<p>First, minikube, out of the box, doesn't even <em>have</em> an Ingress provider, so unless you're leaving out some details from your question, your Ingress resource isn't doing anything. You would need to <a href="https://kubernetes.io/docs/tasks/access-application-cluster/ingress-minikube/" rel="nofollow noreferrer">install an ingress provider</a> after setting up minikube.</p>
<p>If you create a <code>LoadBalancer</code> service, you can access that without an Ingress, but according to <a href="https://minikube.sigs.k8s.io/docs/handbook/accessing/" rel="nofollow noreferrer">the minikube documentation</a> you need to run <code>minikube tunnel</code> first.  When you first create a <code>LoadBalancer</code> service, it doesn't get an external ip address:</p>
<pre><code>$ kubectl get service
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
oc-backend   LoadBalancer   10.100.71.243   &lt;pending&gt;     80:32539/TCP   2m25s
</code></pre>
<p>After you run <code>minikube tunnel</code>, your service will have an external ip:</p>
<pre><code>$ k get service
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
oc-backend   LoadBalancer   10.100.71.243   10.100.71.243   80:32539/TCP   4m23s
</code></pre>
<p>And your system will have the necessary routes to reach the service at that address. So with the configuration you show in your question, and the above output, we would expect your service to be available at <code>http://10.100.71.243</code>.</p>
<hr />
<p>Let's try it out. First, I've made some minor changes to the manifests in your question (I'm running a dummy image instead of the open-concepts-backend image, because I didn't want to muck around with any application configure issues. I'm using the <code>containous/whoami</code> image, that just display some metadata about the environment (it listens on port 80 instead of port 3000).  My manifests look like this:</p>
<pre><code>apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/name: oc-backend
  name: oc-backend
  namespace: oc
spec:
  ports:
  - name: http
    port: 80
    targetPort: http
  selector:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/name: oc-backend
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/name: oc-backend
  name: oc-backend
  namespace: oc
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/instance: oc-backend
      app.kubernetes.io/name: oc-backend
  template:
    metadata:
      labels:
        app.kubernetes.io/instance: oc-backend
        app.kubernetes.io/name: oc-backend
    spec:
      containers:
      - image: docker.io/containous/whoami:latest
        imagePullPolicy: Always
        name: oc-backend
        ports:
        - containerPort: 80
          name: http
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    app.kubernetes.io/instance: oc-backend
    app.kubernetes.io/name: oc-backend
  name: oc-backend
  namespace: oc
spec:
  rules:
  - host: oc-backend.com
    http:
      paths:
      - backend:
          service:
            name: oc-backend
            port:
              name: http
        path: /
        pathType: Prefix
</code></pre>
<p>With all of these manifests deployed, I see the output from <code>kubectl get service</code> that I show above, and I can access the service as expected from my host (after running the <code>minikube tunnel</code> command):</p>
<pre><code>$ curl 10.100.71.243
Hostname: oc-backend-988c667f5-6shxv
IP: 127.0.0.1
IP: 172.17.0.3
RemoteAddr: 172.17.0.1:25631
GET / HTTP/1.1
Host: 10.100.71.243
User-Agent: curl/7.82.0
Accept: */*
</code></pre>
