Kubernetes: What it is and what it isn’t

I’m a developer and I’ll admit it, I’m learning Kubernetes. I’ve been developing web applications now for more than 20 years; however, the past two years I’ve moved to working with microservices applications. Originally the microservices were web sites on multiple virtual machines. Last year we started moving towards containers to achieve a higher density on our machines and to standardize the package our deployments shipped in. Once we had a handful of containers running, it was obvious we needed a platform to manage them.

Kubernetes is a container management platform. Real world applications and services typically contain multiple containers that get deployed across multiple servers. Kubernetes allows you to treat those servers as a pool of compute resources. It monitors the resource usage and needs to determine where and when containers should run and if new instances need to be added. It has many features that makes it easier for me to build systems made of many containers … and keep my sanity.

As I’m learning to build systems using Kubernetes, I have found that it solves these problems well for me:

• Compute scheduling. By looking at the resource needs of a pod (which is one or more containers), the scheduler will find the right place to run it.
• Self-healing. If a pod crashes, a new one will be created to replace it.
• Horizontal scaling. When the resource limits of a pod indicate the number of instances should increase, Kubernetes will add new instances, and it can do the same with decreasing instance count when resources drop.
• Volume management. It manages the persistent storage for needed by my applications.
• Service discovery & load balancing. Pods get their own IP address, DNS and multiple instances get load balanced.
• Automated rollouts & rollbacks. The health of the pods is monitored during updates, and if a failure occurs, the pod can roll back to the previous version.
• Secret & configuration management. Configuration and secrets are managed at the platform level that is used by the containers.

Of course, there are some things needed that are not part of Kubernetes. It needs to run on a platform that handles security, governance, identity and access control, networking, data and storage. We have chosen Azure for our hosted Kubernetes provider, but all the large cloud vendors offer a hosted version these days.

Choosing a hosted Kubernetes provider has shrunk my learning curve by allowing me to focus on managing my application (and not learning Kubernetes The Hard Way).

Besides hosting these multiple container systems, developing them has its own challenges. However, I’ve found the latest round of tools have features for native container development which makes it easier.

I must admit, I am most familiar with Microsoft’s tools, so I’ll focus on those here:

• Visual Studio and Visual Studio Code both have extensions to help me work with Docker and Kubernetes without me needing to jump in and out of my IDE or editor.
• Azure Container Registry gives me a private registry to keep my container images and the Helm charts I use for deploying to Kubernetes.
• Azure DevOps Pipelines is super flexible and works great with my source code repository to build my container images and store them in my registry. It also is great for deploying to my different Kubernetes environments.
• Azure Dev Spaces helps me debug my containers that are deployed in Azure Kubernetes Service, as opposed to having to duplicate a local setup in order to reproduce the problem.

If you are also learning Kubernetes, here are a couple of resources that I’ve found to be useful: k8slearning and https://aka.ms/LearnKubernetes.

Questions or comments? Let me know in the comments below.

Jason Haley

Azure MVP

See more articles from this author