Like we always do, let’s try to get all the nodes for our cluster and see what we get:
$ kubectl get node
NAME STATUS ROLES AGE VERSION
And we see a two-node cluster running! But wait, didn’t it say three nodes when it booted up? Well, that might be Google SRE working behind the scenes and telling us, “Hey! You’ve got nothing deployed, so you can do that with two.”
So, I got an idea. What if I deploy an NGINX deployment, expose it as a
Load Balancer service, deploy a
Horizontal Pod Autoscaler, and hammer it to see how the cluster behaves? Sounds like a plan.
Let’s create an NGINX deployment first:
And we have the deployment created. Let’s expose the deployment as a
Load Balancer service by using the following command:
$ kubectl expose deployment nginx-deployment --port=80 --type=LoadBalancer
And let’s create a
Horizontal Pod Autoscaler using the following command:
$ kubectl autoscale deployment nginx-deployment --min=2 --max=50 --cpu-percent=10
Now, let’s get the pod and service using the following commands:
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-7874d6b448-hxh9h 1/1 Running 0 4m48s
nginx-deployment-7874d6b448-qgppq 1/1 Running 0 4m48s
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.63.128.1
nginx-deployment LoadBalancer 10.63.130.238 220.127.116.11 80:32757/TCP 3m8s
So, two pods are exposed through a
Load Balancer service running on 18.104.22.168. Let’s hit this service using
curl and see what we get:
$ curl 22.214.171.124
Welcome to nginx!
And we get the default NGINX response. Cool, the service is working!
Now, let’s do some load testing in the next section.