Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Following the example in , I created a pod with 3 sysctls specified in the pod's security context. Setting the sysctl resulted in the pod failing to start. What you expected to happen: I expected the pod to start with no issues. If there is something missing in the docs, I appreciate updating There is also a discussion at that suggests that kernel does not namespace certain net.* sysctls. If that's the case, can we document which sysctls are supported? I assumed is a supported sysctl because it's in the official k8s docs. How to reproduce it (as minimally and precisely as possible): Following the pod creation, the pod doesn't start: Once I delete the following two lines from the pod securityContext, the pod starts fine: Anything else we need to know?: You can see that I've enabled the unsafe sysctls with kubelet: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: VMware Fusion OS (e.g: ):Kernel (e.g. ):Install tools: A single-node k8s cluster created with kubeadm Network plugin and version (if this is a network-related bug): Calico Others:
/sig node
Thank you for the incredibly detailed issue report :) I did some poking around, and if is accurate and still current, then I believe the issue is that is not namespaced (i.e. cannot be set on a per pod/container level). If I'm understanding correctly, we'd need to make changes to the Linux kernel in order for it to be namespaced. As a disclaimer, I'm not positive if this parameter became namespaced in new kernels... it could be interesting to investigate if this still happens on a machine with the latest kernel. W.r.t. fixes... I would agree with you that short term, we need to update this documentation so that it doesn't include . do you have any interest in doing so? If not, I'm happy to. Long term, I think it would be great to have better documentation re which sysctl parameters are namespaced (and thus supported) and which ones are not, and also a more descriptive error message if you try and utilize a non-supported parameter.
This historic issue also seems relevant: Perhaps we were premature to close it.
Matt, thanks for confirming the problem! I found the following comments very helpful: Looking at , there doesn't seem to be any difference between Linux 4.15 and 5.1. I'm happy to remove the references to in the docs, but before doing so, should we confirm sysctl worked at some point in the past? As you said, we should enhance the error message and the docs with the supported sysctls. I understand documenting the namespaced sysctls can be a moving target, but not everyone likes to check the Linux source code to see what's namespaced or not. :)
It's probably better to change the docs to set a namespaced sysctl like or . A good way to figure out what network sysctls are namespaced is to pass to kubelet and see all the sysctls listed under inside the pod.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Agree with all your statements here :) I'm also surprised that ever worked, but perhaps we could sync with the original author of the docs? +1 to in the meantime changing the docs to a namespaced sysctl.
I don't think ever worked as it's hardly to believe a sysctl got unnamespacified in the kernel (it's always the other way around). is a good example of namespaced networking sysctl. However, the above suggested is not in some cases - it's unnamespaced in kernel 4.14 and became namespaced in 4.15. In general, this is hard to document because there are hundreds of parameters and some of them is kernel version dependent and you always need to lookup the kernel code for answers. I think what we should do now is to with in the example in the doc. in the doc to something like . I think this should be very close ( is an exception) - I couldn't verify all of them as there are so many sysctls and they can also be by loading kernel modules.
SGTM, can you drive that?
Sure, created to change the doc.

Discussion:
exit 1 fi <del> APIROOT="${KUBE_ROOT}/pkg/api" TMP_APIROOT="${KUBE_ROOT}/_tmp/api" </del> <ins> DIFFROOT="${KUBE_ROOT}/pkg" TMP_DIFFROOT="${KUBE_ROOT}/_tmp/pkg" </ins> _tmp="${KUBE_ROOT}/_tmp" mkdir -p "${_tmp}" <del> cp -a "${APIROOT}" "${TMP_APIROOT}" </del> <ins> cp -a "${DIFFROOT}" "${TMP_DIFFROOT}" </ins> "${KUBE_ROOT}/hack/update-generated-swagger-docs.sh" <del> echo "diffing ${APIROOT} against freshly generated swagger type documentation" </del> <ins> echo "diffing ${DIFFROOT} against freshly generated swagger type documentation" </ins> ret=0 <del> diff -Naupr -I 'Auto generated by' "${APIROOT}" "${TMP_APIROOT}" || ret=$? cp -a "${TMP_APIROOT}" "${KUBE_ROOT}/pkg" </del> <ins> diff -Naupr -I 'Auto generated by' "${DIFFROOT}" "${TMP_DIFFROOT}" || ret=$? cp -a "${TMP_DIFFROOT}/" "${KUBE_ROOT}/" </ins> rm -rf "${_tmp}" if [[ $ret -eq 0 ]] then <del> echo "${APIROOT} up to date." </del> <ins> echo "${DIFFROOT} up to date." </ins> else <del> echo "${APIROOT} is out of date. Please run hack/update-generated-swagger-docs.sh" </del> <ins> echo "${DIFFROOT} is out of date. Please run hack/update-generated-swagger-docs.sh" </ins> exit 1 fi