What Is the Sidecar Pattern in Kubernetes?

In large-scale, microservice-oriented systems, ensuring that every service implements logging, tracing, and security controls in a consistent way is non-trivial. The sidecar pattern addresses this by attaching a dedicated helper container to each application instance, responsible for handling cross-cutting operational concerns. This design cleanly separates business logic from infrastructure logic, allowing application code to remain focused while operational behavior is standardized across the fleet.

The trade-off is operational overhead. At scale, thousands of sidecars introduce additional resource consumption and a parallel lifecycle that must be managed alongside your workloads. Without strong automation, observability, and platform-level controls, sidecars can quickly become a source of drift, inefficiency, and debugging complexity rather than a net gain in consistency.

Key Takeaways

• Isolate Responsibilities for a Modular Architecture: Use the sidecar pattern to offload cross-cutting concerns like logging or metrics collection into a separate container. This isolates application logic from operational tasks, creating a cleaner architecture where components can be updated independently.
• Standardize Cross-Cutting Concerns at Scale: Sidecars are fundamental to service meshes, providing a standardized way to manage network traffic, security, and observability across all microservices. By injecting a proxy sidecar, you can enforce consistent policies for routing, mTLS, and telemetry without modifying application code.
• Automate Sidecar Management to Mitigate Overhead: Sidecars add resource overhead and operational complexity, especially when managing versioning and deployments at scale. Address these challenges by using a GitOps-driven workflow with a platform like Plural to automate sidecar configuration and rollouts, ensuring consistency across your fleet.

What is the sidecar pattern?

The sidecar pattern is a cloud-native design pattern that separates core application logic from operational or infrastructural concerns. Instead of embedding functionality like logging, metrics collection, security enforcement, or proxying directly into application code, those responsibilities are delegated to a companion process—the sidecar—that runs alongside the main application.

The name is literal: just as a motorcycle sidecar is attached but independent, a sidecar container is attached to an application container but owns a distinct responsibility. This keeps application code smaller, easier to reason about, and easier to evolve independently of platform-level concerns.

At scale, this pattern is foundational for standardizing behavior across services. Platforms like Plural build on this idea by helping teams manage the operational complexity that emerges when sidecars become ubiquitous.

Core concepts

At its simplest, the sidecar pattern pairs two containers:

• Primary container – your application, focused purely on business logic
• Sidecar container – a helper responsible for cross-cutting concerns

In Kubernetes, both containers are deployed together inside a single Pod. This co-location is not incidental; it is what makes the pattern work.

Containers in the same Pod:

• Share the same lifecycle (scheduled, started, restarted, and terminated together)
• Share the same network namespace, enabling communication over localhost
• Can share volumes for file-based coordination (for example, log files or sockets)

Because of this tight coupling, the sidecar can transparently observe, augment, or intercept application behavior without invasive changes to the application itself.

What sidecars are typically used for

Sidecars are most effective when they handle concerns that are:

• Operational rather than business-specific
• Reusable across many services
• Likely to change independently of application code

Common examples include:

• Shipping logs to centralized logging backends
• Exporting metrics and traces
• Performing TLS termination or certificate rotation
• Acting as a local proxy for inbound and outbound network traffic
• Enforcing security or rate-limiting policies

By externalizing these responsibilities, application teams avoid duplicating logic across services and reduce the risk of inconsistent implementations.

Role in microservices architectures

In a microservices environment, the sidecar pattern is a key enabler of decoupling. Each service can remain narrowly focused on its domain logic, while sidecars provide a uniform operational layer across the entire system.

This separation has concrete benefits:

• Consistency: Every service gets the same logging, security, and networking behavior by default
• Velocity: Platform teams can update sidecar behavior without requiring application code changes
• Ownership boundaries: Application teams and platform teams can evolve independently

Service meshes are a canonical example of this pattern in practice. A sidecar proxy is injected alongside each workload and transparently manages service-to-service communication, policy enforcement, and telemetry collection.

As the number of services grows, however, so does the number of sidecars. Managing their resource usage, rollout strategy, and failure modes becomes a platform problem—one that tools like Plural are designed to address through automation, observability, and centralized control.

How does the sidecar pattern work in Kubernetes?

