Well, in practice you're likely to have hard dependencies between services in some respect, in that the service won't be able to do useful work without some other service. But I agree that in general it's a good idea to have a graceful degradation of functionality as other services become unavailable.

As we are talking about micro services, K8s has two patterns that are useful.

A global namespace root with sub namespaces will just desired config and current config will the complexity hidden in the controller.

The second is closer to your issue above, but it is just dependency inversion, how the kubelet has zero info on how to launch a container or make a network or provision storage, but hands that off to CRI, CNI or CSI

Those are hard dependencies that can follow a simple wants/provides model, and depending on context often is simpler when failures happen and allows for replacement.

E.G you probably wouldn’t notice if crun or runc are being used, nor would you notice that it is often systemd that is actually launching the container.

But finding those separation of concerns can be challenging. And K8s only moved to that model after suffering from the pain of having them in tree.

I think a DAG is a better aspirational default though.

Right, I don't mean that no service depends on each other, but that they can treat each other like a black box.