Chapter 6. Application Updates, Gradual Rollouts, and Autoscaling

This chapter will expand upon the core concepts, and show you how to roll out updates and test new features of your application with minimal disruption to uptime. It will cover the basics of doing application updates, gradual rollouts, and A/B testing. In addition, we will look at scaling the Kubernetes cluster itself.

In version 1.2, Kubernetes released a Deployments API. Deployments are the recommended way to deal with scaling and application updates going forward. As mentioned in previous chapters, ReplicationControllers are no longer the recommended manner for managing application updates. However, as they're still core functionality for many operators, we will explore rolling updates in this chapter as an introduction to the scaling concept and then dive into the preferred method of using Deployments in the next chapter.

We'll also investigate the functionality of Helm and Helm Charts that will help you manage Kubernetes...

Technical requirements

You'll need to have your Google Cloud Platform account enabled and logged in, or you can use a local Minikube instance of Kubernetes. You can also use Play with Kubernetes over the web: https://labs.play-with-k8s.com/.

Here's the GitHub repository for this chapter: https://github.com/PacktPublishing/Getting-Started-with-Kubernetes-third-edition/tree/master/Code-files/Chapter06.

Example setup

Before we start exploring the various capabilities built into Kubernetes for scaling and updates, we will need a new example environment. We are going to use a variation of our previous container image with a blue background (refer to the v0.1 and v0.2 (side by side) image, later in this chapter, for a comparison). We have the following code in the pod-scaling-controller.yaml file:

apiVersion: v1 
kind: ReplicationController 
metadata: 
  name: node-js-scale 
  labels: 
    name: node-js-scale 
spec: 
  replicas: 1 
  selector: 
    name: node-js-scale 
  template: 
    metadata: 
      labels: 
        name: node-js-scale 
    spec: 
      containers: 
      - name: node-js-scale 
        image: jonbaier/pod-scaling:0.1 
        ports: 
        - containerPort: 80

 

 

Save the following code as pod-scaling-service.yaml file:

apiVersion: v1 
kind: Service 
metadata: 
  name: node-js-scale 
  labels: 
    name: node-js-scale 
spec: 
  type: LoadBalancer 
  sessionAffinity: ClientIP...

Scaling up

Over time, as you run your applications in the Kubernetes cluster, you will find that some applications need more resources, whereas others can manage with fewer resources. Instead of removing the entire ReplicationControllers (and associated pods), we want a more seamless way to scale our application up and down.

Thankfully, Kubernetes includes a scale command, which is suited specifically for this purpose. The scalecommand works both with ReplicationControllers and the new Deployments abstraction. For now, we will explore its use with ReplicationControllers. In our new example, we have only one replica running. You can check this with a get pods command:

$ kubectl get pods -l name=node-js-scale

 

 

Let's try scaling that up to three with the following command:

$ kubectl scale --replicas=3 rc/node-js-scale

If all goes well, you'll simply see the scaled word on the output of your Terminal window.

Note

Optionally, you can specify the --current-replicas flag as a verification step. The scaling...

Smooth updates

The scaling of our application up and down as our resource demands change is useful for many production scenarios, but what about simple application updates? Any production system will have code updates, patches, and feature additions. These could be occurring monthly, weekly, or even daily. Making sure that we have a reliable way to push out these changes without interruption to our users is a paramount consideration.

Once again, we benefit from the years of experience the Kubernetes system is built on. There is built-in support for rolling updates with the 1.0 version. The rolling-update command allows us to update entire ReplicationControllers or just the underlying Docker image used by each replica. We can also specify an update interval, which will allow us to update one pod at a time and wait until proceeding to the next.

Let's take our scaling example and perform a rolling update to the 0.2 version of our container image. We will use an update interval of 2 minutes, so...

Testing, releases, and cutovers

The rolling update feature can work well for a simple blue-green deployment scenario. However, in a real-world blue-green deployment with a stack of multiple applications, there can be a variety of inter-dependencies that require in-depth testing. The update-period command allows us to add a timeout flag where some testing can be done, but this will not always be satisfactory for testing purposes.

Similarly, you may want partial changes to persist for a longer time and all the way up to the load balancer or service level. For example, you may wish to run an A/B test on a new user interface feature with a portion of your users. Another example is running a canary release (a replica in this case) of your application on new infrastructure, such as a newly added cluster node.

