在 Kubernetes 中，sysctl 被分为safe 和unsafe。
除了正确的命名空间之外，safe sysctl 必须在同一节点上的 pod 之间正确隔离。这意味着为一个 pod 设置 safe sysctl
- 不得对节点上的任何其他 pod 产生任何影响
- 不得损害节点的健康
- 不得在 Pod 的资源限制之外获得 CPU 或内存资源。
到目前为止，大多数 命名空间 sysctl 不一定被认为是安全。 safe 集中支持以下 sysctl：
-
kernel.shm_rmid_forced,
-
net.ipv4.ip_local_port_range,
-
net.ipv4.tcp_syncookies。
默认情况下，所有safe sysctls 都默认启用。
所有unsafe sysctls 都被禁用，需要集群管理员在每个节点上手动允许。
kubelet --allowed-unsafe-sysctls \
'kernel.msg*,net.core.somaxconn' ...
对于Minikube，这可以通过extra-config 标志来完成：
minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...
只有 namespaced sysctl 可以通过这种方式启用。
Enabling Unsafe Sysctlsk8s 文档中提到了这一点。
至于，Setting Sysctls for a Pod：
许多 sysctl 在当今的 Linux 内核中是命名空间的。这意味着可以为节点上的每个 pod 独立设置它们。只有命名空间的 sysctl 可以通过 Kubernetes 中的 pod securityContext 进行配置。
已知以下 sysctl 具有命名空间。此列表可能会在 Linux 内核的未来版本中发生变化。
-kernel.shm*,
-kernel.msg*,
-kernel.sem,
-fs.mqueue.*,
- net.* 下的参数可以在容器网络命名空间中设置。但是，也有例外（例如，net.netfilter.nf_conntrack_max 和 net.netfilter.nf_conntrack_expect_max 可以在容器网络命名空间中设置，但它们没有命名空间）。
没有命名空间的 Sysctl 称为 节点级 sysctls。如果您需要设置它们，您必须在每个节点的操作系统上手动配置它们，或者使用带有特权容器的 DaemonSet。
使用 pod securityContext 来配置命名空间的 sysctls。 securityContext 适用于同一个 pod 中的所有容器。
本示例使用 pod securityContext 设置一个安全 sysctl kernel.shm_rmid_forced 和两个不安全 sysctl net.core.somaxconn 和 kernel.msgmax。规范中对 safe 和 unsafe sysctl 没有区别。
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
spec:
securityContext:
sysctls:
- name: kernel.shm_rmid_forced
value: "0"
- name: net.core.somaxconn
value: "1024"
- name: kernel.msgmax
value: "65536"
...
您可能有兴趣阅读 StackOverflow Pros and cons of disabling TCP timestamps 和 What benefit is conferred by TCP timestamp? 上的以下问题。