[{"data":1,"prerenderedAt":304},["ShallowReactive",2],{"blog-en-kubernetes-high-availability-broadcast-seamless-switching":3,"blog-related-en-kubernetes-high-availability-broadcast-seamless-switching":252,"blog-en-kubernetes-high-availability-broadcast-seamless-switching-alt":241},{"id":4,"title":5,"author":6,"body":7,"date":235,"description":236,"extension":237,"image":238,"locale":239,"meta":240,"navigation":241,"path":242,"seo":243,"stem":244,"tags":245,"__hash__":251},"blog\u002Fblog\u002Fen\u002Fkubernetes-high-availability-broadcast-seamless-switching.md","Broadcasters Send the Same Video Twice and Just Keep Whichever Arrives First — It Turns Out That's Exactly How Kubernetes Achieves High Availability","Kubo Team",{"type":8,"value":9,"toc":226},"minimark",[10,15,23,26,37,41,47,61,70,79,83,89,92,117,138,163,170,174,180,183,189,198,206,210,213],[11,12,14],"h2",{"id":13},"why-send-everything-twice-when-cutting-the-feed-would-break-things-anyway","Why Send Everything Twice When \"Cutting the Feed Would Break Things\" Anyway?",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"Camera footage splitting into red and blue paths, with only the first-arriving packet accepted at the receiver","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection01.webp",[16,24,25],{},"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.",[16,27,28,29,36],{},"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 ",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"nofollow","Kubo",".",[11,38,40],{"id":39},"you-just-didnt-know-its-name-this-is-already-an-industry-standard-seamless-protection-switching","You Just Didn't Know Its Name — This Is Already an Industry Standard: Seamless Protection Switching",[16,42,43],{},[19,44],{"alt":45,"src":46},"Timeline showing a seamless cutover from the red path to the blue path the moment a link failure occurs","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection02.webp",[16,48,49,50,54,55,60],{},"This \"send it twice, use whichever arrives first\" technique has an official name: ",[51,52,53],"strong",{},"SMPTE ST 2022-7",", commonly known as Seamless Protection Switching. According to ",[30,56,59],{"href":57,"rel":58},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSMPTE_2022",[34],"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.",[16,62,63,64,69],{},"The mechanics are laid out in detail in ",[30,65,68],{"href":66,"rel":67},"https:\u002F\u002Fwww.elecard.com\u002Fpage\u002Fst2022-7",[34],"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.",[16,71,72,73,78],{},"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 ",[30,74,77],{"href":75,"rel":76},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[34],"Kubo On-Premise",", is a decision we'll dig into in the next section.",[11,80,82],{"id":81},"kubernetes-is-making-the-same-bet-what-pod-distribution-and-az-redundancy-really-are","Kubernetes Is Making the Same Bet — What Pod Distribution and AZ Redundancy Really Are",[16,84,85],{},[19,86],{"alt":87,"src":88},"Architecture diagram showing pod replicas spread evenly across three availability zones, with service continuing when one zone fails","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection03.webp",[16,90,91],{},"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).",[16,93,94,97,98,103,104,108,109,112,113,116],{},[51,95,96],{},"Pod Topology Spread Constraints"," are at the core of this. According to ",[30,99,102],{"href":100,"rel":101},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fscheduling-eviction\u002Ftopology-spread-constraints\u002F",[34],"the official Kubernetes documentation",", setting ",[105,106,107],"code",{},"topologyKey"," to ",[105,110,111],{},"topology.kubernetes.io\u002Fzone"," along with ",[105,114,115],{},"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.",[16,118,119,120,123,124,129,130,133,134,137],{},"Another critical mechanism is ",[51,121,122],{},"PodDisruptionBudget (PDB)",". ",[30,125,128],{"href":126,"rel":127},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fconfigure-pdb\u002F",[34],"The official Kubernetes PDB configuration guide"," explains how setting ",[105,131,132],{},"minAvailable"," or ",[105,135,136],{},"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.",[16,139,140,141,146,147,150,151,156,157,162],{},"Beyond that, as ",[30,142,145],{"href":143,"rel":144},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fscheduling-eviction\u002Fassign-pod-node\u002F",[34],"the official documentation on pod affinity and anti-affinity"," shows, ",[105,148,149],{},"requiredDuringSchedulingIgnoredDuringExecution"," can be used to forcibly prevent pods from clustering into a single AZ. Cloud vendors have baked this same philosophy into their products: ",[30,152,155],{"href":153,"rel":154},"https:\u002F\u002Fdocs.aws.amazon.com\u002Feks\u002Flatest\u002Fuserguide\u002Fdisaster-recovery-resiliency.html",[34],"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, ",[30,158,161],{"href":159,"rel":160},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fregional-clusters",[34],"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.",[16,164,165,166,169],{},"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 ",[30,167,35],{"href":32,"rel":168},[34],", 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.",[11,171,173],{"id":172},"the-cost-of-keeping-a-spare-and-the-pitfalls-diy-operations-tend-to-miss","The Cost of \"Keeping a Spare,\" and the Pitfalls DIY Operations Tend to Miss",[16,175,176],{},[19,177],{"alt":178,"src":179},"Comparison diagram contrasting correctly distributed topology settings against zone-skewed misconfiguration during a zone failure","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection04.webp",[16,181,182],{},"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.",[16,184,185,186,188],{},"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 ",[105,187,136],{}," too conservatively, which can bring node upgrades to a halt entirely.",[16,190,191,192,197],{},"There's an even deeper issue worth considering: the large-scale cloud outage that occurred in October 2025. According to ",[30,193,196],{"href":194,"rel":195},"https:\u002F\u002Fwww.loadbalancer.org\u002Fblog\u002Fmulti-az-resilience\u002F",[34],"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.\"",[16,199,200,201,205],{},"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 ",[30,202,204],{"href":32,"rel":203},[34],"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.",[11,207,209],{"id":208},"summary","Summary",[16,211,212],{},"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.",[16,214,215,216,219,220,225],{},"Getting this design right takes specialized expertise and ongoing operational investment. Alternatively, a managed service like ",[30,217,35],{"href":32,"rel":218},[34],", 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 ",[30,221,224],{"href":222,"rel":223},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"reaching out"," to talk through what redundancy should look like for your own workloads.",{"title":227,"searchDepth":228,"depth":228,"links":229},"",2,[230,231,232,233,234],{"id":13,"depth":228,"text":14},{"id":39,"depth":228,"text":40},{"id":81,"depth":228,"text":82},{"id":172,"depth":228,"text":173},{"id":208,"depth":228,"text":209},"2026-08-05","World Cup broadcasts duplicate every camera feed across two independent paths and simply discard whichever packet arrives second. That seemingly wasteful design shares the same philosophy as Kubernetes high availability and multi-AZ architecture.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fkubernetes-high-availability-broadcast-seamless-switching",{"title":5,"description":236},"blog\u002Fen\u002Fkubernetes-high-availability-broadcast-seamless-switching",[246,247,248,249,250],"k3s","kubernetes","high-availability","multi-az","sre","Vlxk8quAupQNfSZlVXCYza1UmOXhYTJ5J7kfDb0lrUI",[253,261,270,279,288,296],{"path":254,"title":255,"description":256,"date":257,"tags":258},"\u002Fblog\u002Fen\u002Fbroadcast-redundancy-kubernetes-high-availability-design","Why Does the FIFA World Cup Broadcast Never Go Dark? What Broadcast Engineering's Dual-Path Redundancy Teaches Us About Real Kubernetes High Availability","Kubernetes high availability isn't achieved simply by adding more replicas. Using the broadcast industry's SMPTE ST 2022-7 dual-path transmission as a lens, this article unpacks what Topology Spread Constraints and multi-AZ design actually mean.","2026-07-20",[247,246,248,259,250,260],"topology-spread-constraints","managed-kubernetes",{"path":262,"title":263,"description":264,"date":265,"tags":266},"\u002Fblog\u002Fen\u002Fkubernetes-gpu-multitenancy-namespace-vs-dedicated-node","Stop Letting One Team Hog Your Expensive GPUs: Why There's No Single Right Answer for Kubernetes Accelerator Sharing","Kubernetes GPU multi-tenancy isn't a binary choice between namespace isolation and dedicated nodes. This article breaks down the cost-vs-isolation trade-off and how to design a hybrid approach.","2026-08-13",[246,247,267,268,269],"gpu-multitenancy","cost-optimization","namespace-isolation",{"path":271,"title":272,"description":273,"date":274,"tags":275},"\u002Fblog\u002Fen\u002Fkubernetes-gitops-branch-antipattern-fleet-scaling","Your dev\u002Fstaging\u002Fprod Branches Are a Time Bomb: Why Kubernetes GitOps Really Breaks","Splitting dev\u002Fstaging\u002Fproduction by Git branch is a GitOps anti-pattern that undermines Kubernetes' declarative foundations. Learn why drift happens, how to migrate to a directory-based, trunk-based setup, and how to design for fleet-scale growth.","2026-08-10",[246,247,276,277,278],"gitops","argocd","devops",{"path":280,"title":281,"description":282,"date":283,"tags":284},"\u002Fblog\u002Fen\u002Fkubernetes-certificate-management-cert-manager-process-debt","The Cert Renewal Took One Line of Code and Two Months of Meetings: Why Kubernetes Certificate Management Is a Process Problem, Not a Technical One","Kubernetes certificate management is technically a matter of days. What actually takes time is the organizational process of getting sign-off. Here's how cert-manager automates the technical side, and how to design away the operational debt that remains.","2026-08-09",[246,247,285,286,287],"cert-manager","tls","security",{"path":289,"title":290,"description":291,"date":292,"tags":293},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[246,247,294,295,287],"kata-containers","ai-agent",{"path":297,"title":298,"description":299,"date":300,"tags":301},"\u002Fblog\u002Fen\u002Fkubevirt-calico-live-migration-networking","Moving a VM Doesn't Have to Break the Connection: Inside KubeVirt and Calico's Live Migration Magic","Why doesn't live migrating a VM (KubeVirt) between Kubernetes nodes break the connection? We break down Calico's IP persistence and BGP route convergence, and what it means for teams moving off VMware.","2026-08-07",[246,247,302,303,260],"kubevirt","networking",1786701442990]