Let's take a look at an A/B testing example. For this example, we will need to create a new service that uses sessionAffinity. We will set the affinity to ClientIP, which will allow us to forward...

Application autoscaling

A recent feature addition to Kubernetes is that of the Horizontal Pod Autoscaler. This resource type is really useful as it gives us a way to automatically set thresholds for scaling our application. Currently, that support is only for CPU, but there is alpha support for custom application metrics as well. 

Let's use the node-js-scaleReplicationController from the beginning of the chapter and add an autoscaling component. Before we start, let's make sure we are scaled back down to one replica using the following command:

$ kubectl scale --replicas=1 rc/node-js-scale

Now, we can create a Horizontal Pod Autoscaler, node-js-scale-hpa.yaml with the following hpa definition:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: node-js-scale
spec:
  minReplicas: 1
  maxReplicas: 3
  scaleTargetRef:
    apiVersion: v1
    kind: ReplicationController
    name: node-js-scale
  targetCPUUtilizationPercentage: 20

Go ahead and create this with thekubectl create...

Scaling a cluster

All these techniques are great for scaling the application, but what about the cluster itself? At some point, you will pack the nodes full and need more resources to schedule new pods for your workloads.

Autoscaling

When you create your cluster, you can customize the starting number of nodes (minions) with the NUM_MINIONS environment variable. By default, it is set to 4.

Additionally, the Kubernetes team has started to build autoscaling capability into the cluster itself. Currently, this is only supported on GCE and GKE, but work is being done on other providers. This capability utilizes the KUBE_AUTOSCALER_MIN_NODES, KUBE_AUTOSCALER_MAX_NODES, and KUBE_ENABLE_CLUSTER_AUTOSCALER environment variables.

 

 

The following example shows how to set the environment variables for autoscaling before running kube-up.sh:

$ export NUM_MINIONS=5
$ export KUBE_AUTOSCALER_MIN_NODES=2
$ export KUBE_AUTOSCALER_MAX_NODES=5
$ export KUBE_ENABLE_CLUSTER_AUTOSCALER=true

Also, bear in mind that changing...

Managing applications

At the time of this book's writing, new software has emerged that hopes to tackle the problem of managing Kubernetes applications from a holistic perspective. As application installation and continued management grows more complex, software such as Helm hopes to ease the pain for cluster operators creating, versioning, publishing, and exporting application installation and configuration for other operators. You may have also heard the term GitOps, which uses Git as the source of truth from which all Kubernetes instances can be managed.

While we'll jump deeper into Continuous Integration and Continuous Delivery (CI/CD) in the next chapter, let's see what advantages can be gained by taking advantage of package management within the Kubernetes ecosystem. First, it's important to understand what problem we're trying to solve when it comes to package management within the Kubernetes ecosystem. Helm and programs like it have a lot in common with package managers such as apt...

Summary

We should now be a bit more comfortable with the basics of application scaling in Kubernetes. We also looked at the built-in functions in order to roll updates as well as a manual process for testing and slowly integrating updates. We took a look at how to scale the nodes of our underlying cluster and increase the overall capacity for our Kubernetes resources. Finally, we explored some of the new autoscaling concepts for both the cluster and our applications themselves. 

In the next chapter, we will look at the latest techniques for scaling and updating applications with the new deployments resource type, as well as some of the other types of workloads we can run on Kubernetes.

 

 

Questions

1. What is the name of the command that allows you to increase the number of replication controllers and the new Deployments abstraction in order to meet application needs?
2. What is the name of the strategy for providing smooth rollouts to applications without interrupting the user experience?
3. What is one type of session affinity available during deployment?
4. What is the recent addition to Kubernetes that allows for pods in the cluster to scale horizontally?
5. Which environment variables, if set, allow the cluster to scale Kubernetes nodes with demand?
6. Which software tool allows you to install applications and leverage the expertise of those product team's installation settings?
7. What is a Helm install file called? 

Further reading

If you'd like to read more about Helm, check out its web page here: https://www.helm.sh/blog/index.html. If you'd like to read more about the software behind cluster autoscaling, check out the Kubernetes autoscaler repository: https://github.com/kubernetes/autoscaler.