Mastering Memory Management in AKS 1.29

Search for a command to run...

No comments yet. Be the first to comment.
As we enter a historic period in technology, the race is on to define the next era of software development. The goal is no longer just to build tools for humans, but to design systems where artificial intelligence operates as a true partner. As Andre...

When you think of DNS, you might think of it as a simple system for translating domain names to IP addresses. But in the world of Kubernetes, DNS plays a much more pivotal role. Let's dive into the intricacies of DNS in Kubernetes and understand why ...

If you're working with databases, you've probably heard of Kafka, Kafka Connect, and connectors. In a nutshell, Kafka is a distributed streaming platform that allows you to publish and subscribe to streams of records, while Kafka Connect is a framewo...

In a recent project at work, we needed to monitor changes to data stored in multiple databases and services in real-time. To achieve this goal, we opted for Kafka as our distributed streaming platform. We chose Confluent Cloud, the hosted service pro...

Memory management plays a crucial role in ensuring optimal performance and resource efficiency in Azure Kubernetes Service (AKS). With the release of AKS 1.29, significant changes have been introduced to improve memory allocation and pod stability. In this blog, we will explore these changes and provide practical insights on how to optimize memory management in AKS 1.29. But first lets go through the basics of resource management in k8s.
In Kubernetes you can define CPU and memory (RAM) requirements for each container in a Pod. Resource Requests indicate the minimum amount of a resource that a container needs to run properly. The kube-scheduler uses this information to assign Pods to suitable nodes. Resource Limits, set by users, these limits prevent containers from consuming more resources than allocated. They are enforced to maintain fairness and resource efficiency within the cluster. Read more in kubernetes docs
If a node has surplus resources, a container might use more than its requested amount, subject to its defined limit. Consider a container with a 4GiB memory limit. If the container attempts to exceed this limit, the kubelet intervenes. This can result in process terminations within the container, often manifested as Out of Memory (OOM) errors.
However Kubernetes also includes eviction policies managed by the kubelet. These policies trigger Pod eviction if the node's available resources fall below specified thresholds. For instance, if the node's available memory dips below a defined threshold, the kubelet may evict Pods to reclaim resources, even though they are within their resource limit which brings us to the topic of this post.
In previous versions of AKS, memory management posed challenges due to a higher eviction threshold and a complex reservation formula. These factors often led to inefficient resource allocation and pod instability.
Higher Eviction Thresholds: Nodes would start evicting pods when the available memory dipped below 750 MiB, a mechanism to prevent system instability due to low memory.
Complex Memory Reservation: A regressive formula determined the amount of memory reserved for system processes and Kubernetes components, which impacted the allocatable memory for pods.
AKS 1.29 introduced significant changes in memory management, optimizing how resources are allocated and used.
Reduced Eviction Threshold: The new threshold is set at memory.available<100Mi, allowing for more efficient resource allocation and better pod stability.
Simplified Memory Reservation: The new formula for kube-reserved memory is the lesser of 20MB * Max Pods + 50MB or 25% of the total system memory. This change aims to simplify and potentially increase the allocatable memory.
Eviction Threshold: memory.available<750Mi
The regressive formula typically reserved:
25% of the first 4GB = 1GB (1024 MiB)
20% of the next 4GB (4GB to 8GB) = 0.8GB (819.2 MiB)
Total Reserved: 1024 MiB + 819.2 MiB = 1843.2 MiB
Allocatable Memory: 8GB - 1.8432GB - 0.75GB ≈ 5.41GB
Eviction Threshold: memory.available<100Mi
Memory Reservation: 20MB * 30 + 50MB = 650MB (approximately 0.65GB)
Allocatable Memory: 8GB - 0.65GB - 0.1GB = 7.25GB
Eviction Threshold: memory.available<750Mi
The regressive formula for a 4GB node typically reserved:
Total Reserved: 1024 MiB
Allocatable Memory: 4GB - 1GB - 0.75GB = 2.25GB
Eviction Threshold: memory.available<100Mi
Memory Reservation: Capped at 25% * 4GB = 1000MB (1GB), as it's lesser than 20MB * 70 + 50MB = 1450MB.
Allocatable Memory: 4GB - 1GB - 0.1GB = 2.9GB
For a detailed understanding of resource reservations in AKS, refer to Microsoft's official documentation.
The transition from the regressive formula in previous versions to the new calculation method in AKS 1.29 can result in different amounts of memory being reserved for kubelet and system processes. In AKS 1.29, the changes generally lead to a more predictable and potentially higher percentage of allocatable memory, particularly for larger VM sizes. The reduced eviction threshold in AKS 1.29 also signifies a more proactive approach to managing memory availability, enhancing node stability.
To effectively manage memory in AKS 1.29, stay updated with new changes, apply best practices, and continually adjust to your application needs. Efficient memory management is an ongoing journey that enhances your AKS cluster's performance.