In the last blogpost I created, instantiated and started a TIBCO BWCE application Docker image on a local Kubernetes cluster (Minikube). In this blogpost I will be explaining how to easily scale to keep up with user demand.
Scaling a deployment (increasing the number of replicas) will make sure that new pods are created or removed. Kubernetes supports autoscaling, but for this blogpost we will be doing this manually by using the command line (you can also achieve this by using the Kubernetes Dashboard, but that’s no fun!).
Scaling is accomplished by changing the number of replicas in a Deployment.
Scaling up a deployment will require a way to distribute and load-balance the traffic to all of them. The clever thing about Kubernetes is that the services have integrated load-balancing functionality that will distribute network traffic to all pods of an exposed deployment. In the last blogpost we exposed our TIBCO BWCE “helloworld application”-pod by creating a service, so the traffic to each additional TIBCO BWCE “helloworld application”-pod will be handled automatically by this service (awesome!).
Below we see the situation before and after scaling a deployment. Notice that the scope of the service increased automatically and network traffic to all pods are being handled by the original service (A).
1. Let’s start by running the following command to get a list of the actual deployments:
MacBook-Pro:~ ruben.middeljans$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE helloworldbwce-node 1 1 1 1 3d
- DESIRED shows the configured replicas
- CURRENT shows how many replicas are running now
- UP-TO-DATE shows the number of replicas that were updated to match the desired state
- AVAILABLE shows how many replicas are actually AVAILABLE to the users
2. To scale up our TIBCO BWCE “helloworld” application we use the “kubectl scale” command followed by the name of the deployment object (“deployments/helloworldbwce-node”) and the amount of replicas we “desire” (4).
MacBook-Pro:~ ruben.middeljans$ kubectl scale deployments/helloworldbwce-node --replicas=4 deployment "helloworldbwce-node" scaled
3. To verify that the application was properly scaled up to 4 instances we re-run the following command:
MacBook-Pro:~ ruben.middeljans$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE helloworldbwce-node 4 4 4 4 3d
As we can see the change was applied and we have now 4 instances running of the TIBCO BWCE “helloworld” application in just a matter of seconds!
4. To verify the correct amount of pods and corresponding internal IP addresses we can run the following command:
MacBook-Pro:~ ruben.middeljans$ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE helloworldbwce-node-2301106929-hprg4 1/1 Running 4 3d 172.17.0.2 minikube helloworldbwce-node-2301106929-kpxtz 1/1 Running 1 4m 172.17.0.7 minikube helloworldbwce-node-2301106929-s61cc 1/1 Running 1 4m 172.17.0.6 minikube helloworldbwce-node-2301106929-w134b 1/1 Running 0 4m 172.17.0.5 minikube
There are 4 pods now with different (internal) IP addresses.
5. To verify that the original service is now load-balancing the traffic towards all 4 pods we can run the following command:
MacBook-Pro:~ ruben.middeljans$ kubectl describe services/helloworldbwce-node Name: helloworldbwce-node Namespace: default Labels: run=helloworldbwce-node Annotations: <none> Selector: run=helloworldbwce-node Type: LoadBalancer IP: 10.0.0.113 Port: <unset> 8080/TCP NodePort: <unset> 30724/TCP Endpoints: 172.17.0.2:8080,172.17.0.5:8080,172.17.0.6:8080 + 1 more... Session Affinity: None Events: <none>
As we can see there are 4 endpoints each with the corresponding IP address of one of the pods and the corresponding internal port (8080) or our TIBCO BWCE “helloworld” application.
6. To scale down our TIBCO BWCE “helloworld” application we use the “kubectl scale” command in the same way as we did before.
MacBook-Pro:~ ruben.middeljans$ kubectl scale deployments/helloworldbwce-node --replicas=1 deployment "helloworldbwce-node" scaled