目前，在 Linux 内核中，有许多的 sysctl 参数都是 有命名空间的 。 这就意味着可以为节点上的每个 Pod 分别去设置它们的 sysctl 参数。 在 Kubernetes 中，只有那些有命名空间的 sysctl 参数可以通过 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 参数称为 节点级别的 sysctl 参数。 如果需要对其进行设置，则必须在每个节点的操作系统上手动地去配置它们， 或者通过在 DaemonSet 中运行特权模式容器来配置。

可使用 Pod 的 securityContext 来配置有命名空间的 sysctl 参数， securityContext 应用于同一个 Pod 中的所有容器。

在运行一个容器时，有时候需要使用sysctl修改内核参数，比如net.、vm.、kernel等，sysctl需要容器拥有超级权限，容器启动时加上--privileged参数即可。那么，在k8s中是如何使用的呢？

使用sysctl

sysctl -a可以获取sysctl所有参数列表。

从v1.4开始，kubernetes将sysctl分为safe和unsafe，其对safe的sysctl定义如下：

• 不会影响该节点的其他pod
• 不会影响节点的正常运行
• 不会获取超出resource limits范围的CPU和内存资源

目前属于safe sysctl的有：

• kernel.shm_rmid_forced
• net.ipv4.ip_local_port_range
• net.ipv4.tcp_syncookies

其余的都是unsafe sysctl，当kubelet支持更好的隔离机制时，safe sysctl列表将在未来的Kubernetes版本中扩展。

如果日后kubelete支持更好的隔离机制,这份支持的安全列表将会扩展， 所有安全sysctls默认被开启。

所有的非安全sysctls默认被关闭,管理员必须手动在pod级别启动.包含非安全sysctls的pod仍然会被调度,但是将启动失败。请牢记以上警告,集群管理员可以在特殊情况下,比如为了高性能或者时实应用系统优化,可以启动相应的sysctls.sysctl可以通过kubelet在节点级别启动

即需要在想要开启sysctl的节点上手动启动.如果要在多个节点上启动则需要分别进入相应的节点进行设置.

·kubelet --allowed-unsafe-sysctls \ 'kernel.msg*,net.ipv4.route.min_pmtu' ...

对于minikube,则可以通过extra-config来配置

minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
仅有名称空间的sysctls可以通过这种方式开启

为pod设置Sysctls

一系列的sysctls被划分在不同的名称空间内.这意味着他们可以为节点上的pod单独地设置.仅有名称空间的sysctls可以通过pod的securityContext被设置

以下列出的是已知的有名称空间的.在日后的linux内核版本中可能会改变

• kernel.shm*,
• kernel.msg*,
• kernel.sem,
• fs.mqueue.*,
• net.*.

没有名称空间的systls被称作节点级别sysctls.如果你需要设置它们,你必须在每个节点的操作系统上手动设置,或者通过有特权的DaemonSet来设置

使用pod的安全上下文(securityContext)来设置有名称空间的sysctls.安全上下文对pod内的所有容器都产生效果.

以下示例通过pod的安全上下文来设置一个安全的sysctl kernel.shm_rmid_forced和两个非安全的sysctls net.ipv4.route.min_pmtu以及kernel.msgmax .在pod的spec里面,安全的sysctl和非安全的sysctl声明并没有区别

在生产环境中,仅仅在你明白了要设置的sysctl的功能时候才进行设置,以免造成系统不稳定.

POD Spec

apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
spec:
  securityContext:
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.ipv4.route.min_pmtu
      value: "552"
    - name: kernel.msgmax
      value: "65536"
  ...

由于非安全sysctls的非安全特征,设置非安全sysctls产生的后果将由你自行承担,可能产生的后果包含pod行为异常,资源紧张或者节点完全崩溃\

使用 pod 的 initContainers：

      initContainers:
      - command:
        - sysctl
        - -w
        - net.ipv4.tcp_keepalive_time=180
        image: busybox:1.27
        name: init-sysctl
        securityContext:
          privileged: true

或者

      initContainers:
      - command:
        - /bin/sh
        - -c
        - |
          ulimit -n 65536
          mount -o remount rw /sys
          echo never > /sys/kernel/mm/transparent_hugepage/enabled
          mount -o remount rw /proc/sys
          echo 2000 > /proc/sys/net/core/somaxconn
          echo 1 > /proc/sys/vm/overcommit_memory
        image: registry.cn-beijing.aliyuncs.com/acs/busybox:v1.29.2
        imagePullPolicy: IfNotPresent
        name: init-redis
        resources: {}
        securityContext:
          privileged: true
          procMount: Default

pod安全策略(PodSecurityPolicy)

你可以通过设置pod安全策略里的forbiddenSysctls(和)或者allowedUnsafeSysctls来进一步控制哪些sysctls可以被设置.一个以结尾的sysctl,比如kernel.匹配其下面所有的sysctl

• forbiddenSysctls和allowedUnsafeSysctls均是一系列的纯字符串sysctl名称或者sysctl模板(以结尾).匹配所有的sysctl
• forbiddenSysctls将排除一系列sysctl.你可以排除一系列安全和非安全的sysctls.如果想要禁止设置任何sysctls,可以使用*
• 如果你在allowedUnsafeSysctls字段设置了非安全sysctls,并且没有出现在forbiddenSysctls字段里,则使用了此pod安全策略的pods可以使用这个(些)(sysctls).如果想启用所有的非安全sysctls,可以设置*

警告,如果你通过pod安全策略的allowedUnsafeSysctls把非安全sysctl添加到白名单(即可以执行),但是如果节点级别没有通过sysctl设置--allowed-unsafe-sysctls,pod将启动失败.

以下示例允许以kernel.msg开头的sysctls被设置,但是禁止设置kernel.shm_rmid_forced

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: sysctl-psp
spec:
  allowedUnsafeSysctls:
  - kernel.msg*
  forbiddenSysctls:
  - kernel.shm_rmid_forced
 ...