Scaling Your Application to Thousands of Deployments

In this chapter, we will show you how to scale the sample application that we introduced in Chapter 2, Kubernetes on Azure (AKS), using kubectl. We will introduce different failures to demonstrate the power of Kubernetes' declarative engine. The goal is to make you comfortable with kubectl, which is an important tool for managing AKS. In addition, in this chapter you will get a brief introduction to how network traffic is routed to different pods running on different nodes, and how it will help you to diagnose network problems in production.

In this chapter, we'll cover the following topics:

• Scaling your application
• Handling failure in AKS
• Upgrading your application

Technical requirements

For this chapter, you will need any modern browser, such as Chrome, Firefox, Safari, or Edge.

You will find the code files for this chapter by accessing https://github.com/PacktPublishing/Hands-On-Kubernetes-on-Azure.

Scaling your application

Scaling on demand is one of the key benefits of using cloud-native applications. It also helps optimize resources for your application. If the frontend component encounters heavy loads, you can scale the frontend alone, while keeping the same number of backend instances. You can increase or reduce the number/size of VMs required depending on your workload and peak demand hours. You will scale your application components independently and also see how to troubleshoot scaling issues.

Implementing independent scaling

To demonstrate independent scaling, let's use the guestbook example that we used in the previous chapter. Let's follow these steps to learn how to implement independent scaling...

Handling failure in AKS

Kubernetes is a distributed system with many hidden working parts. AKS abstracts all of it for us, but it is still our responsibility to know where to look and how to respond when bad things happen. Much of the failure handling is done automatically by Kubernetes – still, you will run into situations where manual intervention is required. The following is a list of the most common failure modes that require interaction. We will look into the following failure modes in depth in this section:

• Node failures
• Out-of-resource failure
• Storage mount issues
• Network issues

See Kubernetes the Hard Way (https://github.com/kelseyhightower/kubernetes-the-hard-way), an excellent tutorial, to get an idea about the blocks on which Kubernetes is built. For the Azure version, see Kubernetes the Hard Way – Azure Translation (https://github.com/ivanfioravanti...

Upgrading your application

Using Deployments makes upgrading a straightforward operation. As with any upgrade, you should have good backups in case something goes wrong. Most of the issues you will run into will happen during upgrades. Cloud-native applications are supposed to make dealing with this relatively easier which is possible only if you have a very strong development team that has the ability to do incremental rollouts (with support for rollback).

There is a trade-off between getting features out for customers to see versus spending a lot of time ensuring developer training, automated tests, and disciplined developers and product managers. Remember, most successful companies that do upgrades in production multiple times a day had for years monolithic applications that generated revenue before they were able to switch to a microservices-based approach.

Most methods here...

Summary

This was a chapter with tons of information. Our goal was to show how to scale deployments with Kubernetes by not only showing you how to create multiple instances of the software, but also how to debug problems that you might run into.

We started the chapter off by looking at how to define the use of a load balancer and leverage the replica creation feature in Kubernetes to achieve scalability. With this type of scalability, we also achieve failover by using load balancer and multiple instances of the software for stateless applications.

After that, we showed you how to troubleshoot simple problems you might run into, and how to use persistent storage to avoid data loss if a node goes down or needs to be rebooted.

In the next chapter, we will look at how to set up Ingress services and certificate managers to interface with LetsEncrypt.

...