Kubernetes nginx 入口在集群内部工作，但在外部不可见

Question

I set up a trivial kubernetes yaml file (below) to test the nginx ingress. Nginx works as expected inside the cluster but isn't visible outside the cluster.

I'm running minikube with minikube tunnel and minikube addons enable ingress . When I kubectl exec into the nginx-controller I can see nginx working and serving up the test page, but when I try to hit it from outside I get Failed to connect to 127.0.0.1 port 80: Connection refused .

Save the following yaml as stackoverflow.yaml

kind: Deployment
apiVersion: apps/v1
metadata:
  name: cheese-app
  labels:
    app: cheese-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cheese-app
  template:
    metadata:
      labels:
        app: cheese-app
    spec:
      containers:
      - name: cheese-container
        image: errm/cheese:stilton
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: cheese-svc
spec:
  selector:
    app: cheese-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cheese-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: cheese-svc
          servicePort: 80

Then initialize minikube

minikube start
minikube addons enable ingress
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-system ingress-nginx/ingress-nginx
kubectl wait --for=condition=ready pod --all --timeout=120s
kubectl get pods

Start a minikube tunnel in another terminal window

minikube tunnel

And apply the yaml file

kubectl apply -f ./stackoverflow.yaml
kubectl wait --for=condition=ready pod --all --timeout=120s
kubectl get pods
kubectl get svc

For reference, my pods and svc are

NAME                                                       READY   STATUS    RESTARTS   AGE
cheese-app-74ddc9f7c6-xpjwx                                1/1     Running   0          89m
ingress-system-ingress-nginx-controller-656bf75d85-fkzzp   1/1     Running   0          90m

cheese-svc                                          ClusterIP      10.104.243.39   <none>        80/TCP                       82m
ingress-system-ingress-nginx-controller             LoadBalancer   10.106.203.73   127.0.0.1     80:30635/TCP,443:32594/TCP   83m
ingress-system-ingress-nginx-controller-admission   ClusterIP      10.101.103.74   <none>        443/TCP                      83m
kubernetes                                          ClusterIP      10.96.0.1       <none>        443/TCP                      84m

At this point curl 127.0.0.1/ should theoretically return a sample web page, but instead it reports connection refused .

As a diagnostic step, I tried using kubectl exec to try to curl the page from the nginx server from inside the cluster. That works as long as I curl nginx using its own 127.0.0.1 endpoint. If I curl it using its CLUSTER-IP ( 10.106.203.73 in this cluster), I get nothing.

kubectl exec --stdin --tty ingress-system-ingress-nginx-controller-656bf75d85-fkzzp -- curl 127.0.0.1/ -i
...works...

kubectl exec --stdin --tty ingress-system-ingress-nginx-controller-656bf75d85-fkzzp -- curl 10.106.203.73/ -i
...nothing...

curl 127.0.0.1/
...nothing...

I haven't modified the /etc/nginx/nginx.conf in any way, it's the default config auto generated by setting up the kubernetes ingress.

Answer 1

From within cluster this link should work - http://.:port in your case it will be - http://cheese-svc.default:80

To access it from outside, the service is accessible on nodePort 30635 http://10.106.203.73:30635

Answer 2

As you are using minikube, get the IP of your one node minikube cluster using minikube ip .

And then curl http://<minikube_ip>:<nodePort>

Answer 3

My solution was to conclude that minikube isn't worth the effort. I burned a couple pennies spinning up a tiny Azure Kubernetes cluster for a couple minutes and everything just worked instantly.

I had assumed running locally on minikube or in the Kubernetes cluster that Docker for Windows installs would be quicker and easier than running in a cloud instance, but I was wrong. The number of small weird annoying blockers with these local test environments is just too high. Your mileage may vary but I'm definitely willing to pay a few cents to test my builds if it saves me literally days of unsuccessful debugging of local dev environments.