In the last part I deployed a very simple static web application, using the verification steps from the tutorial I was using. I combined this with some persistent NFS storage to preserve the data being served. I showed that this could be accessed from the cluster via curl from the main K8s node, as well as using firefox over X11, also launched from the main node. This is all very well and good but how would this content be accessed externally?
It seems that for more complex deployments, ingress can be used, by making use of an ingress controller and possibly combining with a load balancer. However as I’m taking things a bit slower trying to learn the ins and outs of k8s, I will start simple too.
The verification steps created a clusterIP service for my pod, which I can use anywhere within the cluster, however to access externally at a basic level a different type of service is needed, that of a NodePort.
While I could delete the ClusterIP service and create a new NodePort service, this can also be done on the fly using the patch feature of kubectl:
pi@k8s-master:~ $ kubectl patch svc kube-verify -p '{"spec": {"type": "NodePort"}}' -n kube-verify
service/kube-verify patched
When querying the service it is now shown as a NodePort as expected, and has an additional TCP port:
Now when visiting any node in the cluster using an external IP address and the TCP port assigned, in my case 31981, the webpage becomes visible externally:
Scaling
Currently I have a single pod serving out the static web page from my persistent NFS volume. with the NodePort service added I can now allow access from the internet with a bit of port forwarding on the router. However what if this page become very popular, and a single nginx pod serving the web page cannot cope with the amount of requests it is receiving? Well the beauty of Kubernetes is that we can scale our deployment to have any number of replicas.
By issuing the command:
kubectl scale --replicas=5 deployment/kube-verify -n kube-verify
deployment.apps/kube-verify scaled
We tell k8s that we want 5 running copies of this pod and it starts to create them for us:
There is still only a single NodePort Service which is connecting to all the pods in a round robin fashion, so only use a single IP to connect, however the load is now spread across 5 pods, which could be running on different worker nodes:
This makes it very flexible and could be hooked into other processes to scale up or down based on volume of traffic, time of day or month etc.