Why Send Everything Twice When "Cutting the Feed Would Break Things" Anyway?
At the international broadcast center behind one of the world's largest sporting events, every single camera feed is deliberately transmitted twice, over two completely independent paths carrying identical content. One path is labeled "red," the other "blue," and each runs through entirely separate switches and routers. The receiving end takes in both streams, and whenever a matching pair of packets (identified by sequence number and timestamp) arrives, only the one that gets there first is used as the actual video — the other is simply thrown away.
At first glance, this looks like a wasteful use of bandwidth. In reality, it's standard practice for systems where failure is not an option. And this exact way of thinking sits at the core of Kubernetes high availability design. This article uses the broadcast industry's redundancy technique as an entry point to unpack how Kubernetes builds systems that fail "without anyone noticing" — and what actually changes when you build that resilience yourself versus handing it off to a managed platform like Kubo.
You Just Didn't Know Its Name — This Is Already an Industry Standard: Seamless Protection Switching
This "send it twice, use whichever arrives first" technique has an official name: SMPTE ST 2022-7, commonly known as Seamless Protection Switching. According to the Wikipedia overview of the SMPTE 2022 family of standards, ST 2022-7 defines seamless protection switching at the RTP datagram level, created to guarantee reliability as broadcast infrastructure moved to IP.
The mechanics are laid out in detail in this technical explainer on ST 2022-7. On the sending side, a splitter duplicates RTP streams carrying identical payloads and pushes them down two physically independent network paths. On the receiving side, a switcher takes in packets from both paths into separate buffers, synchronizes them using the RTP header's sequence number and timestamp, and automatically fails over to the other buffer the instant one path degrades or drops. The buffer is sized to absorb the difference in latency between the fastest and slowest path.
What matters here is that this design philosophy doesn't aim to build a system that never fails. It starts from the premise that failure is inevitable, and sets the goal of completing the switchover before the viewer ever notices. This same redundancy philosophy shows up far beyond broadcasting — in financial trading systems, air traffic control, and other mission-critical infrastructure — and it maps directly onto Kubernetes high availability design. Whether you implement this philosophy from scratch on your own cluster, or adopt a platform that ships with it built in, like Kubo On-Premise, is a decision we'll dig into in the next section.
Kubernetes Is Making the Same Bet — What Pod Distribution and AZ Redundancy Really Are
Kubernetes high availability design is built on exactly the same bet: prepare duplicates, and discard whichever one breaks. Just as the broadcast center splits video across red and blue paths, Kubernetes spreads workloads across multiple availability zones (AZs).
Pod Topology Spread Constraints are at the core of this. According to the official Kubernetes documentation, setting topologyKey to topology.kubernetes.io/zone along with maxSkew: 1 lets the scheduler automatically distribute pods while minimizing the imbalance in pod count between zones. This is fundamentally the same idea as sending identical video down multiple paths — if one zone goes down entirely, the replicas in the remaining zones keep the service running.
Another critical mechanism is PodDisruptionBudget (PDB). The official Kubernetes PDB configuration guide explains how setting minAvailable or maxUnavailable ensures a minimum number of replicas stay available even during intentional disruptions, like node maintenance or upgrades. Much like the receiving buffer at a broadcast center keeps video from ever cutting out during a path switch, a PDB acts as insurance that guarantees pod availability throughout cluster operations.
Beyond that, as the official documentation on pod affinity and anti-affinity shows, requiredDuringSchedulingIgnoredDuringExecution can be used to forcibly prevent pods from clustering into a single AZ. Cloud vendors have baked this same philosophy into their products: Amazon EKS's documentation on availability states that the EKS control plane runs at least two API server instances and three etcd instances spread across multiple AZs. Similarly, Google Kubernetes Engine's documentation on regional clusters describes replicating both the control plane and worker nodes across multiple zones as a standard feature that provides resilience against a single-zone failure.
Correctly assembling all of these pieces yourself demands no small amount of specialized knowledge — understanding AZ topology, designing zone spread, calculating PDB thresholds. This is precisely why many infrastructure engineers would rather hand off availability design to a managed Kubernetes service. With a K3s-based platform like Kubo, the Rancher management layer gives you visibility into multi-cluster, multi-AZ configuration status, so you can run a full-fledged Kubernetes cluster with this kind of redundancy design built in from day one.
The Cost of "Keeping a Spare," and the Pitfalls DIY Operations Tend to Miss
Redundancy is not an investment in improving performance — it's an investment in buying insurance. Just as a broadcast center continuously allocates bandwidth to a backup path that goes unused in normal operation, a Kubernetes multi-AZ setup continuously consumes cross-AZ data transfer costs and compute resources for always-on standby replicas. Under normal operation, this looks like waste. The moment a failure hits, its value becomes obvious all at once.
DIY redundancy builds also come with pitfalls that are easy to overlook. A classic failure mode is bumping up replica count without configuring topology spread at all. In that case, multiple pods can end up clustered in the same AZ purely by chance, leading to the paradoxical situation where "we have three replicas, but a single AZ failure took all of them down." Another commonly reported pitfall in practice is setting a PDB's maxUnavailable too conservatively, which can bring node upgrades to a halt entirely.
There's an even deeper issue worth considering: the large-scale cloud outage that occurred in October 2025. According to an article analyzing the limits of multi-AZ resilience, that outage originated from a failure in a core database product used to monitor network load, and cascaded outward from the US East region to affect services worldwide. The article points out that "even if you distribute resources across multiple AZs, you remain exposed to region-level failures as long as you depend on region-centralized services like IAM and account management." In other words, a multi-AZ design is resilient to infrastructure failures within a single AZ, but it cannot save you from a failure in the regional control systems that underpin the whole thing. This is the same structural limitation as the broadcast center's dual paths: doubling up the "path" is not the same as doubling up "the broadcast center itself."
That's exactly why availability design can never be a "set it and forget it" exercise — AZ configuration, PDB settings, and failure scenarios all need continuous review. Whether your team absorbs that ongoing burden of design, monitoring, and tuning in-house, or hands it off to a managed service like Kubo Cloud that gives you constant visibility into your configuration through a dashboard, is a call that should depend on your team's size and available resources.
Summary
When a broadcast center sends the same video twice and quietly discards whichever copy arrives second, it isn't wasting resources — it's a rational form of insurance designed around the assumption that things will break. Kubernetes' topology spread constraints, PodDisruptionBudgets, and multi-AZ scheduling all rest on that same philosophy: prepare duplicates, and cut loose whichever one fails.
Getting this design right takes specialized expertise and ongoing operational investment. Alternatively, a managed service like Kubo, built on K3s with full Kubernetes-grade redundancy features, lets you hand off availability design itself from the very start. Whether you build it from scratch or adopt a proven design is your call — start by reaching out to talk through what redundancy should look like for your own workloads.