On Thu, Feb 17, 2022 at 09:22:00PM +0800, dust.li wrote: > On Thu, Feb 17, 2022 at 10:37:28AM +0100, Stefan Raspl wrote: > >On 2/16/22 16:27, dust.li wrote: > >> On Wed, Feb 16, 2022 at 02:58:32PM +0100, Stefan Raspl wrote: > >> > On 2/16/22 04:49, Dust Li wrote: > >> > > > >Now we understand that cloud workloads are a bit different, and the desire to > >be able to modify the environment of a container while leaving the container > >image unmodified is understandable. But then again, enabling the base image > >would be the cloud way to address this. The question to us is: How do other > >parts of the kernel address this? > > I'm not familiar with K8S, but from one of my colleague who has worked > in that area tells me for resources like CPU/MEM and configurations > like sysctl, can be set using K8S configuration: > https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/ For K8s, this involves container engines like cri-o, containerd, podman, and others towards the runtimes like runc. To ensure they operate together, specifications by the Open Container Initiative (OCI) at https://opencontainers.org/release-notices/overview/ For container/pod deployments, there is especially the Container Runtime Interface (CRI) that defines the interface, e.g., of K8s to cri-o etc. CRI includes support for (namespaced) sysctl's: https://github.com/opencontainers/runtime-spec/releases/tag/v1.0.2 In essence, the CRI spec would allow users to specify/control a specific runtime for the container in a declarative way w/o modifying the (base) container images. Thanks and kind regards, Hendrik