By default, most applications run fine with the kernel parameters provided by the container runtime. When your application requires tuned kernel settings—such as packet forwarding or inotify limits—sandboxed pods let you apply those settings safely. Because each sandboxed pod runs on a dedicated kernel, changes to sysctls are fully isolated and do not affect other pods or the host. This topic describes two methods for setting kernel parameters: declaring sysctls as an annotation at pod creation time, and applying them at runtime with a privileged container.
Prerequisites
Before you begin, ensure that you have:
Why sandboxed pods handle sysctls differently
In a standard Kubernetes cluster, pods that use the runC runtime share the host kernel. This creates two constraints:
A privileged runC container has nearly full access to the host kernel. Modifying sysctls can affect other pods on the same node or make the node unavailable.
Unnamespaced (node-level) sysctls cannot be set differently for individual pods deployed on the same node.
Sandboxed pods bypass both constraints. Each sandboxed pod runs on its own dedicated kernel via the Sandbox-Container runtime (runtimeClassName: runv). Sysctl changes inside the sandbox affect only that pod's kernel—other pods and the host are not affected.
Choose a method
| Method | When to use |
|---|---|
Annotation (securecontainer.alibabacloud.com/sysctls) | Set sysctls declaratively at pod creation time. Both namespaced and unnamespaced sysctls are supported. |
Privileged container (securityContext.privileged: true) | Apply sysctls using sysctl -w inside the container. |
Set sysctls using an annotation
Add the securecontainer.alibabacloud.com/sysctls annotation to the pod template metadata. List multiple sysctls as a comma-separated string.
Annotation format:
| Field | Value |
|---|---|
| Key | securecontainer.alibabacloud.com/sysctls |
| Value format | "key1=value1,key2=value2" (comma-separated) |
| Supported sysctl types | Namespaced and unnamespaced |
| Scope | Applies only to the current pod's kernel |
The following example enables packet forwarding:
annotations:
securecontainer.alibabacloud.com/sysctls: "net.bridge.bridge-nf-call-ip6tables=1,net.bridge.bridge-nf-call-iptables=1,net.ipv4.ip_forward=1"The following is a complete Deployment example:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: busybox
name: busybox
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: busybox
template:
metadata:
labels:
app: busybox
annotations:
securecontainer.alibabacloud.com/sysctls: "net.bridge.bridge-nf-call-ip6tables=1,net.bridge.bridge-nf-call-iptables=1,net.ipv4.ip_forward=1"
spec:
containers:
- command:
- sleep
- infinity
image: 'busybox:latest'
imagePullPolicy: IfNotPresent
name: busybox
resources:
limits:
cpu: '1'
memory: 1Gi
requests:
cpu: 500m
memory: 512Mi
dnsPolicy: ClusterFirst
restartPolicy: Always
runtimeClassName: runvSet sysctls using a privileged container
A privileged container inside a sandboxed pod has nearly full access to the sandbox's dedicated kernel. Because the kernel is isolated, the elevated permissions are confined to that pod—other pods and the host are not affected.
Set securityContext.privileged: true in the container spec:
containers:
- name: busybox
securityContext:
privileged: trueWith privileged access, the container can call sysctl -w directly. The following is a complete Deployment example:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: busybox
name: busybox
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: busybox
template:
metadata:
labels:
app: busybox
spec:
containers:
- command:
- sh
- -c
- "sysctl -w fs.inotify.max_user_watches=524286 && tail -f /dev/null"
image: 'busybox:latest'
imagePullPolicy: IfNotPresent
name: busybox
securityContext:
privileged: true
resources:
limits:
cpu: '1'
memory: 1Gi
requests:
cpu: 500m
memory: 512Mi
dnsPolicy: ClusterFirst
restartPolicy: Always
runtimeClassName: runv