Empty ADDRESS kubernetes ingress
KubernetesKubernetes IngressKubernetes Problem Overview
I tried configuring ingress on my kubernetes cluster. I followed the documentation to install ingress controller and ran the following commands
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/provider/baremetal/service-nodeport.yaml
After that default-http-backend and nginx-ingress-controller were running:
ingress-nginx default-http-backend-846b65fb5f-6kwvp 1/1 Running 0 23h 192.168.2.28 node1
ingress-nginx nginx-ingress-controller-d658896cd-6m76j 1/1 Running 0 6m 192.168.2.31 node1
I tried testing ingress and I deployed the following service:
apiVersion: apps/v1
kind: Deployment
metadata:
name: echoserver-deploy
spec:
replicas: 2
selector:
matchLabels:
app: echo
template:
metadata:
labels:
app: echo
spec:
containers:
- name: my-echo
image: gcr.io/google_containers/echoserver:1.8
---
apiVersion: v1
kind: Service
metadata:
name: echoserver-svc
spec:
selector:
app: echo
ports:
- protocol: TCP
port: 8080
targetPort: 8080
And the following ingress:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: happy-ingress
annotations:
INGRESS.kubernetes.io/rewrite-target: /
spec:
rules:
- host: happy.k8s.io
http:
paths:
- path: /echoserver
backend:
serviceName: echoserver-svc
servicePort: 8080
When I ran the command 'kubectl get ing' I received:
NAME HOSTS ADDRESS PORTS AGE
happy-ingress happy.k8s.io 80 14m
I didn't have ADDRESS resolved and I can’t figure out what the problem is because all the pods are running. Can you give me a hint as to what the issue can be?
Thanks
Kubernetes Solutions
Solution 1 - Kubernetes
You have to enable ingress addons
by following command before creating ingress rules. You can also enable it before executing any other command
$ minikube addons enable ingress
ingress was successfully enabled
Wait until the pods are up and running. You can check by executing following command and wait for the similar output
kubectl get pods -n kube-system | grep nginx-ingress-controller
nginx-ingress-controller-5984b97644-jjng2 1/1 Running 2 1h
For
Deployment
you have to specify the containerPort
and for Service
you have to specify http
protocol.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: echoserver-deploy
spec:
replicas: 2
selector:
matchLabels:
app: my-echo
template:
metadata:
labels:
app: my-echo
spec:
containers:
- name: my-echo
image: gcr.io/kubernetes-e2e-test-images/echoserver:2.1
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: echoserver-svc
spec:
selector:
app: my-echo
ports:
- protocol: TCP
port: 80
targetPort: 8080
name: http
For ingress rule change the port servicePort
from 8080 to 80 the default http port.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: happy-ingress
annotations:
INGRESS.kubernetes.io/rewrite-target: /
spec:
rules:
- host: happy.k8s.io
http:
paths:
- path: /echoserver
backend:
serviceName: echoserver-svc
servicePort: 80
Now apply those files and create your pods, service and ingress rule. Wait few moment, it will take few moments to get ADDRESS for your ingress rule.
Now you can visit your service using
minikube ip
address but not by host name yet. For that you have to add the host and respective IP address in /etc/hosts
file. So open /etc/hosts
file in your favorite editor and add below line where
<minikube_ip> happy.k8s.io
Now you access you service using host name. Verify be following command
curl http://happy.k8s.io/echoserver
Solution 2 - Kubernetes
As official document say: > Because NodePort Services do not get a LoadBalancerIP assigned by > definition, the NGINX Ingress controller does not update the status of > Ingress objects it manages
You have deployed the NGINX Ingress controller as described in the installation guide, so it is normal for your ADDRESS was empty!
Instead, the external client must append the NodePort allocated to the ingress-nginx Service to HTTP requests.
ps. This question is not about minikube
Solution 3 - Kubernetes
Your hostname happy.k8s.io
should resolve to an actual IP address of the nginx-ingress-controller, which points to the front of your load balancer.
You can check under which IP is the cluster working:
bash-3.2$ kubectl cluster-info
Kubernetes master is running at https://192.168.1.100:8443
KubeDNS is running at https://192.168.1.100:8443/api/v1/namespaces/kube-
system/services/kube-dns:dns/proxy
Test the ingress controller for your cluster using curl
bash-3.2$ curl http://192.168.1.100:8080
default backend - 404
In the end, you should just add the domain entry to /etc/hosts
:
192.168.1.100 happy.k8s.io
Solution 4 - Kubernetes
I don't know if this will help, but i had the same problem. I didn't install no ingress controller or whatever like some people said on Github, i just created an Ingress to be able to point my subdomain to a different service and at first my Ingress had no IP address(it was empty).
NAME HOSTS ADDRESS PORTS AGE
ingress delivereo.tk,back.delivereo.tk 80 39s
I think it was because my 2 services for front-end app and back-end api had the Type of LoadBalancer. I changed it to NodePort because they don't need external ip now that the ingress controller will manage what url goes where.
And when i did change the type of my services to NodePort, after 2 or 3 minutes the IP address of the Ingress appeared. When i pointed my Cloudflare DNS to the new Ingress IP, i tested my subdomain and it worked !
BEFORE
apiVersion: v1
kind: Service
metadata:
name: delivereotk
spec:
ports:
- port: 80
selector:
app: delivereotk
type: LoadBalancer
AFTER
apiVersion: v1
kind: Service
metadata:
name: delivereotk
spec:
ports:
- port: 80
selector:
app: delivereotk
type: NodePort
Ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress
spec:
rules:
- host: delivereo.tk
http:
paths:
- backend:
serviceName: delivereotk
servicePort: 80
- host: back.delivereo.tk
http:
paths:
- backend:
serviceName: backdelivereotk
servicePort: 80
Solution 5 - Kubernetes
Ingress problems are specific to your implementation, so let me just speak to a bare-metal, LAN implementation with no load-balancer.
The key validation point of an ingress resource is that it gets an address (after all, what am I supposed to hit, if the ingress doesn't have an address associated with it?) So if you do
kubectl get ingress some-ingress
Over and over (give it 30 seconds or so) and it never shows an address - what now?
On bare-metal LAN there are a few trouble spots. First, ensure that your Ingress resource can find your Ingress controller - so (setting aside the controller spec for now) your resource needs to be able to find your controller with something like:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-api-ingress
annotations:
kubernetes.io/ingress.class: nginx
Where your controller has entries like:
Labels: app.kubernetes.io/component=controller
app.kubernetes.io/instance=ingress-nginx
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=ingress-nginx
app.kubernetes.io/version=1.0.4
helm.sh/chart=ingress-nginx-4.0.6
But now let's go back a step - your controller - is it setup appropriately for your (in my case) bare-metal LAN implementation? (this is all made super-easy by the cloud providers, so I'm providing this answer for my friends in the private cloud community)
There the issue is that you need this essential hostNetwork setting to be true, in your Ingress controller deployment. So for that, instead of using the basic yamil (https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.4/deploy/static/provider/baremetal/deploy.yaml) - wget it, and modify it to set the spec of the template of the spec of the Deployment, so that hostNetwork: true - something like (scroll down to the end):
# Source: ingress-nginx/templates/controller-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
helm.sh/chart: ingress-nginx-4.0.6
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: 1.0.4
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
selector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
revisionHistoryLimit: 10
minReadySeconds: 0
template:
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
spec:
dnsPolicy: ClusterFirst
containers:
- name: controller
image: k8s.gcr.io/ingress-nginx/controller:v1.0.4@sha256:545cff00370f28363dad31e3b59a94ba377854d3a11f18988f5f9e56841ef9ef
imagePullPolicy: IfNotPresent
lifecycle:
preStop:
exec:
command:
- /wait-shutdown
args:
- /nginx-ingress-controller
- --election-id=ingress-controller-leader
- --controller-class=k8s.io/ingress-nginx
- --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
securityContext:
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
runAsUser: 101
allowPrivilegeEscalation: true
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: LD_PRELOAD
value: /usr/local/lib/libmimalloc.so
livenessProbe:
failureThreshold: 5
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
ports:
- name: http
containerPort: 80
protocol: TCP
- name: https
containerPort: 443
protocol: TCP
- name: webhook
containerPort: 8443
protocol: TCP
volumeMounts:
- name: webhook-cert
mountPath: /usr/local/certificates/
readOnly: true
resources:
requests:
cpu: 100m
memory: 90Mi
nodeSelector:
kubernetes.io/os: linux
serviceAccountName: ingress-nginx
terminationGracePeriodSeconds: 300
hostNetwork: true
volumes:
- name: webhook-cert
secret:
secretName: ingress-nginx-admission
Deploy that, then setup your ingress resource, as indicated above.
Your key tests are:
- Does my ingress have a dedicated node in my bare-metal implementation?
- if I hit port 80 on the ingress node, do I get the same thing as hitting the NodePort? (let's say NodePort is 31207 - do I get the same thing hitting port 80 on the ingress node as hitting port 31207 on any node?)
Final note: Ingress has changed a lot over the past few years, and tutorials are often providing examples that don't pass validation - please feel free to comment on this answer if it has become out of date
Solution 6 - Kubernetes
I encountered the same problem on GKE (Google Kubernetes Engine). It turned out there was a problem with ingress settings, I used incorrect names for desired services. You should check for errors by executing this command:
kubectl describe ingress <your-ingress-name>
Solution 7 - Kubernetes
I faced similar issue, realized I needed to :
-
Enable the NGINX Ingress controller, run the following command:
minikube addons enable ingress
-
Verify that the NGINX Ingress controller is running
kubectl get pods -n kube-system
Expect nginx-ingress-controller pod in running status.
Solution 8 - Kubernetes
What you are looking for is a way to test your ingress resource.
You can do this by:
- Look for the ip address of the ingress controller pod/s and use port 80/443 along with this ip.
- Look for the service which is exposing the ingress controller deployment
- If there is no service you can create one and expose the ingress controller deployment
- If you want a hostname then you will need to manage the dns entries.
Solution 9 - Kubernetes
In my case the problem was simply a missing secret in the relevant namespace.
Solution 10 - Kubernetes
I had a similar case. The ingress we have written is just a ingress rule. To make the address available we need to have ingress controller pods running too.
Simply check if the controller pods is running or not
kubectl get pods
You should have the controller pods running as show in the image. If not you can install it using helm.
if you are using helm2 simply use the following command:
helm install stable/nginx-ingress --name my-nginx
follow this docs for different ways to install it. https://kubernetes.github.io/ingress-nginx/deploy/
When doing helm install you might get the following issue if you don't have tiller installed.
Error: could not find tiller
To fix it install tiller as following:
kubectl -n kube-system create serviceaccount tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller
To verify tiller is working:
kubectl get pods --namespace kube-system
Solution 11 - Kubernetes
In my case, for api version 1.20+, the only supported pathType
value is ImplementationSpecific
.
For details, check this link https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer
Solution 12 - Kubernetes
If TLS is part of your ingress, then missing secret can be the case. To find the secret name, first describe your ingress:
kubectl describe ing <ing-name> -n <namespace>
Or find 'secretName' in your yaml file:
tls:
- hosts:
- example.com
secretName: secret-name
And make sure that the secret is available when you list your secrets:
kubectl get secrets -n <namespace>