{
  "version": "2",
  "id": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282",
  "title": "Community Post Proposes 'Bridge' Add-on Versions to Close the EKS Node Upgrade Gap",
  "summary": "A dev.to author argues that pinning EKS add-ons to versions supported on both the current and target Kubernetes releases — applied before nodes roll — removes the window where new nodes run add-ons validated only against the old version.",
  "body": "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.\n\nThe 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.\n\nA 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.\n\nThe 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.\n\nOutput 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.\n\nAs 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.\n\nThe 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.\n\nThe 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.\n\nFor 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.\n\nThe 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.\n\nFor 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.\n\nThe 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.\n\nThe 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.\n\nThe 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.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-09-28T13:17:50.765Z",
  "dateModified": "2026-09-28T13:17:50.765Z",
  "eventDate": null,
  "sourcePublicationDate": "2026-09-28T11:01:27.000Z",
  "source": {
    "name": "dev.to",
    "url": "https://dev.to/ajinkya_a3/upgrade-eks-nodes-without-downtime-the-bridge-add-on-version-trick-2f84",
    "kind": "community"
  },
  "practicalImpact": "Editorial interpretation: teams maintaining EKS clusters can run the described version-intersection check before scheduling a node roll, and should audit their Terraform module for a shared control-plane/node-group version variable, since that dependency is what would otherwise force nodes to roll ahead of the bridge add-ons.",
  "limitations": "Single community post describing one author's cluster and one upgrade path; no measured downtime, error rates or controlled comparison. The cited add-on version numbers are environment- and time-specific and may not be current. The post does not establish that the same bridge versions exist for other add-ons, regions or version pairs, and the operational benefit is argued rather than demonstrated with data.",
  "keyPoints": [
    "The post defines a bridge add-on version as the newest version supported on both the current and target Kubernetes releases, applied before nodes roll so no node runs an add-on validated only for the other release.",
    "The author reports that for a 1.35 to 1.36 move, vpc-cni, coredns, aws-ebs-csi-driver and metrics-server had identical latest versions on both releases, while kube-proxy's bridge was a 1.35.x build because its version tracks the Kubernetes minor.",
    "A shared Terraform version variable between control plane and node group can cause a targeted add-on apply to roll nodes early via depends_on; the author recommends a separate node group version variable.",
    "The author states the technique reduces but does not eliminate upgrade risk, and that force_update_version = true can override a PodDisruptionBudget during the node roll."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-09-28T13:17:50.765Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://dev.to/ajinkya_a3/upgrade-eks-nodes-without-downtime-the-bridge-add-on-version-trick-2f84",
      "publisher": "dev.to",
      "title": "Upgrade EKS Nodes Without Downtime: The Bridge Add-on Version Trick",
      "publishedAt": 1790593287000,
      "fetchedAt": 1790601444676,
      "hash": "f4b69aa5a603fc1421d3edb9c2906f03b58efb0150655d07eea39c2f83c6a5e9",
      "kind": "community"
    }
  ],
  "claims": [
    {
      "claim": "The author describes an AWS-documented EKS upgrade order of control plane, then nodes, then add-ons, and argues it leaves a window where new nodes run old add-on versions.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282#claim-1"
    },
    {
      "claim": "The post identifies vpc-cni, CoreDNS and aws-ebs-csi-driver as the add-ons whose failure on a freshly rolled node would be most disruptive.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282#claim-2"
    },
    {
      "claim": "A bridge version is defined as the newest add-on version supported on both the current and target Kubernetes releases.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282#claim-3"
    },
    {
      "claim": "The author reports that for a 1.35 to 1.36 move, kube-proxy's bridge version was a 1.35.x build because its version tracks the Kubernetes minor.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282#claim-4"
    },
    {
      "claim": "The post warns that a shared version variable plus depends_on can make a targeted add-on apply roll the node group before bridge add-ons land.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282#claim-5"
    },
    {
      "claim": "The author states force_update_version = true can override a PodDisruptionBudget during the node roll, avoiding stuck upgrades but weakening the PDB guarantee.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282#claim-6"
    },
    {
      "claim": "The post states a bridge version reduces upgrade risk but does not remove it, and that replicas, PodDisruptionBudgets and deprecated-API checks are still needed.",
      "source": 1,
      "id": "claim-7",
      "url": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282#claim-7"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282",
    "markdown": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282.md",
    "json": "https://freelancenews.online/news/community-post-proposes-bridge-add-on-versions-to-close-the-eks-node-93cc3282.json"
  }
}