Mesh control plane vs data plane availability

WHAT THIS TESTS Whether you grasp the brain-versus-muscle split in a mesh and reason correctly about graceful degradation during a control-plane outage.

A GOOD ANSWER COVERS The control plane is the management brain. It watches the cluster, computes the desired proxy configuration from your routing, security and policy resources, acts as or fronts the certificate authority, and pushes configuration and certificates to the proxies; Istio's istiod is the example. The data plane is the set of sidecar proxies, or per-node proxies in ambient mode, deployed beside workloads. They do the actual work: routing requests, load balancing, enforcing mTLS and policy, retrying, and emitting telemetry. They operate on the configuration the control plane last delivered, which they hold locally. Because of this separation, a short control-plane outage degrades gracefully. Existing traffic keeps flowing: proxies continue routing and enforcing policy using their cached config, and established mTLS connections keep working. What you lose for the duration is the propagation of changes: new or updated routing rules, authorization policies and service endpoints are not distributed, scaling events are not reflected in load-balancing targets, and certificate issuance and rotation pause, which only bites if certs would expire during the outage. Once the control plane recovers, it reconciles and pushes the current desired state to the proxies.

COMMON WRONG ANSWERS Saying all traffic stops when the control plane is down; the data plane runs independently on cached config. Believing config changes still apply during the outage. Forgetting the certificate-rotation risk if an outage is long. Conflating the control plane being down with the proxies being down.

LIKELY FOLLOW-UPS What eventually breaks if the control plane stays down for a long time, such as cert expiry or stale endpoints? How does the data plane learn endpoint changes normally? How do you make the control plane highly available? How does ambient or sidecar-less architecture change the picture?

ONE CONCRETE EXAMPLE istiod is restarted and briefly unavailable. The checkout and payments sidecars keep routing requests to each other over existing mTLS using their last config, so users notice nothing. Meanwhile a deploy that adds new payments pods does not get its endpoints propagated and a new AuthorizationPolicy does not take effect until istiod returns, at which point it pushes the updated state and everything converges.