Service control plane vs. data-plane agents
A cloud service is not a billing line -- it is real software you run. It has a brain, the control plane, that decides what goes where and keeps track of everything. And it has hands: a small helper, the service agent, running on every server that actually does the work. The brain tells the hands what to do; the hands report back. Object storage, managed databases, Kubernetes -- and even plain virtual machines -- all work this way.
The control plane is not free magic floating above your datacenter. It runs on one of your servers, on your network, using real CPU and memory -- the same CPU and memory your paying customers want. Stand up a new service and you are agreeing to feed its brain and its hands out of the capacity you already own. That is the honest cost of offering a product: a slice of every machine that serves it, plus a home for the brain.
The hands have to be able to reach the brain. They talk over the same cables and switches as everything else. If a cable is cut or a switch dies and a server can no longer reach the brain of a service it was running, that server goes "headless" -- it keeps the lights on as best it can but stops getting instructions, and that service starts to degrade for the customers on it. Keeping the brain reachable is part of keeping the promise.
Detailed explanation
Each service is a control plane plus data-plane agents. The control plane is one logical instance (later HA) placed on a host on your fabric; it costs base + per-agent-host + per-managed-unit resources. Each host that serves the class runs one agent (shared by all of that class's tenants on the box), costing a flat per-host reserve. Both are folded into the host's vm_used_millivcpu / vm_used_mb before the bin-packer runs, so service overhead competes with customer VMs for the same finite vector -- leaving room for the storage agent is a real allocation decision, not a footnote.
Agents must reach their control plane over the existing host -> switch -> ... -> control-plane-host chain -- the same reachability model that gates VM placement. A partition marks the (host, class) pair headless: serving degrades rather than vanishing (serve-stale / read-only, tuned per class) and raises a loud incident, which drives the fix-the-network / add-redundancy loop. The control plane is therefore a SPOF and a partition risk you actively manage.