Reading Time: 5 minutes

Hello Readers, In this blog, I’ll be sharing the steps to upgrade EKS using Terraform.

Here, I’m using Terraform version **v0.12.9**

As we know that AWS keeps updating its EKS service, and keep on deprecating the older versions, so we also need to upgrade our EKS cluster service side by side.

In this blog, I’ll be sharing the steps to upgrade the EKS cluster but before that, here are some points to note.

1. Incremental Upgrade: The EKS needs to be upgraded incrementally, which means you can increment the version only by 1 at a time.

This means that you can follow this blog only if you are currently on EKS 1.15 version. If not, you need to upgrade to 1.14 first, and for that you can refer to my another blog on Upgrade EKS to 1.15 using Terraform.

2. Permissions: To upgrade the cluster, the controller node, from where you are running the Terraform commands, must have **eks:UpdateClusterVersion** permission. You can check the IAM roles for verifying this.

3. Deprecated API Versions: In the latest version of EKS, a number of ApiVersions for some Kubernetes objects have been deprecated. Let’s see these objects in detail.

Deprecated API Versions

Network Policy:

NetworkPolicy in extensions/v1beta1 API Version is no longer served. They need to use API Version as networking.k8s.io/v1.

PodSecurityPolicy:

PodSecurityPolicy in extensions/v1beta1 API Version is no longer served. They need to use API Version as policy/v1beta1.

DaemonSet:

DaemonSet in extensions/v1beta1 and apps/v1beta API Versions are no longer served. They need to use API Version as apps/v1.

Additionally, there are important changes inside the spec definition:

• spec.templateGeneration is removed
• spec.selector is required and immutable after creation
• spec.updateStrategy.type now defaults to RollingUpdate

Deployment:

Deployment in extensions/v1beta1, apps/v1beta1 and apps/v1beta2 API Versions are no longer served. They need to use API Version as apps/v1. Additionally, here also there are important changes inside the spec definition:

• spec.rollbackTo is removed
• spec.selector is now required and immutable after creation
• spec.progressDeadlineSeconds now defaults to 600 seconds
• spec.revisionHistoryLimit now defaults to 10
• maxSurge and maxUnavailable now default to 25%

StatefulSet:

StatefulSet in apps/v1beta1 and apps/v1beta2 API Versions are no longer served. They need to use API Version as apps/v1. Additionally, here also there are important changes inside the spec definition:

• spec.selector is now required and immutable after creation
• spec.updateStrategy.type now defaults to RollingUpdate

ReplicaSet:

ReplicaSet in extensions/v1beta1, apps/v1beta1 and apps/v1beta2 API Versions are no longer served. They need to use API Version as apps/v1. Additionally, here also there are important changes inside the spec definition:

• spec.selector is now required and immutable after creation.

Now, In your running cluster, you need to make sure that all your running services must be running on supported API Version for the above listed objects and not the depricated version. Here’s a way to do that:

Upgrading deprecated APIs using kubectl

If you are simply using kubectl to manage your Kubernetes deployments, you can do the following

• To check the API Version for above listed kubernetes object:
• Note: You need to have **jq** installed on your controller node. If not, it can be installed by using the following command:
• **sudo apt install jq**

kubectl get <object-name> --all-namespaces -o yaml | grep -A 1 last-applied-configuration| grep apiVersion | jq '.apiVersion+" "+.metadata.name'

## For eg: To get ApiVersion for all deployments, run:
kubectl get <object-name> --all-namespaces -o yaml | grep -A 1 last-applied-configuration| grep apiVersion | jq '.apiVersion+" "+.metadata.name'

• Now, for those object, which are using deprecated APIs, you can upgrade them to use the new API version by using the following command on their manifest file.

kubectl convert -f <manifest-file.yaml> --output-version apps/v1 | kubectl apply -f -

Upgrading deprecated APIs using helm

If you are using helm for managing your Kubernetes deployments, you can do the following

• Check for the helm charts of deployed services and verify if the above-listed objects are using the compatible API version. If not, change the API Version and re-deploy that chart.
• Even if you don’t upgrade the services whose objects are using older API Versions, it won’t make any effect on them. They will still run fine. The only problem you’ll face is while upgrading such charts. Helm won’t allow you to upgrade those charts and then the only option left is to purge the chart and re-deploy it.

After the deprecated APIs are removed, you are now ready to upgrade the EKS version.

#aws #aws services #devops #eks #terraform