1

Kubernetes Architecture

This practical book on Kubernetes security provides a detailed exploration of each Kubernetes component with a mix of theory and some step-by-step demonstrations. You will gain a deep understanding of the workflows that connect all the components, and you will learn about the fundamental building blocks that the Kubernetes ecosystem comprises.

Having an in-depth understanding of the Kubernetes architecture is essential for securing a cluster as this will provide the context needed to protect the platform effectively. Gaining a deep understanding of Kubernetes' core components, such as the API server, etcd, controller manager, scheduler, and kubelet, is crucial for detecting potential vulnerabilities and securing each layer of the architecture.

In this chapter, we're going to cover the following main topics:

• Microservices model
• Evolution from Docker to Kubernetes
• What is Kubernetes?
• Kubernetes components
• Kubernetes objects
• Kubernetes alternatives
• Cloud providers and managed Kubernetes

Microservices model

One of the most important aspects of Kubernetes to understand is that it is a distributed system. This means it comprises multiple components distributed across different infrastructure, such as networks and servers, which could be either virtual machines, bare metal, or cloud instances. Together, these elements form what is known as a Kubernetes cluster.

Before you dive deeper into Kubernetes, it's important for you to understand the growth of microservices and containerization.

Traditional applications, such as web applications, are known to follow a modular architecture, splitting code into an application layer, business logic, a storage layer, and a communication layer. Despite the modular architecture, the components are packaged and deployed as a monolith. A monolithic application, despite being easy to develop, test, and deploy, is hard to maintain and scale.

When it comes to a monolithic application, developers face the following inevitable problems as the applications evolve:

• Scaling: A monolithic application is difficult to scale. It's been proven that the best way to solve a scalability problem is via a distributed method.
• Operational cost: The operation cost increases with the complexity of a monolithic application. Updates and maintenance require careful analysis and enough testing before deployment. This is the opposite of scalability; you can't scale down a monolithic application easily as the minimum resource requirement is high.
• Security challenges: Monolithic applications present several security challenges, particularly when addressing vulnerabilities. For instance, rebooting for patching can be complex and time-consuming, while encryption key rotation is often difficult to implement. Additionally, monolithic architectures face increased risks of denial-of-service (DoS) attacks due to scaling limitations, which can impact availability. Here are some clear examples of issues that you may face:
  • Centralized logging and monitoring can be more challenging in monolithic applications, making it harder to detect and respond to security incidents in a timely manner
  • Implementing the principle of least privilege (where each component has only the permissions it needs) is more difficult in a monolithic application because all components run within the same process and share the same permissions
  • Monolithic applications may not easily support modern security practices such as microservices, containerization, or serverless architectures, which can provide better isolation and security controls
• Longer release cycle: The maintenance and development barriers are significantly high for monolith applications. When there is a bug, it takes a lot of time for developers to identify the root cause in a complex and ever-growing code base. The testing time increases significantly. Regression, integration, and unit tests take significantly longer to pass with a complex code base. When the customer's requests come in, it takes months or even a year for a single feature to ship. This makes the release cycle long and impacts the company's business significantly.

These problems create a huge incentive to break down monolithic applications into microservices. The benefits are obvious:

• With a well-defined interface, developers only need to focus on the functionality of the services they own.
• The code logic is simplified, which makes the application easier to maintain and easier to debug. Furthermore, the release cycle of microservices has shortened tremendously compared to monolithic applications, so customers do not have to wait for too long for a new feature.

The issues with a monolith application and the benefits of breaking it down led to the growth of the microservices architecture. The microservices architecture splits application deployment into small and interconnected entities, where each entity is packaged in its own container.

However, when a monolithic application breaks down into many microservices, it increases the deployment and management complexity on the DevOps side. The complexity is evident; microservices are usually written in different programming languages that require different runtimes or interpreters, with different package dependencies, different configurations, and so on, not to mention the interdependence among microservices. This is exactly where Docker comes into the picture. Container runtimes such as Docker and Linux Containers (LXC) ease the deployment and maintenance of microservices.

Further, orchestrating microservices is crucial for handling the complexity of modern applications. Think of it like Ludwig van Beethoven leading an orchestra, making sure every member plays at the right moment to create beautiful music. This orchestration guides all the connected and independent components of an application to work together, completely integrated. Without it, the service will have many issues communicating and cooperating, causing performance problems and a messy network of dependencies that make scaling and managing the application very difficult.

The increasing popularity of microservices architecture and the complexity mentioned here led to the growth of orchestration platforms such as Docker Swarm, Mesos, and Kubernetes. These container orchestration platforms help manage containers in large and dynamic environments.

Having covered the fundamentals of microservices, in the upcoming section, you will now gain insights into how Docker has evolved during past years.

Evolution from Docker to Kubernetes

Process isolation has been a part of Linux for a long time in the form of Control Groups (cgroups) and namespaces. With the cgroup setting, each process has limited resources (CPU, memory, and so on) to use. With a dedicated process namespace, the processes within a namespace do not have any knowledge of other processes running in the same node but in different process namespaces. Additionally, with a dedicated network namespace, processes cannot communicate with other processes without a proper network configuration, even though they're running on the same node.

With the release of Docker, the mentioned process isolation was improved by easing process management for infrastructure and DevOps engineers. In 2013, Docker released the Docker open-source project. Instead of managing namespaces and cgroups, DevOps engineers manage containers through Docker Engine. Docker containers leverage the isolation mechanisms in Linux to run and manage microservices. Each container has a dedicated cgroup and namespaces. Since its release 11 years ago, Docker has changed how developers build, share, and run any applications, supporting them to quickly deliver high-quality, secure apps by taking advantage of the right technology, whether it is Linux, Windows, serverless functions, or any other. Developers just need to use their favorite tools and the skills they already possess to deliver.

Before Docker, virtualization was primarily achieved through virtual machines (VMs), which required a full operating system for each application, but led to some overhead in terms of resources and performance. Docker introduced a lightweight, efficient, and portable alternative by leveraging LXC technology.

However, the problem of interdependency and complexity between processes remains. Orchestration platforms try to solve this problem. While Docker simplified running single containers, it lacked built-in capabilities for managing container clusters, handling load balancing, auto-scaling, and deployment rollbacks to name some. Kubernetes, initially developed by Google and released as an open-source project in 2014, was designed to solve these challenges.

To better understand the natural evolution to Kubernetes, review some of the...