The sidecar pattern works in Kubernetes because of how Pods are designed. A Pod is the smallest deployable unit in Kubernetes and represents a single instance of a workload. While many Pods run only one container, Kubernetes explicitly supports running multiple, tightly coupled containers within the same Pod. This shared execution context is what enables the sidecar pattern.

All containers in a Pod are scheduled onto the same node and operate inside a shared environment. This allows helper processes to run alongside the main application without being compiled into the application binary or embedded into its codebase. Instead of baking operational logic into every service, Kubernetes lets you attach that logic at deployment time.

Pod-level execution model

A Pod provides a boundary similar to a lightweight virtual machine:

• Containers are co-scheduled on the same worker node
• They share the same network namespace (IP address and port space)
• They can mount the same volumes for shared storage

This shared context is what allows sidecars to transparently augment application behavior. The main application remains unaware of the sidecar’s internal implementation while still benefiting from its functionality.

Because the sidecar is just another container in the Pod, Kubernetes manages it using the same primitives—no special APIs or controllers are required.

Deployment within a Pod

You implement the sidecar pattern by defining multiple containers in a single Pod specification:

• Primary container: runs the application
• Sidecar container(s): provide supporting capabilities

From the scheduler’s perspective, the Pod is atomic. Either all containers are placed and run together, or none are. This guarantees co-location and eliminates entire classes of failure modes where auxiliary components drift away from the workloads they support.

Lifecycle management is also simplified:

• Pod creation starts all containers
• Pod termination stops all containers
• Restarts are handled at the Pod boundary, not per helper process

You do not need a separate deployment, health model, or rollout strategy for the sidecar.

Shared networking and storage

Containers in the same Pod communicate over localhost. This has several important implications:

• No service discovery or DNS lookups are required
• Latency is minimal
• Network policy complexity is avoided for intra-Pod traffic

This is why sidecar proxies can intercept all inbound and outbound traffic simply by binding to local ports.

Pods can also define shared volumes, such as emptyDir, that are mounted into multiple containers. This enables file-based coordination patterns, including:

• Log files written by the application and tailed by a logging sidecar
• Unix sockets shared between an app and a proxy
• Configuration files generated or transformed by a helper container

Container-to-container coordination

By default, containers in a Pod have isolated process namespaces. Kubernetes allows you to relax this boundary by enabling shareProcessNamespace.

When enabled:

• Containers can see each other’s processes
• Sidecars can send POSIX signals (e.g., SIGHUP) to the main process
• Coordinated reloads can happen without container restarts

This is useful for advanced patterns such as live configuration reloads, graceful shutdown coordination, or process supervision. It should be used deliberately, but it demonstrates how deeply integrated sidecars can be with their primary workloads.

What are the benefits of the sidecar pattern?

Adopting the sidecar pattern introduces additional moving parts into your Kubernetes deployments, but the trade-off is deliberate and often worthwhile. By colocating a secondary container with your application inside the same Pod, you can externalize operational responsibilities, enforce consistency across services, and improve system resilience. The net effect is a more modular, maintainable architecture that scales better as your environment grows.

Below are the key benefits that make the sidecar pattern a foundational cloud-native design choice.

Separate concerns and improve modularity

The most fundamental advantage of the sidecar pattern is separation of concerns. Business logic stays in the application container, while operational responsibilities are handled by a dedicated companion container.

This has several concrete effects:

• Application code remains smaller and easier to reason about
• Operational logic (logging, metrics, security) is reusable across services
• Each component can be developed, tested, and versioned independently

Developers no longer need to embed logging agents, metrics exporters, or security libraries into every service. Instead, those capabilities are delivered as infrastructure, not application code. This reduces duplication and keeps services aligned with the single-responsibility principle.

Isolate failures and manage resources independently

Because the application and sidecar run as separate containers, they execute in isolated processes. This isolation improves resilience:

• A sidecar crash does not necessarily crash the application
• Non-critical components fail independently of core business logic

Resource management also becomes more precise. Kubernetes allows you to set CPU and memory requests and limits per container, not just per Pod. This enables fine-grained tuning—for example, allocating more memory to a log-shipping sidecar while reserving CPU for the application itself.

This isolation aligns well with microservices design goals, where predictable resource usage and fault containment are essential.

Standardize operations across services

Sidecars provide a powerful mechanism for operational standardization. Instead of each team implementing logging, tracing, and security differently, those concerns are encoded once and deployed everywhere.

This is especially valuable at scale:

