machine-controller
machine-controller copied to clipboard
kubermatic
Support running shell script on Node boot
In some environments, you might need to run some shell commands on node boot.
For example, with Hetzner, you need to enable Receive Packet Steering on your Cloud servers if you are managing a lot of packets on some pods, otherwise you will have the IRQs for the network card on one core, saturating it and slowing everything down.
I could not find a way to have a MachineDeployment run a command after booting on a node.
I tried various forms around this, but the resulting OperatingSystemConfig never include those:
providerSpec:
value:
cloudProvider: hetzner
cloudProviderSpec:
image: ubuntu-22.04
operatingSystem: ubuntu
operatingSystemSpec:
distUpgradeOnBoot: true
provisioningConfig:
modules:
runcmd:
- "echo \"test\" > /tmp/test_bootstrap"
This object is accepted and written on the k8s server, but the runcmd script is never written anywhere I can see. I am not sure if this is a bug, or a missing feature.
I understood that an alternative would be to have a custom OperatingSystemProfile, but it means keeping it up-to-date with newer versions, which is burdensome.
Hey @renchap 👋🏻
This object is accepted and written on the k8s server, but the runcmd script is never written anywhere I can see. I am not sure if this is a bug, or a missing feature.
This missing piece of feedback is unfortunately caused by the technical implementation of CAPI v1alpha1, which machine-controller built upon. Fields are not strongly typed, so requests trying to edit arbitrary fields like providerSpec.operatingSystemSpec.provisioningConfig (which does not exist and isn't used anywhere) are not rejected, but do not serve any purpose. Since there is no feature intended here, I would not consider this a bug.
I understood that an alternative would be to have a custom
OperatingSystemProfile, but it means keeping it up-to-date with newer versions, which is burdensome.
At the moment OSPs are our only supported way of customising node bootstrapping. I understand that keeping things up to date requires more maintenance, but fundamentally we cannot know what kind of customisations are added and if they interfere with things our default bootstrapping does. Customisation requires more maintenance. At the same time, we appreciate the feedback that maintaining custom OSPs is "too much". We have been tracking a discussion to harmonise the process over at https://github.com/kubermatic/kubermatic/issues/12310.
Would a way to pre-process your custom OSP, e.g. via some templating engine (or similar so something like kustomize) help you?
Yes, this would make sense. Having an easy way to create our custom OSP, inserting snippets where we need them, would be useful here.
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kubermatic-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.