Home > Software design >  The extention of updateable fields in Pod
The extention of updateable fields in Pod

Time:09-26

I wonder why only some fields of a pod can be modified。 The updateable fields are:

  1. spec.containers[*].image
  2. spec.initContainers[*].image
  3. spec.activeDeadlineSeconds 1

In my actual business, I have a need to change the schedulername of a pod. So i change the validating codes in the file of validation.go. And i created a second scheduler named kube-scheduler-test. That is pod whose schedulername is kube-scheduler-test When i created a new pod whose schedulername is kube-scheduler-test, then the kube-scheduler-test will update the schedulername of pod to default-scheduler. And then default-scheduler will schedule this pod to specified node.

enter image description here

enter image description here

Could you explain why only some fields of a pod can be modified and whether my method of changing the schedulername acceptable or not?

CodePudding user response:

Pods are designed to be disposable, think of them as immutable. When you want to change anything about a Pod, you create a new Pod, and throw away the old Pod.

There are many articles explaining immutable infrastructure.

CodePudding user response:

Could you explain why only some fields of a pod can be modified...

Example when your custom scheduler is half-way identify which node to deploy a pod and last minute request came to modify the resources limit. Or a pod started as normal user but let the pod switch user on the fly by changing securityContext fields? There are many scenarios, the bottom line is any field that can break the the cluster state consistency will be immutable.

and whether my method of changing the schedulername acceptable or not?

You are trying to extend kubernetes with your own scheduler and kubernetes does support that.

  • Related