• Logging and observability behave consistently across services
• Security controls are enforced uniformly
• Updates to operational behavior do not require application changes

Service meshes are a canonical example of this benefit. A shared proxy sidecar can be rolled out or upgraded across hundreds of services without touching a single line of application code.

Platforms like Plural build on this model by helping teams manage sidecar-heavy environments through automation, visibility, and centralized lifecycle control, reducing the operational burden that otherwise comes with widespread sidecar adoption.

Explore common sidecar use cases

The sidecar pattern is most valuable when you need to extend application behavior without changing application code. By colocating auxiliary containers inside the same Pod, platform teams can standardize cross-cutting concerns—observability, security, networking, and configuration—while application teams remain focused on business logic.

This division of responsibility is especially important in large microservices environments. Sidecars let you define operational behavior once and apply it uniformly across services. The challenge shifts from implementation to lifecycle management at scale, where platforms like Plural help enforce consistency through GitOps-driven workflows and centralized visibility.

Manage traffic with a service mesh

Service meshes are the most visible and widely adopted example of the sidecar pattern. Tools like Istio and Linkerd inject a proxy sidecar into every application Pod.

That proxy transparently intercepts all inbound and outbound traffic, allowing a centralized control plane to enforce policies such as:

• Traffic routing for canary and blue/green deployments
• Retries, timeouts, and circuit breaking
• Mutual TLS (mTLS) between services
• Fine-grained telemetry collection

Because the proxy operates at the network layer, none of this logic lives in application code. Teams can evolve traffic and security policies independently of service releases, significantly reducing coordination overhead.

Centralize logging and monitoring

Sidecars are commonly used to standardize observability across services. Instead of embedding logging or metrics libraries into every application, a dedicated sidecar handles collection and forwarding.

Typical patterns include:

• A logging sidecar (for example, Fluentd or Vector) tails log files from a shared volume or reads from stdout and ships logs to a centralized backend.
• A metrics sidecar exposes or transforms metrics so they can be scraped by Prometheus or pushed to another monitoring system.

This approach decouples application code from observability tooling. Developers emit logs and metrics in a simple, consistent way, while platform teams control formats, destinations, and retention policies.

With Plural, these signals can be aggregated across clusters and environments, giving operators a unified view of system health without per-service customization.

Enhance security and manage configuration

Sidecars are well suited for isolating security-sensitive responsibilities from application code. Common examples include:

• TLS termination: A sidecar handles certificates and encryption, allowing the application to communicate over plain HTTP inside the Pod.
• Authentication and authorization: A proxy sidecar validates tokens or identities before requests reach the application.
• Secret handling: Sensitive data can be fetched, rotated, or injected by the sidecar rather than hard-coded into the app.

Another closely related use case is dynamic configuration management. A sidecar can watch for updates to a ConfigMap, secret, or external configuration store and trigger reloads without restarting the application container. This enables safer rollouts and faster configuration changes with minimal disruption.

Proxy requests and balance load

A sidecar can also function as a local reverse proxy for outbound and inbound requests. In this role, it may:

• Perform client-side load balancing
• Enforce rate limits
• Apply request-level access controls
• Normalize retries and backoff behavior

By pushing these concerns into a sidecar, applications avoid reimplementing complex networking logic. This leads to more consistent behavior across services and allows developers to ship features without deep expertise in resilience patterns or protocol-level details.

Across all these use cases, the value of the sidecar pattern comes from standardization without code coupling. At small scale, sidecars are easy to add. At large scale, managing their configuration, rollout, and resource impact becomes a platform concern—one that Plural addresses by making sidecar deployment and governance consistent across clusters.

What are the challenges of the sidecar pattern?

The sidecar pattern delivers clear architectural benefits, but those benefits come with non-trivial operational trade-offs. Introducing an additional container per Pod changes the resource profile, lifecycle semantics, and runtime behavior of your workloads. At small scale, these costs are easy to absorb. At platform scale, they become first-order concerns that must be designed for explicitly.

Understanding these challenges is essential for deciding where sidecars make sense—and where they may introduce unnecessary complexity.

Resource overhead and performance impact

Every sidecar consumes CPU, memory, and often network bandwidth. When sidecars are deployed ubiquitously, this overhead compounds quickly.

Key implications include:

• Higher baseline resource usage per Pod
• Increased infrastructure cost due to larger node requirements
• Greater risk of resource contention if limits are misconfigured

