User Namespaces: Stateful Pods Now Available in Kubernetes 1.28!
Kubernetes v1.25 introduced support for user namespaces only for stateless Pods. With Kubernetes …
Kubernetes v1.27, released in April 2023, introduces improvements in Memory QoS (alpha), enabling more efficient memory management on Linux nodes.
Support for Memory QoS was initially introduced in Kubernetes v1.22, with some limitations identified later regarding the calculation of memory.high. These limitations have now been addressed in Kubernetes v1.27.
Kubernetes allows you to optionally specify how much of each resource a container requires in the Pod specification. The most common resources are CPU and memory.
An example of a Pod manifest defining a container’s resource requirements might look like this:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: nginx
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "64Mi"
cpu: "500m"
spec.containers[].resources.requests
When you specify the resource request for containers in a Pod, the Kubernetes Scheduler uses this information to decide on which node the Pod will be placed. The Scheduler ensures that the sum of the resource requests of the scheduled containers for each resource type is less than the total allocated resources on the node.
spec.containers[].resources.limits
When you set the resource limit for containers in a Pod, the Kubelet enforces these limits so that the running containers cannot use more of these resources than you have specified.
When the Kubelet starts a container as part of a Pod, it passes the requests and limits for CPU and memory to the container runtime. The container runtime assigns both the CPU request and the CPU limit value to a container. Provided the system has free CPU time, containers are entitled to as much CPU as they request. However, containers cannot use more CPU than the configured limit, i.e., the CPU usage of the containers is throttled if they use more CPU than the specified limit within a given time interval.
Before the introduction of the Memory QoS feature, the container runtime only used the memory quota and ignored the memory request (requests were and are still used to influence scheduling). If a container uses more memory than the configured limit, the Linux Out Of Memory (OOM) Killer is triggered.
Let’s compare how the container runtime typically configures memory requests and limits in cgroups on Linux, with and without the Memory QoS feature:
Memory Request
The memory request is primarily used by the Kube-Scheduler during (Kubernetes) Pod scheduling. In cgroups v1, there are no controls to specify the minimum amount of memory that the cgroups must always retain. Therefore, the container runtime did not use the requested memory amount value set in the Pod specification.
Cgroups v2 introduced a memory.min setting, which is used to specify the minimum amount of memory that should be available to the processes within a specific cgroup. If a cgroup’s memory usage is within its effective minimum limit, the memory of the cgroup will not be reclaimed under any circumstances. If the kernel cannot maintain at least memory.min bytes of memory for the processes within the cgroup, the kernel activates its OOM-Killer. In other words, the kernel guarantees that at least this memory is available or terminates processes (which may be outside the cgroup) to make the memory more available. Memory QoS maps memory.min to spec.containers[].resources.requests.memory to ensure memory availability for containers in Kubernetes Pods.
Memory Limit
The memory.limit specifies the memory limit beyond which a container cannot request more memory. If the container tries to allocate more memory than the limit, it is handled accordingly by the system.
With the new features in Kubernetes 1.27, developers and DevOps teams can now optimize the memory management of their applications. This leads to better resource utilization and fewer outages caused by the OOM-Killer. Take advantage of these new functionalities and make your Kubernetes environments more efficient. ayedo is here as your Kubernetes partner to help you implement these innovations.
Source: Kubernetes Blog
Kubernetes v1.25 introduced support for user namespaces only for stateless Pods. With Kubernetes …
Introduction The Kubernetes community took a significant step with version v1.24 by digitally …
In the latest version of Kubernetes, v1.27, there’s an exciting new feature: the ability to …