DEV Community: Lorenzo Tettamanti

Kubernetes service meshes rely on “sidecar” proxies to handle traffic routing transparently, security
policies, and observability for your microservices—but manually bolting those proxies onto every Pod
spec quickly becomes a maintenance nightmare.

What if you could have Kubernetes do the work for you, automatically injecting the proxy whenever a Pod is created?

In this tutorial, we’re going to build exactly that: a Mutating Admission Webhook in Rust that hooks
into the Kubernetes API server, inspects incoming Pod specs, and—if they meet your criteria—patches
them on the fly to include an init‑container (for iptables setup) and your proxy‑sidecar.

Along the way, you’ll learn how to:

Define the AdmissionReview/AdmissionRequest and AdmissionResponse data structures
Wire up an async handler in Axum, complete with #[instrument] tracing for per-request logging
Craft a JSONPatch that adds init‑containers and sidecar containers via a base64-encoded payload
Stand up a TLS‑secured HTTP server using Rustls so Kubernetes can trust your webhook

By the end, you’ll have a drop‑in proxy injector that can be deployed alongside your service mesh
control plane—no more manual injection, no more drift, just automatic, consistent proxy injection
across your cluster.

All the code we walk through here is available on our GitHub repository—feel free to clone and explore it!

Let’s dive in!🚀

Admission Webhooks

What Are Admission Webhooks?

Admission webhooks are a type of dynamic admission controller in Kubernetes. They allow you to validate or modify (mutate) Kubernetes objects as they are submitted to the cluster.

There are two types of admission webhooks:

Validating Admission Webhooks – used to validate requests to the Kubernetes API server. They can accept or reject the request, but cannot modify the object.
Mutating Admission Webhooks – used to modify (mutate) objects before they are persisted. They can change or enrich the resource definition, such as injecting sidecars into pods.

Admission webhooks are HTTP callbacks that are invoked during the admission phase of an API request. The Kubernetes API server sends an AdmissionReview request to the webhook service, which then evaluates the request and responds with an AdmissionReview response.

The admission phase takes place after authentication and authorization, but before the object is stored in etcd.

You can configure the Kubernetes API server to call specific webhook services when certain operations (like CREATE, UPDATE, or DELETE) are performed on specific resources (such as Pods, Deployments, etc.).

How It Works

When a request is made to the Kubernetes API:

The request is authenticated and authorized.
The object goes through the admission phase, where it is passed to:
- Mutating webhooks (in sequence),
- Followed by validating webhooks (in parallel).
Based on the webhook responses, the request is either allowed, denied, or modified.
If allowed, the object is persisted in etcd.

Controllers vs. Webhooks

It’s important to distinguish between admission controllers and webhooks:

Admission controllers are built into the Kubernetes API server binary. They are enabled and configured by cluster administrators and cannot be extended at runtime.
Webhooks, on the other hand, are external HTTP services configured through the Kubernetes API. They provide a more flexible and extensible way to implement custom admission logic, and can be written in any language or framework.

Admission controllers can validate, mutate, or perform both operations depending on their configuration. While validating controllers can only inspect and accept/reject objects, mutating controllers can modify them before they are stored.

Building a Proxy Injector: The Structures

To begin, we need to define the data structures that will be used within our injector code. We use the pub keyword to make these structures accessible from other files within the module.
The first structure we need is AdmissionRequest, which represents a request sent to the admission webhook:

#[derive(Debug, Serialize, Deserialize)]
pub struct AdmissionRequest {
    uid: String,
    object: serde_json::Value,
}

uid: A unique identifier for this admission request, provided by the Kubernetes API server. It's used to correlate requests and responses.
object: This field contains the Kubernetes object (usually a Pod) being submitted. It's stored as a raw JSON value so we can inspect or mutate it flexibly.

Next, we define the AdmissionReview structure. This wraps the admission request and is used to process it:

#[derive(Debug, Deserialize, Serialize)]
pub struct AdmissionReview {
    #[serde(rename = "apiVersion", default = "default_api_version")]
    pub api_version: String,
    #[serde(default = "default_kind")]
    pub kind: String,
    pub request: AdmissionRequest,
    #[serde(skip_deserializing)]
    pub response: Option<AdmissionResponse>,
}