For example, a service mesh proxy may consume tens of millicores of CPU and tens to hundreds of megabytes of memory per Pod. Multiplied across thousands of replicas, this can materially affect cluster sizing and cost models.

Performance can also degrade if the sidecar competes with the application for resources. Without careful requests, limits, and monitoring, sidecars can introduce throttling or unpredictable latency under load. This makes cluster-wide visibility into per-container resource consumption a prerequisite for sustainable sidecar adoption.

Deployment complexity and lifecycle coupling

A Pod with multiple containers is operationally more complex than a single-container Pod. Kubernetes treats the Pod as an atomic unit, which tightly couples the lifecycle of the application and its sidecar.

This coupling introduces several challenges:

• A failing sidecar can block the entire Pod from becoming Ready
• Image pull failures or crashes in the sidecar prevent application startup
• Application and sidecar versions must be coordinated carefully

Updating a sidecar is not a local change—it often requires a fleet-wide rollout. Executing these updates safely and repeatably is difficult without strong automation. Declarative, GitOps-based workflows become essential to ensure that application and sidecar configurations evolve together from a single source of truth.

Platforms like Plural help manage this complexity by standardizing sidecar deployment and upgrades across clusters, reducing the operational risk of manual coordination.

Latency and container coordination

Sidecars frequently sit on the request path. Even though communication happens over localhost, every intercepted request introduces an additional hop. For latency-sensitive or high-throughput services, this “sidecar tax” can become measurable and, in some cases, unacceptable.

Beyond runtime latency, there are coordination challenges:

• Kubernetes does not guarantee container startup order within a Pod
• Applications may depend on the sidecar being fully initialized
• Shutdown sequencing can be difficult to orchestrate cleanly

Teams often compensate with startup probes, readiness gates, or custom init logic. While effective, these mechanisms increase configuration complexity and create new failure modes, including race conditions that are hard to debug when Pods fail intermittently.

In summary, the sidecar pattern trades application simplicity for platform complexity. When applied deliberately—and supported by strong automation, observability, and lifecycle management—it enables powerful architectural patterns. When applied indiscriminately, it can increase cost, latency, and operational risk. Evaluating these challenges upfront is critical to using sidecars effectively at scale.

Sidecar vs. other architectural patterns

The Sidecar pattern is one of several container co-location patterns used in Kubernetes to extend or adapt application behavior. While these patterns all rely on running multiple containers in the same Pod, they solve different architectural problems. Understanding the distinctions between Sidecar, Ambassador, and Adapter patterns helps platform and application teams choose the right abstraction for a given concern.

At a high level, the difference comes down to what responsibility is being offloaded and where that responsibility sits relative to the application.

Sidecar vs. Ambassador

The Sidecar and Ambassador patterns are often conflated because both introduce helper containers, but their scopes are different.

A Sidecar augments the application with internal or cross-cutting capabilities. Typical responsibilities include:

• Logging and metrics collection
• Security enforcement (mTLS, auth proxies)
• Configuration watching and reloads

The Sidecar enhances the application’s behavior without fundamentally changing how it communicates with the outside world.

An Ambassador, by contrast, is focused explicitly on external communication. It acts as a dedicated proxy for outbound (and sometimes inbound) traffic, abstracting away networking complexity. From the application’s perspective, it talks only to localhost. The Ambassador handles:

• Service discovery and routing
• Load balancing and retries
• Authentication to external services
• Protocol translation if required

The key distinction is scope:

• Sidecar → extends the application itself
• Ambassador → mediates the application’s interaction with external systems

In practice, an Ambassador can be implemented as a specialized Sidecar, but architecturally the intent is different.

Sidecar vs. Adapter

The Adapter pattern solves a different class of problem: standardization and compatibility.

An Adapter does not add new behavior to the application. Instead, it transforms the application’s existing output into a format expected by another system. You can think of it as a protocol or data-format translator.

Common examples include:

• Converting proprietary log formats into structured JSON
• Normalizing metrics into a common schema
• Translating legacy monitoring output into a modern telemetry format

Unlike a Sidecar, which introduces new capabilities, the Adapter’s job is to reshape data so heterogeneous systems can interoperate without modifying the application itself. This is particularly useful when dealing with legacy services or third-party software you cannot easily change.

Choosing the right pattern

