Concepts

Detailed explanations of Kubernetes system concepts and abstractions.

Edit This Page

在 Kubernetes 集群中使用 Sysctl

本文档描述如何在 Kubernetes 集群中使用 sysctl。

Sysctl 是什么?

在 Linux 系统中,sysctl 接口允许管理员在运行时修改内核参数。参数能够通过 /proc/sys/ 虚拟进程文件系统获得。这些参数覆盖多个子系统,例如:

您可以通过运行以下命令来获得所有参数的列表

$ sudo sysctl -a

命名空间化与 Node 级别的 Sysctl 对比

在目前的 Linux 内核中,有很多 sysctl 是 命名空间化的(namespaced)。这意味着每个 node 上的 pod 都能单独设置 sysctl。在 Kubernetes 的 pod 上下文中能够访问 sysctl 的前提就是命名空间化。

以下是已知 命名空间化 的 sysctl:

没有命名空间的 Sysctl 称为 node 级别,并且必须通过管理员手动设置,也就是要么设置 node 的底层 Linux 分布(例如通过 /etc/sysctls.conf),要么使用具有特权容器的 DaemonSet。

注意:这里有一个很好的练习:集群中已经 tainted 具有特殊 sysctl 配置的 node,如何将需要这些特殊 sysctl 配置的 pod 调度到这些 node 上。建议使用 Kubernetes 的 taints 和 toleration 特性 来完成这个练习。

安全与不安全的 Sysctl 对比

Sysctl 被分为 安全不安全 组。为了能够更好的实现命名空间化,一个 安全的 sysctl 必须对同一个 node 上的 pod 进行合理的 隔离。这意味着为一个 pod 设置一个 安全的 sysctl 要做到

目前为止,大部分已 命名空间化 的 sysctl 不一定被认为是 安全的

在 Kubernetes 1.4 版本中,安全 的 sysctl 集合支持以下 sysctl:

当 kubelet 在未来的 Kubernetes 版本中支持更好的隔离机制后,这个列表将会得到扩展。

所有 安全的 sysctl 默认都是启用状态。

所有 不安全的 sysctl 默认都是禁用的,并且允许管理员在每个节点上进行手动修改。带有不安全的 sysctl 的 pod 能够被调度,但是无法启动。

警告:由于 不安全 的特性,使用 不安全的 sysctl 您需要自担风险,这可能会导致一些问题,如容器的错误行为、资源短缺或者 node 的完全损坏。

启用不安全的 Sysctl

考虑到上面的警告,在非常特殊的场景下管理员可以允许某些 不安全的 sysctl,例如要求高性能或者实时性应用程序调优。能够通过 kubelet 的参数来启用 不安全的 sysctl,例如:

$ kubelet --experimental-allowed-unsafe-sysctls 'kernel.msg*,net.ipv4.route.min_pmtu' ...

只有 命名空间化 的 sysctl 能够通过这种方式启用。

为 Pod 设置 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 上。

Analytics

Create an Issue Edit this Page