I think you generally have the right sentiment, but some of these solutions are born out of necessity. Using containers at scale is really hard when you're trying to solve for optimal resource usage and resilience. These abstractions may seem crazy but other solutions are probably much crazier.
The other part of this problem that isn't applicable generally to other things, is this is a fairly unique problem to cgroups. By design cgroups don't have a singular implementation or solution, so there are a lot of "competing" solutions. I think some amount of unix philosphy is at play here, to do one thing (or really, fewer) and that's why it seems insane how many systems you have to hook up together to make the thing work the way it should.
I'm fairly devops centric, but I'd still take this with a grain of salt b/c containers aren't my area of expertise.
The other part of this problem that isn't applicable generally to other things, is this is a fairly unique problem to cgroups. By design cgroups don't have a singular implementation or solution, so there are a lot of "competing" solutions. I think some amount of unix philosphy is at play here, to do one thing (or really, fewer) and that's why it seems insane how many systems you have to hook up together to make the thing work the way it should.
I'm fairly devops centric, but I'd still take this with a grain of salt b/c containers aren't my area of expertise.