<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>EKS on Daniel McDonough</title><link>https://dev.daniel-mcdonough.com/tags/eks/</link><description>Recent content in EKS on Daniel McDonough</description><generator>Hugo</generator><language>en</language><copyright>© 2026 Daniel McDonough</copyright><lastBuildDate>Mon, 08 Jul 2024 19:30:00 -0400</lastBuildDate><atom:link href="https://dev.daniel-mcdonough.com/tags/eks/index.xml" rel="self" type="application/rss+xml"/><item><title>Upgrading a Neglected EKS Cluster from 1.17 to 1.30</title><link>https://dev.daniel-mcdonough.com/posts/upgrading-a-neglected-eks-cluster-from-1.17-to-1.30/</link><pubDate>Mon, 08 Jul 2024 19:30:00 -0400</pubDate><guid>https://dev.daniel-mcdonough.com/posts/upgrading-a-neglected-eks-cluster-from-1.17-to-1.30/</guid><description>&lt;p>On July 3rd, 2024, I ended up dealing with one of the messier Kubernetes situations I’ve encountered: upgrading an EKS cluster that had effectively been left behind for years. The push to upgrade wasn’t optional as the cluster version was approaching the end of extended support from AWS, and staying on it meant continuing to pay the higher extended support costs.&lt;/p></description></item></channel></rss>