背景
业务开发须要批改pod的内核参数，这些参数被认为是 unsafe 的参数，须要批改kubelet 的 --allowed-unsafe-sysctls 中才能够用，同时要把pod指定调度到这些kubelet被批改过的节点。
在遗记设置节点亲和性或者nodeSelector的状况下，间接批改deployment，会造成什么样的问题。上面通过试验复现一遍。
试验
自 k8s 1.12 起，sysctls 个性 beta 并默认开启，容许用户在 pod 的 securityContext 中设置内核参数
apiVersion: apps/v1kind: Deploymentmetadata: name: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: securityContext: sysctls: - name: net.core.somaxconn value: "1024" containers: - name: nginx image: nginx创立deplyemnt后，过五分钟后查看，集群创立了上千个pod
$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-7fbbcfcc7d-4gmrg 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-6dfpm 0/1 SysctlForbidden 0 17snginx-7fbbcfcc7d-6jkdn 0/1 SysctlForbidden 0 14snginx-7fbbcfcc7d-6mf6z 0/1 SysctlForbidden 0 16snginx-7fbbcfcc7d-6p2hs 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-cd759 0/1 SysctlForbidden 0 12snginx-7fbbcfcc7d-ckqbl 0/1 SysctlForbidden 0 16snginx-7fbbcfcc7d-gtvq4 0/1 SysctlForbidden 0 16snginx-7fbbcfcc7d-jbv2p 0/1 SysctlForbidden 0 18snginx-7fbbcfcc7d-jdh84 0/1 SysctlForbidden 0 18snginx-7fbbcfcc7d-kmd9p 0/1 SysctlForbidden 0 20snginx-7fbbcfcc7d-lcp6k 0/1 SysctlForbidden 0 15snginx-7fbbcfcc7d-lsdlx 0/1 SysctlForbidden 0 15snginx-7fbbcfcc7d-mbd74 0/1 SysctlForbidden 0 19snginx-7fbbcfcc7d-mbjnf 0/1 SysctlForbidden 0 18snginx-7fbbcfcc7d-mmbj7 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-n2ndn 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-rhjmp 0/1 SysctlForbidden 0 14snginx-7fbbcfcc7d-rznhl 0/1 SysctlForbidden 0 13snginx-7fbbcfcc7d-sfrl9 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-t9bkk 0/1 SysctlForbidden 0 19snginx-7fbbcfcc7d-vd6x8 0/1 SysctlForbidden 0 17snginx-7fbbcfcc7d-vt2jh 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-w4l7n 0/1 SysctlForbidden 0 20snginx-7fbbcfcc7d-w5sgq 0/1 SysctlForbidden 0 14snginx-7fbbcfcc7d-wlf2c 0/1 SysctlForbidden 0 13snginx-7fbbcfcc7d-xh22t 0/1 SysctlForbidden 0 21s解决办法
kubectl scale deployment --replicas=0 nginxkubectl delete pods -l app=nginx总结
为pod设置内核参数前先创立一个长期pod验证过再去批改deployment，防止创立大批量有效的pod。