【问题标题】:Altering host sysctl params from privileged container从特权容器更改主机 sysctl 参数
【发布时间】:2018-10-19 09:28:59
【问题描述】:

我们将 GKE 用于带有 ASP 的 NET Core 容器。每个 ASP 容器至少使用一个 inotify 实例(用于监视 Razer 模板),并且可以使用另一个来监视配置文件(如果未明确禁用)。

Linux 默认每个主机的 inotify 实例数限制为 128 (fs.inotify.max_user_instances=128)。一些实例被 kubernetes 本身使用(例如流利的守护进程)。因此,当在单个主机上部署大量 pod 时,主机会耗尽空闲的 inotify 实例,并且容器会陷入崩溃循环。

由于我们使用 GKE,我们无法直接管理工作节点和更改 sysctl 设置。

我的问题是:

  1. 我可以通过特权容器以某种方式更改主机 VM 的 sysctl 设置吗?
  2. 有没有办法设置 kubernetes 调度程序,以便在选择部署新 pod 的节点时考虑空闲 inotify 实例的数量(或至少部署的 pod 数量)?

【问题讨论】:

  • 第一个问题,请查看K8s doc 为 pod 设置 Sysctl。没有命名空间的 sysctl 称为节点级 sysctl。

标签: asp.net-core kubernetes .net-core google-kubernetes-engine inotify


【解决方案1】:

here 所述,“没有命名空间的 Sysctl 称为节点级 sysctls。如果需要设置它们,则必须在每个节点的操作系统上手动配置它们,或者使用带有特权容器的 DaemonSet”。

关于调度 pod,调度程序似乎没有办法在调度时考虑 inotify 或 pod 的数量。 scheduler 只知道可用资源(CPU 和内存)和 pod 规格,例如 pod 或节点关联性。

要获得所需的传播类型,需要对资源请求和 pod 亲和性/反亲和性进行大量规划和使用。您可以查看this

【讨论】:

    猜你喜欢
    • 2018-12-25
    • 2021-04-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-10-16
    • 1970-01-01
    • 2014-11-04
    相关资源
    最近更新 更多