Changing restricted fields of templates in kubernetes and openshift

Question

I'm using the openshift playground. I deploy a sample application, and export the yaml for the pod. While trying to edit some of the fields I ran across this message Forbidden: unsafe sysctl "kernel.msgmax" is not allowed

Searching around the link https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/#listing-all-sysctl-parameters describes how some parameters are labelled unsafe and cannot be changed but the safe ones can

But even the safe sysctls throw error,

spec: Forbidden: pod updates may not change fields other than spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds or spec.tolerations

1. Is it the playground environment that is limiting changes to kernel parameters? Would I need to have my own minikube installation to enable changing the unsafe sysctl parameters?
2. Apart from the minikube/kubelet alternatives given to edit/enable unsafe sysctls, is there a different way? What would be a good way to customize kernel parameters for a pod?

Answer 1

Please read thoroughly this documentation section. Everything is clearly explained there.

As to setting Unsafe Sysctls, you need to additionally enable them on node-level:

All safe sysctls are enabled by default.

All unsafe sysctls are disabled by default and must be allowed manually by the cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be scheduled, but will fail to launch.

With the warning above in mind, the cluster admin can allow certain unsafe sysctls for very special situations such as high-performance or real-time application tuning. Unsafe sysctls are enabled on a node-by-node basis with a flag of the kubelet; for example:

kubelet --allowed-unsafe-sysctls \
  'kernel.msg*,net.core.somaxconn' ...

For Minikube, this can be done via the extra-config flag:

minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...

Only namespaced sysctls can be enabled this way.

As to...

But even the safe sysctls throw error,

spec: Forbidden: pod updates may not change fields other than spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds or spec.tolerations

This is completely different error message and it has nothing to do with restrictions related to changing sysctls in your Pod definition. Note that you cannot change majority of your Pod specification via kubectl edit apart from just a few exceptions listed in the message above. Specifically you cannot change them without recreating your Pod so in this case instead of editing it you can simply run:

kubectl get pod pod-name -o yaml > my-pod.yaml

Then you can edit your required Pod spec fields, and redeploy it:

kubectl apply -f my-pod.yaml

Alternatively you may edit your Deployment as @Arghya Sadhu already suggested in his answer. Deployment controller will recreate those Pods for you with updated specification.

---

Is it the playground environment that is limiting changes to kernel parameters? Would I need to have my own minikube installation to enable changing the unsafe sysctl parameters?

Not really. You can enable them on every node which is part of your cluster by re-configuring your kubelets. As to changing kubelet configuration, it might be done differently depending on your kubernetes installation. In case it was created with kubeadm you just need to edit the following file:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

then run:

sudo systemctl daemon-reload

and restart your kubelet by running:

sudo systemctl restart kubelet.service

Apart from the minikube/kubelet alternatives given to edit/enable unsafe sysctls, is there a different way? What would be a good way to customize kernel parameters for a pod?

Answered above.

I hope it clarified your doubts about setting both safe and unsafe sysctls in a Kubernetes Cluster.

Answer 2

The safe sysctls throwing that error is expected behavior. What you need to do is delete the pod before applying the edited yaml to the cluster.You can also avoid this error if you use a deployment instead of a pod directly.