zoukankan      html  css  js  c++  java
  • kubernetes高级之集群中使用sysctls

    系列目录

    在linux系统里,sysctls 接口允许管理员在运行时修改内核参数.参数存在于/proc/sys/虚拟进程文件系统里.参数涉及到很多子模块,例如:

    • 内核(kernel)(常见前缀kernel.)

    • 网络(networking)(常见前缀net.)

    • 虚拟内存(virtual memory) (常见前缀 vm.)

    • MDADM(常见前缀dev.)

    启用非安全sysctls

    sysctls分为安全和非安全的.除了合理地划分名称空间外一个安全的sysctl必须在同一个节点上的pod间是隔离的.这就意味着为一个pod设置安全的sysctl需要考虑以下:

    • 必须不能影响同一节点上的其它pod

    • 必须不能危害节点的健康

    • 必须不能获取自身pod所限制以外的cpu或内存资源

    截至目前,大部分名称空间下的sysctls都不被认为是安全的.以下列出被kubernetes安全支持:

    • kernel.shm_rmid_forced

    • net.ipv4.ip_local_port_range

    • net.ipv4.tcp_syncookies

    如果日后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的功能时候才进行设置,以免造成系统不稳定.

    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安全策略(PodSecurityPolicy)

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

    forbiddenSysctlsallowedUnsafeSysctls均是一系列的纯字符串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
     ...
    
  • 相关阅读:
    背水一战 Windows 10 (61)
    背水一战 Windows 10 (60)
    背水一战 Windows 10 (59)
    背水一战 Windows 10 (58)
    背水一战 Windows 10 (57)
    背水一战 Windows 10 (56)
    背水一战 Windows 10 (55)
    背水一战 Windows 10 (54)
    背水一战 Windows 10 (53)
    背水一战 Windows 10 (52)
  • 原文地址:https://www.cnblogs.com/tylerzhou/p/11082819.html
Copyright © 2011-2022 走看看