本文档描述如何在 Kubernetes 集群中使用 sysctl。
在 Linux 系统中,sysctl 接口允许管理员在运行时修改内核参数。参数能够通过 /proc/sys/
虚拟进程文件系统获得。这些参数覆盖多个子系统,例如:
kernel.
)net.
)vm.
)dev.
)您可以通过运行以下命令来获得所有参数的列表
$ sudo sysctl -a
在目前的 Linux 内核中,有很多 sysctl 是 命名空间化的(namespaced)。这意味着每个 node 上的 pod 都能单独设置 sysctl。在 Kubernetes 的 pod 上下文中能够访问 sysctl 的前提就是命名空间化。
以下是已知 命名空间化 的 sysctl:
kernel.shm*
,kernel.msg*
,kernel.sem
,fs.mqueue.*
,net.*
.没有命名空间的 Sysctl 称为 node 级别,并且必须通过管理员手动设置,也就是要么设置 node 的底层 Linux 分布(例如通过 /etc/sysctls.conf
),要么使用具有特权容器的 DaemonSet。
注意:这里有一个很好的练习:集群中已经 tainted 具有特殊 sysctl 配置的 node,如何将需要这些特殊 sysctl 配置的 pod 调度到这些 node 上。建议使用 Kubernetes 的 taints 和 toleration 特性 来完成这个练习。
Sysctl 被分为 安全 和 不安全 组。为了能够更好的实现命名空间化,一个 安全的 sysctl 必须对同一个 node 上的 pod 进行合理的 隔离。这意味着为一个 pod 设置一个 安全的 sysctl 要做到
目前为止,大部分已 命名空间化 的 sysctl 不一定被认为是 安全的。
在 Kubernetes 1.4 版本中,安全 的 sysctl 集合支持以下 sysctl:
kernel.shm_rmid_forced
,net.ipv4.ip_local_port_range
,net.ipv4.tcp_syncookies
.当 kubelet 在未来的 Kubernetes 版本中支持更好的隔离机制后,这个列表将会得到扩展。
所有 安全的 sysctl 默认都是启用状态。
所有 不安全的 sysctl 默认都是禁用的,并且允许管理员在每个节点上进行手动修改。带有不安全的 sysctl 的 pod 能够被调度,但是无法启动。
警告:由于 不安全 的特性,使用 不安全的 sysctl 您需要自担风险,这可能会导致一些问题,如容器的错误行为、资源短缺或者 node 的完全损坏。
考虑到上面的警告,在非常特殊的场景下管理员可以允许某些 不安全的 sysctl,例如要求高性能或者实时性应用程序调优。能够通过 kubelet 的参数来启用 不安全的 sysctl,例如:
$ kubelet --experimental-allowed-unsafe-sysctls 'kernel.msg*,net.ipv4.route.min_pmtu' ...
只有 命名空间化 的 sysctl 能够通过这种方式启用。
sysctl 特性是 Kubernetes 1.4 版本中的一个 alpha API。因此,需要通过 pod 的注解来设置 sysctl。这将被应用于 pod 中的所有容器。
以下是通过注解来设置 安全的 和 不安全的 sysctl 的示例:
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
annotations:
security.alpha.kubernetes.io/sysctls: kernel.shm_rmid_forced=1
security.alpha.kubernetes.io/unsafe-sysctls: net.ipv4.route.min_pmtu=1000,kernel.msgmax=1 2 3
spec:
...
注意:在没有显式启用上述两个 不安全的 sysctl 的 node 上,使用上述 不安全的 sysctl 的 pod 将会启动失败。如果想要使用 node 级别 的 sysctl,建议您使用 taints 和 toleration 特性 或者 node 上的 taint 来把 pod 调度到正确的 node 上。
Create an Issue Edit this Page