Ingress is major part when we talk about Kubernetes inbuilt load balancers.

kubernetes port types

Limitation

Unless something seriously magical has happened with “Docker for Mac,” then the type: LoadBalancer is only designed for a cloud environment, where the Ingress controller can provision a cloud load balancer (i.e. AWS's ELB, GKE's ... whatever they use).

That said, one can see from your output that kubernetes has behaved as if it was type: NodePort (with your specific example showing that port 32670 goes to port 8080 on your Service). It's unclear whether you can just use that NodePort-ish port as-is, or whether the Service in "pending" state somehow means traffic will not route as expected. I guess maybe just try it?

Or you can skip the pretense and create the Service legitimately of type: NodePort , and then you and kubernetes will be on the same page about what is happening.

The other way you can chose to do things is run an in-cluster Ingress controller, such as ingress-nginx, and use virtual-hosting to expose all your services on just one port. That can be far more convenient if you have a lot of Services to expose, but it would likely be too big of a headache to set up just for one or two of them.

Why endpoints and not services

The NGINX ingress controller does not use Services to route traffic to the pods. Instead it uses the Endpoints API in order to bypass kube-proxy to allow NGINX features like session affinity and custom load balancing algorithms. It also removes some overhead, such as conntrack entries for iptables DNAT.

Practical approach for kubernetes ingress loadbalancer deployment.

SSL certificate generation and configure kubernetes secrets for it.

// Generate local root key with password

openssl genrsa -des3 -out rootCA.key 4096 // Generate local root key without password

openssl genrsa -out rootCA.key 4096 // Creating local Certificate Authority certificate

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -subj "/C=LK/ST=western/O=lsf, Inc./CN=local.com" -out rootCA.crt // updating your local certificate store

mkdir /usr/local/share/ca-certificates/extra

update-ca-certificates // Generate domain key

openssl genrsa -out example.com.key 2048 // Generate self signed certificate request

openssl req -new -sha256 -key example.com.key -subj "/C=SL/ST=western/O=lsf, Inc./CN=example.com" -out example.com.csr // Generate self signed certificate

openssl x509 -req -in example.com.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out example.com.crt -days 500 -sha256 // Configure kubernetes secret from the certificate

kubectl create secret tls tls-certificate --key example.com.key --cert example.com.crt While we are using OpenSSL, we should also create a strong Diffie-Hellman group, which is used in negotiating Perfect Forward Secrecy with clients. // Generate dhparam

openssl dhparam -out dhparam.pem 2048 // Configure

kubectl create secret generic tls-dhparam --from-file=dhparam.pem

Once deploy the ingress controller you may check it.

$ kubectl get service nginx-ingress

Change the your localhost ip to your test domain name in /etc/hosts file.

Then it is possible to use browser for url calling.

$ sudo nano /etc/hosts

Then check it from using a browser or curl commands.

// Check normal

$ curl https://example.com -cacert ./tls/rootCA.crt // check providing CA authority certificate

$ curl https://example.com -cacert ./tls/rootCA.crt // If you'd like to turn off curl's verification of the certificate, // use the -k (or --insecure) option.

$ curl https://example.com --insecure

Check the services currently running in kubernetes cluster.

$ kubectl get services

Finally add the ingress rules as in following yaml.

Hear minor modification is added to the original site changing the domain name to example.com which i have used in my article.

View the hello-world-svc page by url through ingress.

View the hello world service directly through nodePort.