Skip to content

Commit 5c678ef

Browse files
harcheiholder101
authored andcommitted
Graduate swap to Beta 1
Signed-off-by: Itamar Holder <iholder@redhat.com>
1 parent ade6b45 commit 5c678ef

File tree

2 files changed

+94
-15
lines changed

2 files changed

+94
-15
lines changed

keps/sig-node/2400-node-swap/README.md

+90-13
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,10 @@
88
- [Goals](#goals)
99
- [Non-Goals](#non-goals)
1010
- [Proposal](#proposal)
11+
- [Enable Swap Support only for Burstable QoS Pods](#enable-swap-support-only-for-burstable-qos-pods)
12+
- [Set Aside Swap for System Critical Daemon](#set-aside-swap-for-system-critical-daemon)
13+
- [Steps to Calculate Swap Limit](#steps-to-calculate-swap-limit)
14+
- [Example](#example)
1115
- [User Stories](#user-stories)
1216
- [Improved Node Stability](#improved-node-stability)
1317
- [Long-running applications that swap out startup memory](#long-running-applications-that-swap-out-startup-memory)
@@ -17,6 +21,7 @@
1721
- [Virtualization management overhead](#virtualization-management-overhead)
1822
- [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)
1923
- [Risks and Mitigations](#risks-and-mitigations)
24+
- [Security risk](#security-risk)
2025
- [Design Details](#design-details)
2126
- [Enabling swap as an end user](#enabling-swap-as-an-end-user)
2227
- [API Changes](#api-changes)
@@ -30,7 +35,8 @@
3035
- [Graduation Criteria](#graduation-criteria)
3136
- [Alpha](#alpha)
3237
- [Alpha2](#alpha2)
33-
- [Beta](#beta)
38+
- [Beta 1](#beta-1)
39+
- [Beta 2](#beta-2)
3440
- [GA](#ga)
3541
- [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
3642
- [Version Skew Strategy](#version-skew-strategy)
@@ -166,6 +172,66 @@ administrators can configure the kubelet such that:
166172

167173
This proposal enables scenarios 1 and 2 above, but not 3.
168174

175+
### Enable Swap Support only for Burstable QoS Pods
176+
Before enabling swap support through the pod API, it is crucial to build confidence in this feature by carefully assessing its impact on workloads and Kubernetes. As an initial step, we propose enabling swap support for Burstable QoS Pods by automatically calculating the appropriate swap values, rather than allowing users to input these values manually.
177+
178+
Swap access is granted only for pods of Burstable QoS. Guaranteed QoS pods are usually higher-priority pods, therefore we want to avoid swap's performance penalty for them. Best-Effort pods, on the contrary, are low-priority pods that are the first to be killed during node pressures. In addition, they're unpredictable, therefore it's hard to assess how much swap memory is a reasonable amount to allocate for them.
179+
180+
By doing so, we can ensure a thorough understanding of the feature's performance and stability before considering the manual input of swap values in a subsequent beta release. This cautious approach will ensure the efficient allocation of resources and the smooth integration of swap support into Kubernetes.
181+
182+
Allocate the swap limit equal to the requested memory for each container and adjust the proportion of swap based on the total swap memory available.
183+
184+
#### Set Aside Swap for System Critical Daemon
185+
186+
System critical daemons (such as Kubelet) are essential for node health. Usually, an appropriate portion of system resources (e.g., memory, CPU) is reserved as system reserved. However, swap doesn't inherently support reserving a portion out of the total available. For instance, in the case of memory, we set `memory.min` on the node-level cgroup to ensure an adequate amount of memory is set aside, away from the pods, and for system critical daemons. But there is no equivalent for swap; i.e., no `memory.swap.min` is supported in the kernel.
187+
188+
Since this proposal advocates enabling swap only for the Burstable QoS pods, this can be done by setting `memory.swap.max` on the cgroups used by the Burstable QoS pods. The value of this `memory.swap.max` can be calculated by:
189+
190+
memory.swap.max = total swap memory available on the system - system reserve (memory)
191+
192+
This is the total amount of swap available for all the Burstable QoS pods; let's call it `TotalPodsSwapAvailable`. This will ensure that the system critical daemons will have access to the swap at least equal to the system reserved memory. This will indirectly act as having support for swap in system reserved.
193+
194+
### Steps to Calculate Swap Limit
195+
196+
1. **Calculate the total memory requests of the pod:**
197+
- Sum up the memory requests of all containers in the pod. Let's call this value `TotalMemory`.
198+
199+
2. **Determine the swap proportion for each container:**
200+
- For each container, divide its memory request by the `TotalMemory`. The result will be the proportion of requested memory for that container within the pod. Let's call this value `RequestedMemoryProportion`.
201+
- If a container is defined with memory requests == memory limits, its `RequestedMemoryProportion` is defined as 0.Therefore, as can be seen below, its overall swap limit is also 0.
202+
203+
3. **Calculate the total swap memory available:**
204+
- `TotalPodsSwapAvailable` is the total amount of memory available for the pods. Divide the available swap memory by the total physical memory. Let's call this value `SwapMemoryProportion`.
205+
206+
4. **Calculate the swap limit for each container:**
207+
- Multiply the `RequestedMemoryProportion` of a container by its memory request and then multiply the result by the `SwapMemoryProportion`. The result will be the adjusted swap limit for that specific container within the pod.
208+
209+
#### Example
210+
Suppose we have a Burstable QoS pod with two containers:
211+
212+
- Container A: Memory request 20 GB
213+
- Container B: Memory request 10 GB
214+
215+
Let's assume the total physical memory is 40 GB and the total swap memory available is also 40 GB. Also assume that the system reserved memory is configured at 2GB,
216+
217+
Step 1: Calculate `TotalPodsSwapAvailable`, which denotes total available swap memory: 40 GB - 2 GB = 38 GB
218+
219+
Step 2: Calculate the total memory requests of the pod: 20 GB + 10 GB = 30 GB
220+
221+
Step 2: Determine the requested memory proportion for each container:
222+
- Container A: (20 GB) / (30 GB) = 2/3
223+
- Container B: (10 GB) / (30 GB) = 1/3
224+
225+
Step 3: Calculate the total swap memory available: Since the total swap memory (38 GB) and physical memory (40 GB), the `SwapMemoryProportion` will be 38 GB / 40 GB = 0.95
226+
227+
Step 4: Calculate the swap limit for each container:
228+
- Container A: (2/3) * 20 GB * 0.95 ≈ 12.66 GB
229+
- Container B: (1/3) * 10 GB * 0.95 ≈ 3.16 GB
230+
231+
In this example, Container A would have a swap limit of 12.66 GB, and Container B would have a swap limit of 3.16 GB.
232+
233+
This approach allocates swap limits based on each container's memory request and adjusts the proportion based on the total swap memory available in the system. It ensures that each container gets a fair share of the swap space and helps maintain resource allocation efficiency.
234+
169235
### User Stories
170236

171237
#### Improved Node Stability
@@ -300,6 +366,12 @@ and/or workloads in a number of different scenarios.
300366
Since swap provisioning is out of scope of this proposal, this enhancement
301367
poses low risk to Kubernetes clusters that will not enable swap.
302368

369+
#### Security risk
370+
371+
Enabling swap on a system without encryption poses a security risk, as critical information, such as Kubernetes secrets, may be swapped out to the disk. If an unauthorized individual gains access to the disk, they could potentially obtain these secrets. To mitigate this risk, it is recommended to use encrypted swap. However, handling encrypted swap is not within the scope of kubelet; rather, it is a general OS configuration concern and should be addressed at that level. Nevertheless, it is essential to provide documentation that warns users of this potential issue, ensuring they are aware of the potential security implications and can take appropriate steps to safeguard their system.
372+
373+
Additionally, end user may decide to disable swap completely for a Pod or a container in beta 1 by making Pod guaranteed or set request == limit for a container. This way, there will be no swap enabled for the corresponding containers and there will be no information exposure risks.
374+
303375
## Design Details
304376

305377
We summarize the implementation plan as following:
@@ -487,14 +559,14 @@ Test grid tabs enabled:
487559

488560
No new e2e tests introduced.
489561

490-
For alpha2 [Current stage]:
562+
For alpha2:
491563

492564
- Add e2e tests that exercise all available swap configurations via the CRI.
493565
- Verify MemoryPressure behavior with swap enabled and document any changes
494566
for configuring eviction.
495567
- Verify new system-reserved settings for swap memory.
496568

497-
For beta [Future]:
569+
For beta 1:
498570

499571
- Add e2e tests that verify pod-level control of swap utilization.
500572
- Add e2e tests that verify swap performance with pods using a tmpfs.
@@ -536,20 +608,23 @@ Here are specific improvements to be made:
536608
swap limit for workloads.
537609
- Investigate eviction behavior with swap enabled.
538610

539-
540-
#### Beta
541-
542-
- Add support for controlling swap consumption at the pod level [via cgroups].
543-
- Handle usage of swap during container restart boundaries for writes to tmpfs
544-
(which may require pod cgroup change beyond what container runtime will do at
545-
container cgroup boundary).
611+
#### Beta 1
612+
- Enable Swap Support using Burstable QoS Pods only.
613+
- Enable Swap Support for Cgroup v2 Only.
546614
- Add swap memory to the Kubelet stats api.
547615
- Determine a set of metrics for node QoS in order to evaluate the performance
548616
of nodes with and without swap enabled.
549-
- Better understand relationship of swap with memory QoS in cgroup v2
550-
(particularly `memory.high` usage).
551-
- Collect feedback from test user cases.
617+
- Make sure node e2e jobs that use swap are healthy
552618
- Improve coverage for appropriate scenarios in testgrid.
619+
- Remove support for setting unlimited amount of swap (including [swapBehavior](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-MemorySwapConfiguration) flag of the Kubelet) as any workload with aggressive memory allocation can bring down a node with having no limits on swap usage.
620+
621+
#### Beta 2
622+
- Add support for controlling swap consumption at the container level [via cgroups] in Pod API in [container resources](https://github.com/kubernetes/kubernetes/blob/94a15929cf13354fdf3747cb266d511154f8c97b/staging/src/k8s.io/api/core/v1/types.go#L2443). More specifically add a new [ResourceName](https://github.com/kubernetes/kubernetes/blob/94a15929cf13354fdf3747cb266d511154f8c97b/staging/src/k8s.io/api/core/v1/types.go#L5522) `swap`. This will make sure we stay consistent with other resources like `cpu`, `memory` etc.
623+
- Publish a Kubernetes doc page encouring user to use encrypted swap if they wish to enable this feature.
624+
- Handle usage of swap during container restart boundaries for writes to tmpfs
625+
(which may require pod cgroup change beyond what container runtime will do at
626+
container cgroup boundary).
627+
553628

554629
[via cgroups]: #restrict-swap-usage-at-the-cgroup-level
555630

@@ -559,6 +634,8 @@ _(Tentative.)_
559634

560635
- Test a wide variety of scenarios that may be affected by swap support.
561636
- Remove feature flag.
637+
- Remove the Swap Support using Burstable QoS Pods only deprecated in Beta 2.
638+
562639

563640
### Upgrade / Downgrade Strategy
564641

keps/sig-node/2400-node-swap/kep.yaml

+4-2
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,8 @@ authors:
44
- "@ehashman"
55
- "@ike-ma"
66
- "@SergeyKanzhelev"
7+
- "@harche"
8+
- "@iholder101"
79
owning-sig: sig-node
810
participating-sigs:
911
- sig-node
@@ -18,12 +20,12 @@ approvers:
1820
- "@dchen1107"
1921

2022
# The target maturity stage in the current dev cycle for this KEP.
21-
stage: alpha
23+
stage: beta
2224

2325
# The most recent milestone for which work toward delivery of this KEP has been
2426
# done. This can be the current (upcoming) milestone, if it is being actively
2527
# worked on.
26-
latest-milestone: "v1.27"
28+
latest-milestone: "v1.28"
2729

2830
# The milestone at which this feature was, or is targeted to be, at each stage.
2931
milestone:

0 commit comments

Comments
 (0)