Skip to main content
Contact our team to know more about our services
select webform
By submitting, you acknowledge that you've read and agree to our privacy policies, and Opcito may use the information provided for business purposes.
Become a part of our team
select webform
One file only.
1.5 GB limit.
Allowed types: gif, jpg, jpeg, png, bmp, eps, tif, pict, psd, txt, rtf, html, odf, pdf, doc, docx, ppt, pptx, xls, xlsx, xml, avi, mov, mp3, mp4, ogg, wav, bz2, dmg, gz, jar, rar, sit, svg, tar, zip.
By submitting, you acknowledge that you've read and agree to our privacy policies, and Opcito may use the information provided for business purposes.
Guide to upgrade an EKS cluster from 1.29 to 1.30 using Terraform
20 Sep 2024

It's time to upgrade your EKS clusters! Following up on my previous blog about upgrading an EKS cluster from 1.28 to 1.29, this highly anticipated Kubernetes 1.30 release, nicknamed Uwernetes, brings new features and improvements. If you're worried about navigating the upgrade process alone, don't worry. This blog will guide you through a smooth and efficient upgrade using Terraform, ensuring your workloads transition seamlessly into the Uwernetes era.

Kubernetes_1.30_Uwernetes

EKS version 1.30 changes:

  • Managed node group automatically used default Amazon Linux 2023 OS. 
  • EKS added a new label to worker nodes as topology.k8s.aws/zone-id to specify zone id for resource.
  • EKS will not include default annotation on the gp2 StorageClass.

What are the changes in Kubernetes 1.30 release?

You can find a complete list of changes and updates in Kubernetes version 1.30 here. These are the updates that caught my eye.

  • Robust VolumeManager reconstruction after kubelet restart (SIG Storage): This update to the volume manager allows the kubelet to gather more detailed information about how volumes are currently mounted during startup. This improved data helps ensure volumes are cleaned up reliably after a Kubelet restart or machine reboot. There are no changes for users or cluster administrators. They used a feature process and feature gate NewVolumeManagerReconstruction to revert to the old behavior, if necessary, temporarily. Now that the feature is stable, the feature gate is locked and cannot be disabled.
  • Prevent unauthorized volume mode conversion during volume restore (SIG Storage): The control plane strictly prevents unauthorized changes to volume modes when restoring snapshots to PersistentVolume. To allow such changes, cluster administrators must provide specific permissions to the relevant identities (like ServiceAccounts used for storage integration).
  • Pod Scheduling Readiness (SIG Scheduling): Kubernetes avoids scheduling Pods until the required resources are provisioned in the cluster. This control enables the implementation of custom rules, such as quotas and security measures, to regulate Pod scheduling.
  • Min domains in PodTopologySpread (SIG Scheduling): The minDomains parameter for PodTopologySpread constraints is now stable. This allows you to specify the minimum number of domains for Pod placement. This feature is designed to work with Cluster Autoscaler.

This release includes a total of 17 enhancements promoted to Stable:

  • Container Resource based Pod Autoscaling
  • Remove transient node predicates from KCCM's service controller
  • Go workspaces for k/k
  • Reduction of Secret-based Service Account Tokens
  • CEL for Admission Control
  • CEL-based admission webhook match conditions
  • Pod Scheduling Readiness
  • Min domains in PodTopologySpread
  • Prevent unauthorised volume mode conversion during volume restore
  • API Server Tracing
  • Cloud Dual-Stack --node-ip Handling
  • AppArmor support
  • Robust VolumeManager reconstruction after kubelet restart
  • kubectl delete: Add interactive(-i) flag
  • Metric cardinality enforcement
  • Field status.hostIPs added for Pod
  • Aggregated Discovery

No deprecated API versions in Kubernetes 1.30 release

Steps to upgrade EKS with Terraform

First, deploy the EKS cluster in AWS Cloud with 1.29 version by Terraform. Here's the screenshot of the cluster.

deploy EKS cluster in AWS Cloud with 1.29 version by Terraform