The correct pattern depends entirely on the responsibility you are trying to externalize from your application:

• Use the Sidecar pattern when you need to add or enhance functionality with a tightly coupled helper process
  • Logging agents
  • Metrics collectors
  • Security or policy enforcement
  • Configuration reloaders
• Use the Ambassador pattern when you want to simplify and standardize external communication
  • Service discovery
  • Request routing
  • Circuit breaking and retries
  • Authentication to upstream services
• Use the Adapter pattern when you need to transform or normalize output for compatibility
  • Log format conversion
  • Metrics normalization
  • Data translation between systems

By choosing the pattern that matches your intent, you avoid overloading Sidecars with responsibilities they were not designed for and end up with a cleaner, more maintainable microservices architecture that clearly separates concerns.

How to implement sidecars in Kubernetes

Implementing the sidecar pattern in Kubernetes is primarily a Pod-level configuration exercise. A sidecar is not a special Kubernetes resource; it is simply an additional container defined alongside your main application container within the same Pod. This co-location gives the sidecar access to the same lifecycle, networking, and storage context as the application, enabling tight integration without requiring any changes to application code.

At small scale, this is straightforward. At fleet scale, consistency becomes the real challenge. Platforms like Plural address this by enforcing standardized Pod templates and GitOps-driven workflows, ensuring sidecars are deployed predictably and safely across environments.

Configure the Pod specification

In Kubernetes, a sidecar is defined by adding a second container to the Pod’s spec.containers list. Both the application container and the sidecar are first-class citizens within the Pod.

Key characteristics:

• Each container specifies its own image, resources, and probes
• All containers are scheduled together as a single unit
• Kubernetes does not distinguish between “main” and “sidecar” containers unless explicitly configured

For example, a web application container might be paired with a logging or proxy container. From Kubernetes’ perspective, this is just a multi-container Pod.

This model keeps sidecars declarative and composable, allowing teams to reason about them using the same primitives they already use for application workloads.

Set up shared volumes and networking

The sidecar pattern relies heavily on the shared execution context provided by the Pod.

Networking

• All containers in a Pod share the same network namespace
• Communication happens over localhost
• No Services, DNS lookups, or network policies are required for intra-Pod traffic

This is why proxy and mesh sidecars can intercept traffic simply by binding to local ports.

Storage

• Pods can define shared volumes (commonly emptyDir)
• Volumes can be mounted into multiple containers simultaneously

A common pattern is:

• The application writes logs or data to a shared volume
• The sidecar reads, processes, and forwards that data elsewhere

This file-based coordination avoids tight coupling between containers while still enabling efficient data exchange.

Best practices for sidecar deployment

Sidecars are powerful, but they must be deployed deliberately to avoid unnecessary overhead.

Recommended practices include:

• Set explicit CPU and memory requests and limits
  Prevent sidecars from starving the main application or introducing unpredictable contention.
• Keep sidecar images minimal
  Smaller images reduce startup time and resource footprint.
• Avoid defaulting to sidecars for every service
  If a workload does not need the functionality, do not add the operational cost.
• Use native sidecar container support when available
  Kubernetes introduced native sidecar semantics (beta in v1.28+) to address lifecycle issues. This ensures sidecars:
  • Start before application containers
  • Shut down after application containers
  • Avoid common startup and termination race conditions

At scale, managing these best practices manually is error-prone. Plural helps enforce them centrally, allowing platform teams to define sidecar standards once and apply them consistently across clusters using GitOps.

How to manage sidecars at scale

While the sidecar pattern offers significant benefits for modularity and separation of concerns, managing these containers across a large fleet of Kubernetes clusters introduces its own set of operational challenges. As you scale, you need a robust strategy for monitoring resource consumption, automating deployment, and handling updates without disrupting your applications. Without a clear plan, the overhead of managing thousands of sidecar instances can quickly negate their advantages. A successful at-scale implementation requires tooling and workflows that address performance, automation, and lifecycle management head-on.

Monitor and optimize performance

Every sidecar container consumes CPU and memory, and this resource overhead can become substantial across a large environment. To prevent sidecars from becoming performance bottlenecks or driving up costs, you must continuously monitor their resource utilization. Sidecars are often responsible for critical tasks like collecting logs, exporting metrics, and handling application traces, so their performance directly impacts your observability stack. Poorly configured sidecars can starve the main application of resources or fail themselves, creating blind spots in your monitoring.

