In a large Istio mesh, each injected istio-proxy's memory footprint and configuration-push time grow as unrelated services are added elsewhere in the cluster. Why does that happen, and what does Istio's `Sidecar` resource do about it?

## Where the growth comes from Istio's default posture is maximal connectivity: without further information, any workload might talk to any service, so `istiod` computes and pushes configuration covering the whole mesh to every proxy. That is an excellent default for a demo and a poor one at scale, because it couples two things that should be independent — the size of a pod's proxy and the size of the cluster it happens to live in. The consequences show up in three places: - **Per-pod memory.** Each `istio-proxy` holds the full picture. Multiply a growing per-proxy footprint by every pod in the mesh and the mesh's overhead grows quadratically in feel, if not strictly in maths. - **Push volume and latency.** A change in any namespace can require recomputing and pushing configuration to proxies that have no interest in it. Under heavy deployment churn the control plane spends its time on pushes nobody needed, and the pushes that *do* matter queue behind them — the practical symptom being routing changes that take noticeably longer to take effect than they used to. - **Startup cost.** A new pod must receive that whole picture before it is useful, which lengthens exactly the startup window that the ordering problem already made delicate. ## What the `Sidecar` resource declares A `Sidecar` resource is a scope declaration, not a routing rule. It says which other parts of the mesh a set of workloads is allowed to *see*: ```yaml apiVersion: networking.istio.io/v1 kind: Sidecar metadata: name: default namespace: payments spec: egress: - hosts: - "./*" # everything in this namespace - "istio-system/*" # the control plane's own services - "platform/kafka.platform.svc.cluster.local" - "identity/*" ``` With no `workloadSelector`, a `Sidecar` named per convention applies to every workload in its namespace; with one, it applies only to matching workloads. `egress.hosts` entries are `namespace/host` pairs, where `.` means the current namespace and `*` matches all hosts. There is also an `outboundTrafficPolicy` field controlling whether calls to hosts outside the registry are allowed to pass through or are refused. The effect is that proxies in `payments` receive configuration for four namespaces instead of two hundred, and stop being pushed to when an unrelated team deploys. ## The operational trade This is a real trade, not free savings. Scoping turns an implicit "everything is reachable" into an explicit dependency declaration, and **an undeclared dependency stops working**. A team that adds a call to a new service without updating their `Sidecar` gets a failure that looks nothing like a missing route — the destination simply is not in that proxy's world. This is the single reason organisations delay adopting scoping: it converts a silent architectural fact into a maintained artefact. Managed well, that is the point. The `Sidecar` resource becomes a reviewed statement of what a service is permitted to call, which is valuable independently of memory. Managed badly — one enormous namespace-wide `Sidecar` copied everywhere with `*/*` in it — you get the maintenance burden and none of the savings. ## The complementary control `Sidecar` narrows what proxies see. `discoverySelectors` in the mesh configuration narrows what `istiod` watches in the first place, by selecting the namespaces the control plane tracks at all. In a cluster where large namespaces have nothing to do with the mesh — batch infrastructure, third-party operators — that removes work at the source rather than filtering it downstream. The two are usually deployed together: `discoverySelectors` for whole regions of the cluster that are simply not meshed, `Sidecar` for shaping visibility among the namespaces that are. ## How to know you need this Watch per-proxy memory as a distribution across the fleet, not as a single number, and watch how long a configuration change takes to be reflected at the proxies. When the first climbs with cluster growth rather than with your own service count, and the second degrades during other teams' deploy windows, the default scope has outgrown you. Below that — a mesh of a few dozen services — introducing `Sidecar` resources buys little and costs a maintenance obligation, which is why it is fairly graded as a scaling technique rather than a default practice.