api_version: The version of the AdmissionReview API we're handling.
kind: Always "AdmissionReview" for admission webhooks.
request: Contains the actual AdmissionRequest sent by the API server.
response: Optional at deserialization time (we don't receive it from the client), but we populate it before responding to the API server. The default values for apiVersion and kind are provided by the following functions:

fn default_api_version() -> String {
    "admission.k8s.io/v1".to_string()
}

fn default_kind() -> String {
    "AdmissionReview".to_string()
}

After that, we define the AdmissionResponse structure, which is used to send a response back from the admission webhook:

#[derive(Debug, Serialize)]
pub struct AdmissionResponse {
    uid: String,
    allowed: bool,
    patch: Option<String>,
    #[serde(rename = "patchType")]
    patch_type: Option<String>,
}

uid: Must match the request's UID so Kubernetes knows which request this response is for.
allowed: Indicates whether the request is approved or denied.
patch: If set, this is a base64-encoded JSON patch to modify the original object before it's persisted in etcd.
patch_type: Typically "JSONPatch" if you're modifying the object. Required when patch is provided.

Building a Proxy injector: The injection logic

After defining the main structures, we need to create the proper injection logic.

We want a modular logic that can adapt to future changes and users' needs, while maintaining a simple program structure.

First of all, we need to create a simple function called check_and_validate_pod.

This function ensures that the pod meets our requirements before injecting the sidecar proxy into a pod.

The function follows this logic:

Checks if containers are present
- Iterates over each container in the pod's spec.containers.
- If a container's name contains "cortexflow-proxy":
- Logs an error.
- Returns an error: "The pod is not eligible for proxy injection. Sidecar proxy already present."`
Validates namespace annotations
- Retrieves the pod's namespace from metadata.namespace.
- Checks metadata.annotations for the key "proxy-injection".
- If it's set to "disabled":
  - Logs a warning.
  - Returns an error: "Automatic namespace injection is disabled."
Validates pod-level annotations
- Checks if the pod itself has "proxy-injection": "disabled" in metadata.annotations.
- If so:
  - Logs a warning.
  - Returns an error: "Automatic pod injection is disabled."
If all checks pass
- Returns Ok(true) indicating the pod is eligible for injection.

For the sake of brevity, I am not including the code below, but you can find the check_and_validate_pod code here.

Going back to our inject function, after calling the validation function, we expect two behaviours:

The pod is ready and eligible for injection
The pod is not eligible for injection

In the first case, we can apply the patch, which we'll define in the next chapter, and return an allowed: true Admission Response.
In the second case, we are not injecting the patch, and we return an allowed: false Admission Response.

⚠️For an unexpected issue, I can't include the code directly. You can find the code here

Building a Proxy injector: The patch

Now the magic happens ⭐. The patch is one of the most crucial parts in the proxy injector and is where all the variables are defined.

We are using serde_json to create a JSON Patch and lazy_static to optimize the resources by initializing the variable when it is first accessed, in contrast to the regular static data, which is initialized at compile time.

The patch is divided into two parts:

Initialize Iptables
Initialize the proxy

In the first part, we are using iptables to redirect all the external traffic — in particular, TCP and UDP traffic — to specific ports.

We decided to bind the TCP traffic to port 5054 and the UDP traffic to port 5053.

Note:The init-iptables operation cannot be skipped. Otherwise, our system will not bind the traffic to the ports we chose, resulting in endless hours of debugging.

In the second part, we're doing another add operation to include the image of the proxy server.

We're also explicitly setting the TCP (5054) and UDP (5053) ports using the containerPort key.

⚠️For an unexpected issue, I can't include the patch code directly. You can find the code here

Building a Proxy injector: The server logic

In the last part we need to create a server to serve the API we made in the previous step. For this step we use the axum crate and we proceed creating a route. We decided to call the endpoint /mutate as a reminder for our Mutating Admission Webhook. As second step we proceed to associate the inject function as POST request and we bind the 9443, this ends the route configuration. The last step is to load the TLS certificate files tls.crt and tls.key.

Note:
Kubernetes requires TLS certificates to serve APIs over HTTPS. Failing to provide the certificates will result in a non-functional webhook service

How to generate a TLS certificate?

Working with TLS certificates may be something unfamiliar to the majority of people reading this article. Cert-manager is the easiest way to generate the tls.key and tls.crt keys. All you have to do is installing cert-manager using the kubernetes CLI

kubectl apply -f https://github.com/cert-manager/certmanager/releases/latest/download/cert-manager.yaml

The installation may take a while so you can take a small break to let your mind rest a little bit!

After cert-manager is installed you can get the secrets using the following commands

Return the data.ca file

kubectl get secret proxy-injector-tls -n cortexflow -o jsonpath='{.data.ca\.crt}'

Return the tls.key file

kubectl get secret proxy-injector-tls -n cortexflow -o jsonpath='{.data.tls\.key}'

Return the tls.crt file

kubectl get secret proxy-injector-tls -n cortexflow -o jsonpath='{.data.tls\.crt}'

Note:
For security reasons, do not share these secrets with anyone. Leaking them may compromise your system’s security and get you in trouble.

We decided to automate this process in the install.sh script that you can find in the repository

⚠️For an unexpected issue, I can't include the code directly. You can find the code here

Building a Proxy injector: Deploying to Kubernetes

Now that all components are in place, the final step is to create a Kubernetes manifest to deploy the application into our cluster.
Below is an example YAML file we used to deploy the proxy injector within our namespace.

Pay special attention to the spec section: here, we define a custom selector that grants the necessary permissions for the injector to modify incoming Pod definitions—specifically, to add the sidecar proxy container automatically.

⚠️For an unexpected issue, I can't include the manifest code directly. You can find the code here

Conclusion

In the first part, we've covered the foundamentals of proxy injection,going through admission webhooks and admission controllers, while in the second part we have built all the logic from scratch using the Rust programming covering a lot of practical aspects such as defining the structures,building the patch, launching the axum server and interacting with the Kubernetes API.

In the next part of this series, we’ll create a sidecar proxy and all the basic functions such as service discovery, metrics, observability and messaging 🚀

Enjoying the content? Show us some love with a ⭐ on GitHub! And be sure to catch the first episode of the series, where we take a deep dive into the world of service meshes.
Stay tuned—and stay curious. 🌐🧩

What is a service mesh? Discover the key functionalities, pros and cons of modern service mesh technologies [6 min read] 🚀

Lorenzo Tettamanti — Mon, 14 Apr 2025 22:59:18 +0000

Lorenzo Tettamanti for CortexFlow

Apr 14 '25

Service Mesh Explained: What's a service mesh?

#kubernetes #microservices #architecture #learning

Comments

6 min read

Service Mesh Explained: What's a service mesh?

Lorenzo Tettamanti — Mon, 14 Apr 2025 13:00:00 +0000

Hey there, super curious minds,

let’s be really honest here...if you’ve been working with microservices long enough, you’ve probably hit that point where everything feels like a group project with no team lead. Services yelling at each other across the cluster, authentication scattered everywhere, observability held together by logs and prayer, and your brain quietly whispering, “This was supposed to be better than monoliths?”

That’s where the idea of a service mesh sneaks in. It promises to solve a lot of those problems: better traffic control, resilience, security, observability—all packed into a neat, layered abstraction. It’s the glue between your services... or maybe the smart traffic cop, the bouncer, and the observability dashboard all rolled into one.

But what exactly is a service mesh?

Why is everyone in the Kubernetes ecosystem talking about it?

And more importantly: do you really need one?

In this article, we’ll break down the core concepts behind service meshes, including what they are, what problems they solve, and how they work under the hood. We’ll dig into control planes, data planes, proxies, and other buzzwords—but with a practical mindset (and hopefully, no tears).

No YAML dumps or complex install guides here—this is the conceptual groundwork. Think of it as your first casual conversation with the service mesh world before things get serious. Now let’s get started! 🎉

Microservices

In the past, applications were smaller, with fewer functionalities, and most of them followed a monolithic architecture. However, as businesses grew and applications became more complex, a new approach started to emerge. This shift was driven by challenges like handling dynamic traffic demands, improving observability, and ensuring better monitoring. As applications began to scale, companies needed a more flexible and efficient way to tackle these challenges. That’s where microservices architecture came into play.

In a monolithic architecture, the entire application exists as a single unit (a monolith). In contrast, a microservices architecture breaks down the application into smaller, independently deployable services, which communicate with each other using APIs.

Let’s consider an example: an e-commerce platform that features a main page for purchasing products, a payment page, a recommendation page, a customer care page, and so on. In a monolithic approach, the entire platform – including the main product page, payment gateway, recommendation system, customer care, and more – would all reside in one large application. Instead of this, with a microservices approach, we can break down the platform into individual services (or deployable units) for each functionality. This is similar to the "divide et impera" strategy that anyone familiar with data structures and algorithms has heard at least once in their life. Using this methodology, each service has a single responsibility. For our e-commerce platform, this makes maintenance easier and helps avoid the risk of introducing unexpected bugs with every update.

Image: Monolithic vs microservices architecture: in a monolithic architecture all the application is concentrated in one place while in a microservices architecture, every service is independent and can be easily maintained without influencing other services

What is a service mesh?

When we talk about microservice architecture, we’re implicitly referring to a distributed environment where services communicate solely through APIs. In such an environment, a service mesh introduces an abstract infrastructure layer that manages service-to-service communication. It ensures efficient handling of service requests by controlling traffic, providing observability, enforcing security, and enabling service discovery.

Key components of a service mesh

The Control Plane is the heart of the service mesh. It coordinates the behavior of proxies and provides APIs for operations and maintenance teams to manipulate and monitor the entire network. This plane is crucial in the context of network design and cloud computing as it manages how data packets travel across the network.

Here, decisions are made regarding the routing of network traffic. On the other hand, the Data Plane is responsible for moving the data based on the routing choices made by the control plane.

The Control Plane performs several important functions:

Network Layout Management: It defines and manages the structure of the network.
Routing Tables & Traffic Flow: It updates routing tables and controls how traffic flows through the network.
Enforcing Rules: It ensures that network policies are followed.

Control planes are also common in traditional networking with protocols like OSPF and BGP. They are a key part of Software-Defined Networking (SDN) through centralized controllers and are managed by tools like Kubernetes in cloud computing to handle container orchestration.

The control plane ensures that the network operates smoothly and securely, optimizing the overall network performance.

Data Plane: Moving the Data

The Data Plane intercepts the communication between different services and processes it based on the decisions made by the control plane.

Key Tasks of the Sidecar Proxy

In a service mesh, the sidecar proxy is responsible for performing various key tasks:

Service Discovery: The sidecar proxy identifies all the available upstream or backend service instances.
Health Checking: It ensures the upstream service instances are healthy and capable of handling network traffic. This can be done
through:

Active health checks (e.g., sending pings to a /healthcheck endpoint).
Passive health checks (e.g., detecting unhealthy states based on
repeated 5xx errors).

Routing: Based on a REST request the proxy determines which upstream service cluster should handle the request.
Load Balancing: Once the appropriate service cluster is identified, the proxy decides which specific service instance should handle the request, including settings for timeouts, circuit breaking, and retry policies.
Security & Authentication : For incoming requests, the proxy verifies the caller's identity using mechanisms like mTLS. It then checks whether the caller is authorized to access the requested endpoint. If not, the proxy returns an unauthenticated response.
Observability: The proxy generates detailed statistics, logs, and distributed tracing data for each request. This helps operators understand the flow of traffic across the services and troubleshoot any issues that arise.

Benefits of using a service mesh

Centralized Traffic Management: A service mesh allows for fine-grained control over communication between services, including advanced routing capabilities, retries, and failovers. This can be crucial in ensuring high availability and resilience.
Security at Scale: Security is paramount in microservices architecture, and service mesh addresses this by providing a uniform layer for implementing security measures like encryption, authentication, and authorization. It ensures that communication between services remains secure without burdening individual services with security concerns.
Resilience and Fault Tolerance: Service mesh introduces capabilities for implementing circuit breaking, retries, and timeouts, promoting resilience in the face of failures. It enables applications to gracefully handle faults, preventing cascading failures and ensuring optimal user experiences.
Enhanced Observability: Service mesh provides unparalleled visibility into the interactions between microservices. With features like distributed tracing and monitoring, organizations can gain insights into the performance and behavior of their applications, facilitating efficient troubleshooting and optimization.

But Wait... Why Not Use a Service Mesh?

Before we hand the service mesh the keys to our infrastructure, let’s pump the brakes.

Service meshes are incredibly powerful—but they’re also not free. Not in performance, complexity, or cognitive load. Here’s why you might not want one just yet:

It’s Heavy: You’re adding sidecar proxies to every service. That’s more network hops, more memory, more CPU, and more configuration. You better have a good reason (or a beefy cluster).
Steep Learning Curve: Control planes, mTLS, traffic shifting, retries... these are all good things, but they require real understanding and new operational tooling.
Not Always Needed: If you’re running five services in dev with no real need for advanced routing or auth, a service mesh is like bringing Kubernetes to a shell script. Start with simpler tools and scale your complexity as needed.
Debugging Becomes... “Fun”: That one sidecar proxy that failed to inject? That Envoy config you didn’t understand? Debugging service mesh issues can sometimes feel like playing 4D chess while blindfolded.

So no, a service mesh is not mandatory. It’s not a badge of honor. It’s a tool—and like any tool, you need to reach for it when and if it solves your specific problems.

Wrapping Up: The Mesh Is Only the Beginning

The service mesh world is vast, fast-moving, and—let’s admit it—a little intimidating. But if you’re building distributed systems, or just tired of duct-taping together retries, mTLS, and observability, it’s a space worth exploring.

In this first part, we’ve covered why service meshes exist, what they are, and when they make sense (or don’t). Hopefully, you’re walking away with a solid mental model, a few new questions, and a bit more clarity about what all the buzz is about.

Service meshes aren’t just a passing trend—they’re part of a broader shift toward smarter, more composable infrastructure. While the concepts can feel heavy at first, the payoff in resilience, visibility, and security is real.

Whether you’re just peeking into this space or already wrestling with sidecars and control planes, remember: you’re not alone._ And this journey?_ It's only just begun.

In the next part of this series, we’ll dive into real-world implementations 🚀

Until then, keep your services chatty (but secure), your architectures simple (until they can’t be), and your curiosity sharp.

Mesh wisely. Stay tuned—and stay curious. 🌐🧩

Kubernetes Explained: Understanding the Key Components Driving Modern Infrastructure ⚙️

Lorenzo Tettamanti — Sun, 05 Jan 2025 19:57:16 +0000

📖 Introduction

Hi everyone, in today's episode we'll explore the Kubernetes key components. In the latest episode, we learned why Kubernetes is so important for software engineering and why almost every big company relies on it. Our journey will be supported with examples and illustrations to help everyone understand the essential functionalities of Kubernetes.

Let's dive into it! 🚢

📒 Glossary:

Here’s a list of common words and terms used in this article. This will help you form a basic understanding before reading the full article.

Container:
A container is a standardized unit of software that packages an application’s code along with all its dependencies, libraries, and configuration files needed to run. Containers ensure that the software behaves consistently regardless of the environment. Common container technologies include Docker and Kubernetes.

Distributed system:
A distributed system is a collection of independent computers or nodes that work together to appear as a single coherent system to the end user. These systems communicate with one another over a network to coordinate tasks, share resources, and achieve common objectives.

Daemon:
In the field of container orchestration, a daemon refers to a background service or process that continuously runs and manages tasks without user intervention.

Production Environment:
The production environment is the setting where an application or service is made available to end-users. In this environment, the application is expected to operate stably, efficiently, and securely, often under real-world traffic conditions and with configurations optimized for performance.

API:
An API (Application Programming Interface) is a set of rules and definitions that allows different software applications to communicate with each other. APIs define how requests are sent, data is structured, and responses are received. APIs are commonly used for web services (e.g., REST, GraphQL), hardware, operating systems, and more.

YAML:
YAML (YAML Ain't Markup Language) is a human-readable data serialization format often used for configuration files. YAML uses hierarchical indentation to represent data structures like maps, lists, and scalar values. It is easy to read and write, making it popular in container configuration and resource orchestration.

🏗️ Architecture

What's a Kubernetes cluster?

A Kubernetes cluster is a set of machines, called nodes, that can run containerized applications. Kubernetes adopts a distributed architecture based on a client-server model to orchestrate the containers. The Kubernetes architecture is composed of two core components:

👨🏻‍⚖️ Master Node

🧠 The control plane

The brain of the cluster. It is responsible for managing the state of the cluster. In production environments, the control plane usually runs on multiple nodes that span across several data center zones. The second is a set of worker nodes. These nodes run the containerized application workloads. The containerized applications run in a Pod.

What's a Pod?

Pods are the smallest deployable units in Kubernetes. A pod hosts one or more containers and provides shared storage and networking for those containers. Pods are created and managed by the Kubernetes control plane. They are the basic building blocks of Kubernetes applications.

Now let’s dive a bit deeper into the control plane. It consists of several core components such as the API server, etc, scheduler, and controller manager.

🤖 API server:

This is the primary interface between the control plane and the rest of the cluster. It exposes a RESTful API that allows clients to interact with the control plane and submit requests to manage the cluster. The API server is the gateway for the kubectl which is a command line tool for communicating with the the control plane using the API.

For example the command

 kubectl run "pod-name" --image="image-name"

is used to create a Pod with a desired pod-name and with the desidered image-name

💾 etcd

Etcd is an open-source distributed key-value store and plays an essential role in the Kubernetes control plane. It stores the cluster's persistent state. In Kubernetes etcd acts as the primary datastore, storing all the cluster data including all the configuration, state, and metadata. It is used by the API server to retrieve and update the cluster's state, ensuring that the actual state of the cluster matches the desired state defined by the users and the administrator.

Fun fact: ETCD is composed of the words "etc" and "d." "etc" is derived from the UNIX directory "/etc," which houses configuration files, and "d" stands for "distributed"

📓 Scheduler:

The scheduler is responsible for scheduling pods onto the worker nodes in the cluster. It uses information about the resources required by the pods and the available resources on the worker nodes to make placement decisions.
In a cluster, Nodes that meet the scheduling requirements for a Pod are called feasible nodes. If none of the nodes are suitable, the pod remains unscheduled until the scheduler is able to place it.

Kube-scheduler selects a node for the pod in a 2-step operation:

Filtering:
The filtering step identifies the nodes where the Pod can be scheduled. After this step, the node list contains the suitable nodes (usually more than one). If the list is empty, the Pod is not (yet) schedulable.
Scoring:
In the scoring step, the scheduler ranks the remaining nodes to choose the best placement for the Pod. Each node that passed the filtering is given a score based on the active scoring rules.

Finally, kube-scheduler assigns the Pod to the Node with the highest ranking. If there is more than one node with equal scores, kube-scheduler selects one of these at random.

🧑🏻‍💼 Controller manager:

The controller manager is responsible for running controllers that manage the state of the cluster. The replication controller ensures that the desired number of replicas of a pod is running, the deployment controller manages the rolling update and rollback of deployments, and the endpoint controller manages the endpoint of the services.

Image 1: A summary of the main components of the master node

👷🏻 Worker Nodes

The core components of Kubernetes running on the worker nodes include the kubelet, container runtime, and kube-proxy.

📦 Kubelet

The kubelet is a daemon that runs on each worker node. It's the primary node-agent that runs on each node. It is responsible for communicating with the control plane. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider. It receives instructions from the control plane about which pods to run on the node, and ensures that the desired state of the pods is maintained.
The kubelet works in terms of a PodSpec. It takes a set of PodSpecs and ensures that the containers, described in those PodSpecs are running and healthy.
The Kubelet doesn't manage containers that were not created by Kubernetes.
Here's an example of a PodSpec:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx-container
      image: nginx:latest
      ports:
        - containerPort: 80
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"
      volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d
  volumes:
    - name: nginx-config
      configMap:
        name: nginx-config-map
  restartPolicy: Always

In this context the Kubelet reads the PodSpec and tells the container runtime to download the container image "nginx:latest", next it runs the containers and mounts the volume defined in spec.volumes. The kubelet allocates the resource defined in spec.resources and monitors the health of the container.

⚙️ Container Runtime

The container runtime runs the containers on the worker nodes. It is responsible for pulling the container images from a registry. Start and stop the containers and manage the containers' resources. Kubernetes supports container runtimes such as containered, CRI-O, and any other implementation of the Kubernetes CRI (Container Runtime Interface). There are 2 types of Container Runtimes: Low-level Container Runtime and High-Level Container Runtimes. Since this is a broad topic I will expand on the concept of runtime containers in a future article.

💻 Proxy

The kube-proxy is a network proxy that runs on each worker node. It is responsible for routing traffic to the correct pods. It also provides load balancing for the pods and ensures that traffic is distributed evenly across them. After kube-proxy is installed it authenticates with the API server and when new services or endpoints are added or removed the API server communicates these changes to the kube-proxy, then kube-proxy applies these changes as NAT rules. When traffic is sent to a service it's redirected to a backend Pod based on these rules. As for the Container Runtimes this is a small introduction about what's the kube-proxy and what are his main functionalities and I'll expand on all these concepts in a dedicated article.

Image2: A summary of the main components of a kubernetes cluster that includes the master node and two worker nodes. In the first worker node there are 5 pods running microservices and the second worker node there are 3 pods running microservices

🚀 Conclusions

Kubernetes components are a beautiful example of technology and sophisticated infrastructure. Today we explored how the core components work and interact to enable efficient application deployment and scaling. In the next episode, I'll show you how to start your first Kubernetes cluster and how to deploy an application!

Thank you for reading! 🙏

Learn the benefits of Kubernetes and why Airbnb, Spotify and CERN use it!

Lorenzo Tettamanti — Sat, 04 Jan 2025 13:19:07 +0000

Kubernetes Explained: Benefits, Use Cases, and Why Airbnb,Spotify and CERN Rely on It 🤖

Lorenzo Tettamanti ・ Jan 1

#kubernetes #learning #softwaredevelopment #softwareengineering

Kubernetes Explained: Benefits, Use Cases, and Why Airbnb,Spotify and CERN Rely on It 🤖

Lorenzo Tettamanti — Wed, 01 Jan 2025 22:27:12 +0000

📖 Introduction

Hi everyone, in today's episode we'll dive into Kubernetes, one of the most impactful tools in modern software development. We'll learn why Kubernetes is a game-changer for developers and why almost every big company relies on it. Our journey will be supported by several examples taken from some success stories in the modern world of software engineering such as AirBnb, Spotify and the European Organization for Nuclear Research.

Originally designed by Google in 2014 as an upgrade of their internal cluster manager "Borg" to handle Google’s massive scale of operations, Kubernetes started gaining traction among developers in 2015. Over the years, the Kubernetes community has grown exponentially, numbering thousands of contributors all over the world. This growth has consolidated Kubernetes' position as one of the largest and most influential open-source projects globally, second only to Linux in terms of its impact on modern IT infrastructure.

Why Developers Love Kubernetes 💓

🖥️ Simplifies Work for Developers

Kubernetes helps manage applications by automating tasks like deploying, scaling, and updating. This means less manual work for developers and IT teams, allowing them to focus on building and improving apps. Kubernetes helps companies deliver reliable, scalable, and cost-effective applications.

📈 Scalability Made Simple

As companies grow, so do their applications. But there's a catch: as applications scale up, managing all the containers manually becomes a real nightmare. Nowadays, companies can easily reach dozens or hundreds of microservices, leading to highly complex infrastructures to orchestrate.
What if a node fails? How do you manage traffic and handle request peaks? For a simple website, this might not be a problem, but for a big company, this is an everyday challenge.

Kubernetes makes it easy to scale up or down based on how many people are using an app. This ensures everything runs smoothly, even during busy times. Think of Kubernetes as a conductor for your applications!

Kubernetes also supports horizontal and vertical scaling, allowing applications to handle increased traffic and workload demands efficiently. By adjusting the number of running instances or the resources allocated to each instance, Kubernetes ensures that applications can scale up or down seamlessly, thereby enhancing performance and reliability.

	Horizontal scaling	Vertical scaling
Aim	Increasing/decreasing the number of machines	Adjusting the CPU memory on existing machine
Best Use In	stateless applications	stateful applications
Scalability	High	Limited to maximum resources
Fault tolerance	Higher, one fault doesn't effect other	lower, one fault can effect other
cost	Can be cost-effective	Can lead to higher costs

Table 1: Examples of horizontal and vertical scaling

🤸‍♀️ Adapts to Changing Needs (Flexibility)

Kubernetes let companies quickly deploy new features or make updates. It also works with multiple cloud services, so businesses can use the best tools for their needs without being locked into one provider.
The Kubernetes community has developed several strategies and best practices to tackle challenges related to scalability and high availability. These include using multi-replica deployments, configuring readiness and liveness probes, implementing Pod Disruption Budgets, and utilizing node affinity and anti-affinity rules. These strategies help ensure that services remain operational and accessible even during node maintenance or failures. For example, Spotify and Airbnb benefit from these HA strategies by maintaining continuous service availability despite underlying infrastructure changes or failures.

💵 Cost Efficiency Through Automation

Imagine this: You and your team have successfully proposed and worked on a new feature and the Head of Software Engineering has approved it.
What could go wrong? A hidden bug resulting in downtime! Downtime can be costly for your application leading to a bad user experience, a damaged reputation, and a loss of profit.

Kubernetes helps an application remain accessible with minimal interruptions. By efficiently managing resources, Kubernetes helps reduce costs. Companies only use what they need, avoiding wasted computing power.

🥳 Ensuring High Availability with Kubernetes

Kubernetes plays a critical role in enhancing the high availability and reliability of microservices. It offers a powerful framework for building highly available applications by running multiple replicas of containers and managing them through controllers like ReplicaSets and Deployments. These controllers ensure that the desired number of replicas is always running while maintaining service availability even during failures. The Kubernetes community has developed several strategies and best practices to tackle challenges related to scalability and high availability. These include using multi-replica deployments, configuring readiness and liveness probes, implementing Pod Disruption Budgets, and utilizing node affinity and anti-affinity rules. These strategies help ensure that services remain operational and accessible even during node maintenance or failures.

Open-Source 🧑‍💻

With over 120k+ commits, 112k stars, and a community of over 7k developers, Kubernetes is the second-largest project on GitHub. Its vast and active community ensures continuous development, with regular updates and continuous monitoring from contributors worldwide. This collaborative effort not only accelerates innovation but also ensures the platform remains secure, scalable, and adaptable to evolving industry needs. The growing ecosystem around Kubernetes, which includes many plugins, tools, and integrations, showcases its importance in today's technology landscape.

🧑‍💻 Success Stories: How Top Companies Use Kubernetes

Big names like Airbnb and Spotify use Kubernetes to keep their services running smoothly and to handle millions of users. They’ve seen better performance and faster updates, helping them stay ahead of competitors.

🏩 Airbnb: From Monolith to Microservices

Initially, Airbnb operated on a Ruby on Rails monolith known as Monorail. However, as the company grew, this monolithic architecture became a bottleneck, leading to dependency issues and operational inefficiencies. To address these challenges, Airbnb began migrating to a service-oriented architecture SOA in 2018, which helped in managing dependencies more effectively and enhancing scalability
Airbnb leverages Kubernetes to efficiently manage its cloud infrastructure and handle the daily fluctuations in traffic.
Airbnb has transitioned almost all of its online services from manually orchestrated AWS EC2 instances to Kubernetes, significantly enhancing its operational efficiency.

Airbnb's infrastructure comprises thousands of nodes spread across nearly a hundred Kubernetes clusters 😲. The Kubernetes Cluster Autoscaler plays a crucial role in dynamically adjusting the size of these clusters based on current demand. This dynamic scaling ensures that Airbnb can handle peak travel seasons without unnecessary overspending during off-peak times.

🎵 Spotify: Scaling Music Streaming with Kubernetes:

Spotify was an early adopter of microservices and Docker, deploying containerized microservices across its fleet of virtual machines (VMs) with a homegrown container orchestration system called Helios. However, by late 2017, it became apparent that a small team managing Helios was less efficient compared to adopting a solution supported by a larger community. Recognizing the potential benefits of Kubernetes, Spotify decided to migrate to this open-source container orchestration platform. Jai Chakrabarti, Director of Engineering, Infrastructure and Operations at Spotify, noted that Kubernetes not only complemented Helios but eventually replaced it due to its feature richness and robust community support. This migration allowed Spotify to handle its rapidly growing infrastructure more effectively, automate deployments, and ensure high availability across different regions.

One of the significant challenges Spotify faced before adopting Kubernetes was managing the scalability strain during major music events, album releases, or viral song trends. Manually scaling resources to handle traffic surges was slow and often led to service disruptions. Kubernetes provided a solution by enabling Spotify to automate resource scaling and improve resource utilization, ensuring a seamless user experience even during peak demand periods.

⚛️ CERN: Managing Big Data with Kubernetes:

The European Organization for Nuclear Research is a great example of big data and high-demanding infrastructure. Currently, CERN stores over 500 petabytes (1PB = 1000 TB) of data and the number is expected to increase to 5,000 PB with future upgrades to its accelerators. To put it into perspective, nowadays, common computers use a typical 1TB hard disk to store data, if we stacked 5,000,000 1TB hard drives on top of each other, the stack would be 130 kilometers high 😮. This is an extreme example but is useful to help us visualize the magnitude of the problem.

To address the challenges of data storage, processing, and scalability, CERN has increasingly turned to Kubernetes. It has enabled CERN to handle its extreme data workload peaks, particularly during periods leading up to major conferences. The organization is looking towards a more hybrid infrastructure, leveraging both on-premises resources and public cloud services to meet these demands efficiently.

The transition to Kubernetes was also driven by the need for scalable infrastructure to support Continuous Integration and Continuous Delivery (CI/CD) workflows. The traditional Docker-based solution became obsolete, prompting CERN to adopt Kubernetes Runners, which provide a more flexible and scalable environment for GitLab CI/CD pipelines.

Furthermore, the application of Kubernetes extends to the efficient utilization of GPU resources for machine learning tasks. CERN's Large Hadron Collider (LHC) generates billions of particle collisions per second, resulting in hundreds of petabytes of data that need to be reconstructed and analyzed.

🚀 Conclusions

Kubernetes has transformed modern IT by simplifying app management, enabling scalability, and optimizing resources. Its adoption by companies like Airbnb, Spotify, and CERN highlights its value in handling complex infrastructures and ensuring high availability.

In the next episode, I'll dive into how Kubernetes infrastructure works.

Thank you for reading! 🙏