I deployed the nginx application running in the cluster and verified the nginx app by port forwarding to the 9999 port.

kubectl get po -n nginx
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-848dd6cfb5-nnxh4   1/1     Running   0          13s

kubectl port-forward -n nginx nginx-deployment-848dd6cfb5-nnxh4 9999:80
Forwarding from 127.0.0.1:9999 -> 80
Forwarding from [::1]:9999 -> 80
Handling connection for 9999
Handling connection for 9999

Access the nginx application here: http://localhost:9999

nginx

What are the Prerequisites to upgrade from EKS cluster 1.29 – 1.30

Before upgrading the EKS cluster to v1.30, we need to update the IAM policy of the EKS cluster IAM role with action ec2:DescribeAvailabilityZones

Upgrade EKS cluster

Updates Terraform script to upgrade EKS cluster to 1.30 version.

terraform {
  backend "s3" {
         encrypt        = true
         bucket         = "terraform-state-bucket"
         key            = "infra"
         region         = "ap-south-1"
  }
}

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region  = "ap-south-1"
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "eks-cluster"
  cluster_version = "1.30"
  cluster_endpoint_public_access  = true

  cluster_addons = {
  coredns                = {
    resolve_conflicts = "OVERWRITE"
    version           = "v1.11.1-eksbuild.9"
  }
  kube-proxy             = {
    resolve_conflicts = "OVERWRITE"
    version           = "1.30.0-eksbuild.3"
  }
  vpc-cni                = {
    resolve_conflicts = "OVERWRITE"
    version           = "v1.18.1-eksbuild.3"
  }
  aws-ebs-csi-driver                = {
    resolve_conflicts = "OVERWRITE"
    version           = "v1.31.1-eksbuild.1"
  }

}

  vpc_id                   = "*******"
  subnet_ids               = ["*******", " *******", "******* "]
  control_plane_subnet_ids = ["*******", "*******", "*******"]

  eks_managed_node_groups = {
    group = {
      ami_type       = "AL2023_x86_64_STANDARD"
      instance_types = ["t3a.medium"]

      min_size     = 1
      max_size     = 2
      desired_size = 1
    }
  }

  enable_cluster_creator_admin_permissions = true

  tags = {
    Environment = "dev"
    Terraform   = "true"
  }
}

To see the changes after modifying the Terraform script, run Terraform plan.

terraform plan

terraform plan

To apply the changes to upgrade the EKS cluster to 1.30 version, run Terraform apply 

terraform apply

Upgrading the cluster will take 8-10 minutes and 25-30 minutes to do the node group and AWS EKS add-ons. Now, let's verify the nginx application, which was already deployed. I verified the nginx application by port forwarding to 9999 port.

kubectl get po -n nginx                                                
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-848dd6cfb5-t8pjf   1/1     Running   0          7m45s

kubectl port-forward -n nginx nginx-deployment-848dd6cfb5-t8pjf 9999:80
Forwarding from 127.0.0.1:9999 -> 80
Forwarding from [::1]:9999 -> 80

From above, the nginx app is redeployed after the node group gets upgraded to 1.30 version. Now let's access the nginx application by http://localhost:9999

welcome to nginx

Verify all other components after upgrading the EKS cluster to check whether they could include:

  1. Load Balancer Controller
  2. calico-node
  3. Cluster Autoscaler or Karpenter
  4. External Secrets Operator
  5. Kube State Metrics
  6. Metrics Server
  7. csi-secrets-store
  8. Keda (event driven autoscaler)

Conclusion

It's now much quicker to upgrade an EKS cluster, taking only 8 minutes to upgrade the control plane. I utilized Terraform to seamlessly upgrade both the EKS cluster and node group to version 1.30. This made the process significantly easier. Fortunately, there were no major issues during the upgrade, and all workloads ran without any problems.
My next blog will talk about migrating from EKS from 1.30 to 1.31. Stay tuned!

Subscribe to our feed

select webform