Plural’s built-in multi-cluster dashboard provides the deep visibility needed to manage this. It allows you to inspect the resource consumption of individual containers within pods across your entire fleet. This centralized view helps you identify inefficient sidecars, set appropriate resource requests and limits, and ensure that both the sidecar and the primary application have the resources they need to function correctly.

Automate with a service mesh

Manually injecting and configuring sidecars for every microservice is not a viable strategy at scale. This is where a service mesh becomes essential. Service meshes like Istio and Linkerd automate the injection of proxy sidecars, which manage how microservices communicate, handle traffic routing, and improve observability. By offloading these networking concerns to an automated infrastructure layer, developers can focus on business logic without worrying about the underlying communication mechanics.

Using a service mesh ensures that every workload gets a consistently configured sidecar, enforcing security policies like mutual TLS (mTLS) and providing uniform telemetry collection. Plural simplifies this process by allowing you to deploy and manage complex applications like Istio from our open-source application catalog. With Plural, you can define a standardized service mesh configuration and use our GitOps engine to roll it out across all your clusters, ensuring consistency and reducing manual effort.

Plan your versioning and update strategy

A key benefit of the sidecar pattern is that the sidecar can be updated independently of the main application. However, this flexibility also introduces a lifecycle management challenge. You need a clear strategy for rolling out new sidecar versions, whether for a security patch or a feature update, without causing downtime for the primary application. Since the sidecar shares the pod's lifecycle, updating its container image often requires a pod restart, which must be carefully orchestrated.

A GitOps workflow is the most effective way to manage these updates. By defining your pod specifications, including the sidecar's image tag, in a Git repository, you create a single source of truth. Plural’s Continuous Deployment (CD) engine automatically detects commits to your repository and orchestrates the rollout across your fleet in a controlled and auditable manner. This approach allows you to safely manage sidecar versions, test changes systematically, and ensure that your entire environment remains consistent and up-to-date.

Related Articles

• Mastering the Kubernetes Sidecar Pattern

Frequently Asked Questions

Why not just build logging or monitoring directly into my application? While you can integrate these functions directly, the sidecar pattern decouples them from your application's core logic. This means your application team can focus on business features without needing to manage the lifecycle of observability tooling. It also enforces consistency; instead of every service implementing its own logging library, you can deploy a single, standardized logging sidecar across your entire fleet. This allows you to update your logging agent or metrics collector independently, without ever touching or redeploying the main application code.

When is the sidecar pattern a bad idea? The pattern isn't a universal solution. For very simple applications, the added resource consumption and deployment complexity of a second container may not be justified. It's also not ideal for extremely latency-sensitive services where the minimal network hop between the application and the sidecar proxy can impact performance. If the auxiliary function is tightly coupled with the application's core business logic and cannot be run as a separate process, a sidecar is not the right architectural choice.

Does using a sidecar add significant performance overhead? Yes, every sidecar introduces some overhead. This comes in two forms: resource consumption and latency. Each sidecar container requires its own CPU and memory, which can add up across thousands of pods. There is also a small amount of network latency, often called the "sidecar tax," for requests that are processed by a proxy. For most applications, this impact is negligible, but it's a critical factor for high-throughput systems. Monitoring this overhead is essential, and using a tool like Plural's multi-cluster dashboard gives you the visibility to manage resource allocation effectively.

How do I ensure my main application starts only after the sidecar is ready? Coordinating container startup order is a common challenge. The main application might depend on a sidecar, like a service mesh proxy, to be fully initialized before it can handle traffic. The modern solution is to use Kubernetes' native sidecar container feature, which is designed to manage this lifecycle dependency by ensuring sidecars start before the main containers and shut down after them. For older Kubernetes versions, a common approach is to use startup probes or custom scripts in the main container that wait for the sidecar to become available on a specific port before proceeding.

How can I update a sidecar across hundreds of services without causing issues? Updating a sidecar at scale requires automation and a declarative approach. Manually updating pod definitions across a large fleet is error-prone and unmanageable. The most effective strategy is to use a GitOps workflow. You define your pod specifications, including the sidecar's container image tag, in a Git repository. To perform an update, you simply commit a change to that image tag. A system like Plural CD will automatically detect the change and orchestrate a controlled, auditable rollout across all relevant clusters, ensuring the update is applied consistently everywhere.