kubernetes-ingressminikube

ingress with minikube working differently on Mac vs Ubuntu. When to set etc/hosts to 127.0.0.1 vs "minikube ip"?


I have a simple ingress file that does work on multiple environments, but to access it, it behaves differently depending on if I'm running my minikube cluster on my Mac or my Ubuntu machines.

Specifically, for my mac, I have to add the the entry: 127.0.0.1 my.kube to /etc/hosts, and also run minikube tunnel for me to be able to access my application in the browser at http://my.kube.

But, for my Ubuntu system, I have to get the minikube ip and place the resulting ip in /etc/hosts like 192.168.49.2 my.kube for example. And then I do NOT need to run minikube tunnel.

While I can see the pros and cons of each:

  1. using a 127.0.0.1 and a tunnel removes a dependency on the minikube ip, which could change if the cluster is deleted and recreated (although some work has gone on to make it persistent).
  2. using the minikube ip and not needing a tunnel is nice too.

But, my question is why are things behaving differently at all?

I have enabled the ingress addon on both environments with minikube addons enable ingress.

When I check the hostname of the loadBalancer created by the ingress with kubectl get ingress my-ingress -o yaml I get the same result for both. I expected to see an IP in the case where the minikube IP is used (Ubuntu).

....
status:
  loadBalancer:
    ingress:
    - hostname: localhost

Again, all services are up and running fine, it's just a question of what goes in /etc/hosts and whether minikube tunnel is or is not running.

Also, to be clear, my Ubuntu system will not work with 127.0.0.1 and minikube tunnel. I can't find a common approach for the two environments.

For reference, here is my ingress file:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my.kube
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-ui
                port:
                  number: 3000
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: my-api
                port:
                  number: 8080

Some names have been changed to protect the innocent.

Just for completeness, the services are just simply:

apiVersion: v1
kind: Service
metadata:
  name: my-ui
spec:
  selector:
    app: my-ui
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: my-api
spec:
  selector:
    app: my-api
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

Solution

  • Minikube supports ingress differently on the Mac and Linux.

    On Linux the ingress is fully supported and therefore does not need the use of minikube tunnel.

    On Mac there is an open issue due to a network issue. The documentation states that the minikube ingress addon is not supported, but I argue that that is highly misleading if not incorrect. It's just supported differently (and not as well).

    On both Mac and Linux minikube addons enable ingress is required. Enabling the ingress addon on Mac shows that the ingress will be available on 127.0.0.1 as shown in the screenshot, whereas Linux will make it available by the minikube ip. Then, when we start minikube tunnel on the Mac it will connect to the ingress like any other exposed service.

    minikube commands in CLI

    Thanks to Gabriel for pointing me in the right direction.