It’s currently not straightforward for users to know the effective resource requirements for a pod. The formula for this is Max ( Max(initContainers), Sum(Containers)) + pod overhead. This is derived from the fact that init containers run serially and to completion before non-init containers. The effective request for each resource is then the maximum of the largest request for a resource in any init container, and the sum of that resources across all non-init containers.

The introduction of in place pod updates of resource requirement in [KEP 1287](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1287-in-place-update-pod-resources) further complicates effective resource requirement calculation as `Pod.Spec.Containers[i].Resources` becomes a desired state field and may not represent the actual resources in use. The KEP notes that:

> Schedulers should use the larger of `Spec.Containers[i].Resources` and `Status.ContainerStatuses[i].ResourcesAllocated` when considering available space on a node.

We can introduce `ContainerUse` to represent this value:

ContainerUse(i) = Max(Spec.Containers[i].Resources, Status.ContainerStatuses[i].ResourcesAllocated)

In the absence of KEP 1287, or if the feature is disabled, `ContainerUse` is simply:

ContainerUse(i) = Spec.Containers[i].Resources

The sidecar KEP also changes that calculation to be more complicated as sidecar containers are init containers that do not terminate. Since init containers start in order, sidecar resource usage needs to be summed into those init containers that start after the sidecar. Defining `InitContainerUse` as:

InitContainerUse(i) = Sum(sidecar containers with index < i) + Max(Spec.InitContainers[i].Resources, Status.InitContainerStatuses[i].ResourcesAllocated)

allows representing the new formula for a pods resource usage

Max ( Max( each InitContainerUse ) , Sum(Sidecar Containers) + Sum(each ContainerUse) ) + pod overhead
Even now, users still sometimes find how a pods effective resource requirements are calculated confusing or are just unaware of the formula. The mitigating quality to this is that init container resource requests are usually lower than the sum of non-init container resource requests, and can be ignored by users in those cases. Software that requires accurate pod resource requirement information (e.g. kube-scheduler, kubelet, autoscalers) don't have that luxury. Its too much to ask of users to perform this even more complex calculation simply to know the amount of free capacity they need for a given resource to allow a pod to schedule.