In real world, we usually use one SidecarSet resource to control container injection for the batch of workloads. Sometimes, in order to control specific settings of container for specific workloads, we have to apply another one SidecarSet resource which is only different with the other SidecarSet in few settings. In the end, we have to manage so many SidecarSet resources for the specific settings for some workload even if there settings are same in most fields.
The common case is that we need to control sidecar cpu resource based on the application container. We have to manage different SidecarSet resources which define different cpu setting but the other container settings are same.
The key idea is that we can do some work on the container injection. From the inspire of istio, we can use pod annotations to override some container settings when kruise manager does the container injection.
ABNER-1
commented
1 month ago
In real world, we usually use one SidecarSet resource to control container injection for the batch of workloads. Sometimes, in order to control specific settings of container for specific workloads, we have to apply another one SidecarSet resource which is only different with the other SidecarSet in few settings. In the end, we have to manage so many SidecarSet resources for the specific settings for some workload even if there settings are same in most fields.
The common case is that we need to control sidecar cpu resource based on the application container. We have to manage different SidecarSet resources which define different cpu setting but the other container settings are same.
The key idea is that we can do some work on the container injection. From the inspire of istio, we can use pod annotations to override some container settings when kruise manager does the container injection.