Community Post Proposes 'Bridge' Add-on Versions to Close the EKS Node Upgrade Gap

A community post published on dev.to describes a sequencing technique for upgrading Amazon EKS clusters that its author calls the "bridge add-on version" trick. The claim is narrow and practical: by moving managed add-ons to a version that is supported on both the current and the target Kubernetes release before the node group rolls, operators can avoid a window in which freshly rolled nodes run add-on builds that were only validated against the older Kubernetes version. The post is an author's account of one cluster's upgrade path, not an AWS announcement or an independently verified benchmark.

The author frames the technique as a response to the ordering AWS documents for EKS upgrades: control plane first, then nodes, then add-ons. That order works on paper, the post argues, but it leaves a gap. While nodes roll from 1.35 to 1.36, new nodes are running old add-on versions. The author singles out the add-ons that every pod depends on — vpc-cni for pod IP allocation on each node, CoreDNS for name resolution, and the aws-ebs-csi-driver for attaching volumes to stateful pods — as the ones where a misbehaving build would surface mid-rollout, with pods rescheduling around it.

A definitional remedy is what the post proposes: the newest add-on version present in the supported-version lists of both the current and the target Kubernetes release is what counts as a bridge version. Should each add-on be sitting on that bridge version prior to the nodes rolling, the author reasons, then the same add-on build runs on old nodes at 1.35 and new nodes at 1.36, and no node runs an add-on lacking validation for its Kubernetes version. On both releases the bridge version is valid, so per the post it may be applied at any moment before the node upgrade — whether at the outset on 1.35, or immediately after the control plane has moved to 1.36.

The author supplies a bash script that derives the bridge version per add-on by calling aws eks describe-addon-versions twice, once for each Kubernetes version, and taking the newest version common to both lists. The script covers vpc-cni, coredns, kube-proxy, aws-ebs-csi-driver and metrics-server, and warns when no overlapping version exists, in which case the post says an intermediate hop may be needed for that add-on.

Output from the author's own cluster, covering a 1.35 to 1.36 move, is what the post reports. On both releases the latest version was identical for vpc-cni, coredns, aws-ebs-csi-driver and metrics-server, so the latest build was simply the bridge — v1.23.1-eksbuild.1 for vpc-cni and v1.14.6-eksbuild.4 for coredns, for instance. The exception was kube-proxy: because its version tracks the Kubernetes minor, the 1.36 latest build was unavailable on 1.35, and a 1.35.x build, v1.35.3-eksbuild.29, served as the bridge. Until nodes are on 1.36, the author advises keeping kube-proxy there.

As much as the version arithmetic, the Terraform wiring described in the post matters. A single variable supplies the control plane resource's version, and changing only that line, the author notes, is what makes Terraform update the control plane in place. One minor version at a time is how EKS upgrades, and no rollback is offered, so this is treated in the post as the step to plan carefully. In the author's recommended setup, by contrast, a separate variable supplies the managed node group's version, and force_update_version = true plus max_unavailable = 1 are used so the group rolls one node at a time.

The author flags a specific Terraform trap. Because -target applies the named resource plus everything it depends on, and the add-on resource in the post declares a dependency on the node group, a shared version variable would cause a targeted add-on apply to drag the node group in and roll nodes before the bridge add-ons land — defeating the purpose. The stated fix is a separate variable for the node group so nodes can be held on 1.35 while the control plane and add-ons move first. The post notes nodes are allowed to run behind the control plane.

The step-by-step sequence the author lays out is: upgrade the control plane with a targeted apply; apply the bridge add-on versions with a targeted apply; roll the nodes with a targeted apply; optionally move add-ons to the versions EKS marks as default for the new release; and finish with a plain terraform apply to reconcile state. The post states that the control plane and add-on steps are interchangeable, with the only rule being that bridge add-ons land before the nodes.

For the optional fourth step, the author provides a query that filters add-on versions whose compatibility entry for the target release has defaultVersion set to true, and cautions that the default can differ from the newest build, so it should be compared against the earlier latest-version list before choosing. The post describes this step as optional because a bridge version is already supported on the new release, with kube-proxy the one add-on worth moving promptly so it matches the node version again.

The post is explicit about what the technique does not do. According to it, a bridge version lowers upgrade risk yet does not eliminate that risk, and several things remain necessary: sensible PodDisruptionBudgets, a check for deprecated APIs, and multiple replicas for critical workloads. It also warns that during the node roll, force_update_version = true can override a PodDisruptionBudget — stuck upgrades are avoided, but the PDB is then no longer an absolute guarantee. The author adds a further caution: compatibility listing alone should not be read as proof that an add-on's behaviour is unchanged, so each add-on's release notes deserve a read before the version is adopted.

For freelancers and developers who maintain EKS clusters for clients, the practical value is a repeatable pre-flight check rather than a new tool: the version-intersection script can be run against any two adjacent Kubernetes releases to decide whether an upgrade can proceed directly or needs an intermediate hop. The Terraform variable split is the part most likely to require refactoring an existing module, since it changes how node group versions are sourced.

The evidence here is a single community post describing one author's cluster and one upgrade path. The version numbers cited are specific to that cluster and region at the time of writing and should not be treated as current. The post does not report measured downtime, error rates or a controlled comparison, and it does not claim to have tested the approach beyond the author's own environment. Whether the same bridge versions exist for other add-ons, other regions or other Kubernetes version pairs is not established by the supplied material.

The underlying reasoning is nonetheless checkable against AWS's own tooling: describe-addon-versions returns per-Kubernetes-version compatibility lists, so the intersection the author computes is a real property of the published metadata rather than an assumption. What remains unverified is the operational claim that this ordering materially reduces incidents during a node roll — a plausible argument that the post supports with reasoning and a worked example, not with data.

The takeaway for teams planning an EKS minor-version upgrade is to treat add-on version selection as a step that can be scheduled independently of the node roll, and to verify the dependency graph of any targeted Terraform apply before running it. The author's own caveats — no rollback on control plane upgrades, PDB overrides, and the need to read release notes — are the constraints that should shape how much confidence to place in the technique.