4

This question is similar to the one asked in: Could not access Kubernetes Ingress in Browser on Windows Home with Minikube?
except I experience this on my local machine running macOS Big Sur. And unfortunately the suggestions there did not help me. I also followed the example from: Set up Ingress on Minikube with the NGINX Ingress Controller
All steps goes as planned, except the last one, where I get no response to the curl hello-world.info.
I assumed that I could find some log of the curl request in

kubectl logs -n ingress-nginx ingress-nginx-controller-69bdbc4d57-xbz7v

but nothing get logged there when I try curl hello-world.info. Only logs from startup remains there. Unless I set it to debug mode (arg: --v=5), which logs a lot, but I've not found anything related to the curl request. But suggestions to grep filter could be useful. I tried to follow the same description on ubuntu, running microk8s, and the ingress works fine there. So there is something with my local setup on the mac.

Here is the output from my test:

$ minikube start
  minikube v1.23.2 on Darwin 11.6
✨  Using the docker driver based on existing profile
  Starting control plane node minikube in cluster minikube
  Pulling base image ...
  Restarting existing docker container for "minikube" ...
  Preparing Kubernetes v1.22.2 on Docker 20.10.8 ...
  Verifying Kubernetes components...
    ▪ Using image kubernetesui/dashboard:v2.3.1
  After the addon is enabled, please run "minikube tunnel" and your ingress resources would be available at "127.0.0.1"
    ▪ Using image kubernetesui/metrics-scraper:v1.0.7
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.0
    ▪ Using image k8s.gcr.io/ingress-nginx/controller:v1.0.0-beta.3
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.0
  Verifying ingress addon...
  Enabled addons: storage-provisioner, default-storageclass, ingress, dashboard
  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
$ kubectl get pods -n ingress-nginx
NAME                                        READY   STATUS      RESTARTS        AGE
ingress-nginx-admission-create--1-z82df     0/1     Completed   0               7d18h
ingress-nginx-admission-patch--1-bvspd      0/1     Completed   1               7d18h
ingress-nginx-controller-69bdbc4d57-xbz7v   1/1     Running     4 (4m43s ago)   7d18h
$ kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
deployment.apps/web created
$ kubectl expose deployment web --type=NodePort --port=8080
service/web exposed
$ kubectl get service web
NAME   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
web    NodePort   10.96.184.154   <none>        8080:30578/TCP   15s
$ kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
ingress.networking.k8s.io/example-ingress created
$ kubectl get ingress
NAME              CLASS   HOSTS              ADDRESS        PORTS   AGE
example-ingress   nginx   hello-world.info   192.168.49.2   80      13s

Added this to the hosts file

$ ping hello-world.info
PING hello-world.info (192.168.49.2): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
$ curl hello-world.info
curl: (7) Failed to connect to hello-world.info port 80: Operation timed out

Any suggestion is appreciated. I've also looked into this troubleshooting guide, but not been able to find the solution to my problem.

Here is the result of the get ingress example-ingress -oyaml request

$ kubectl get ingress example-ingress -oyaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"nginx.ingress.kubernetes.io/rewrite-target":"/$1"},"name":"example-ingress","namespace":"default"},"spec":{"rules":[{"host":"hello-world.info","http":{"paths":[{"backend":{"service":{"name":"web","port":{"number":8080}}},"path":"/","pathType":"Prefix"}]}}]}}
    nginx.ingress.kubernetes.io/rewrite-target: /$1
  creationTimestamp: "2021-10-06T18:58:17Z"
  generation: 1
  name: example-ingress
  namespace: default
  resourceVersion: "147761"
  uid: ab01f481-0687-4ae8-8cda-a458adb31f52
spec:
  ingressClassName: nginx
  rules:
  - host: hello-world.info
    http:
      paths:
      - backend:
          service:
            name: web
            port:
              number: 8080
        path: /
        pathType: Prefix
status:
  loadBalancer:
    ingress:
    - ip: 192.168.49.2

I must admit I do yet not understand the routing of k8s. And I find it strange that the IP of Minikube, which match the Ingress IP, 192.168.49.2 is not to be found if I type ifconfig in terminal. So how can the macos route this traffic even locally, when it does not know that the IP sits on the machine itself. So maybe the problem is here?

Updated with my workaround

In hosts I set

127.0.0.1 hello-world.info

then run

$ minikube tunnel
❗  The service/ingress example-ingress requires privileged ports to be exposed: [80 443]
  sudo permission will be asked for it.
  Starting tunnel for service example-ingress.

And after that the ingress controller respond

$ curl hello-world.info
Hello, world!
Version: 1.0.0
Hostname: web-79d88c97d6-g29pb
  • Can you post the result of `kubectl get ingress example-ingress -oyaml`? – AndD Oct 06 '21 at 13:29
  • I've included that information in the post now – Roger Ulekleiv Oct 06 '21 at 19:06
  • Uhm, it looks all ok to me. Maybe the Nginx controller Pod is logging some errors? Check its logs with `kubectl logs -f -n ingress-nginx ingress-nginx-controller-69bdbc4d57-xbz7v` – AndD Oct 07 '21 at 06:00
  • No errors listed in the controller log. I suspect more and more that the curl request, or through browser, never reach minikube. Because it is a mystery to me how the OS could send this request to minikube when the 192.168.49.2 is not found in netstats or ifconfig output. – Roger Ulekleiv Oct 07 '21 at 06:39
  • I now changed the hosts file to map hello-world.info to 127.0.0.1. Then ran minikube tunnel. And when I now run 'curl hello-world.info' I get the expected response from the cluster/pod. So I guess I can conclude that this is a routing issue, and I can live with this setup on my local machine, for testing. – Roger Ulekleiv Oct 07 '21 at 07:39

0 Answers0