CODEWITHSUNDEEP
amazon-web-serviceskuberneteskubectlamazon-eks
Luca Rasconi
Luca Rasconi

Reputation: 1105

EKS upgrade of first of November

I've an EKS cluster in AWS.

[cloudshell-user@ip-10-0-87-109 ~]$ kubectl version --short
Kubeconfig user entry is using deprecated API version client.authentication.k8s.io/v1alpha1. Run 'aws eks update-kubeconfig' to update.
Client Version: v1.23.7-eks-4721010
Server Version: v1.20.11-eks-f17b81

[cloudshell-user@ip-10-0-87-109 ~]$ kubectl get nodes
Kubeconfig user entry is using deprecated API version client.authentication.k8s.io/v1alpha1. Run 'aws eks update-kubeconfig' to update.
NAME                    STATUS   ROLES    AGE     VERSION
fargate-172.101.0.134   Ready    <none>   13d     v1.20.15-eks-14c7a48
fargate-172.101.0.161   Ready    <none>   68d     v1.20.15-eks-14c7a48

On Nov 1st AWS is going to update the server version to 1.21 because AWS going to end the support of 1.20.

What problems will come up? I read

no EKS features were removed in 1.21

What should I do in order to be safe?

Upvotes: 0

Views: 1269

Answers (2)

Adiii
Adiii

Reputation: 59896

You do not really need to perform any safety checks on your end, AWS will take care of the upgrade process (at least from 20 to 21. My recommendation will be to upgrade before AWS tries to upgrade the cluster, as once it reached the end of life, the upgrade can happen anytime

The only thing you need to update manually

  • Self-managed Node Group
  • Any add-on

The breaking change is the service account token expiry

  • Any service that depends on a service token account, keep in mind that now the token will expire in one hour and the service/pod need to refresh the token

Service account tokens now have an expiration of one hour. In previous Kubernetes versions, they didn't have an expiration.

On the end of support date, you can no longer create new Amazon EKS clusters with the unsupported version. Existing control planes are automatically updated by Amazon EKS to the earliest supported version through a gradual deployment process after the end of support date. After the automatic control plane update, make sure to manually update cluster add-ons and Amazon EC2 nodes.

kubernetes-versions-1.21

Upvotes: 2

Binh Nguyen
Binh Nguyen

Reputation: 2159

With EKS version upgraded, it is based on the official Kubernetes upstream version upgrade so you better check what changes and deprecation between 1.20 and 1.21 and do they affect your current workload because of changes from APIs.

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#changelog-since-v1200

If yes, you have to prepare updating your manifests: https://aws.amazon.com/blogs/containers/preparing-for-kubernetes-api-deprecations-when-going-from-1-15-to-1-16/

From the official calendar, it says End Of Support on November 1st but there are some FAQs that you need to understand first: https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#version-deprecation

  • On the end of support date, you can no longer create new Amazon EKS clusters with the unsupported version.
  • Amazon EKS will automatically upgrade existing control planes (not nodes) to the oldest supported version through a gradual deployment process after the end of support date. Amazon EKS does not allow control planes to stay on a version that has reached end of support.
  • After the automatic control plane update, you must manually update cluster add-ons and Amazon EC2 nodes.

To be safe, you have to

  • prepare your manifests to be updated with latest Kubernetes version that you are going to upgrade to.
  • proactively upgrade your EKS before AWS forces doing it.
  • remember to upgrade EKS add-ons, node groups and test any of your current controllers in the new version: https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html
  • I suggest you just provision a test cluster with spot instances and try out your application first.

amazon-eks-release-calendar

References:

Upvotes: 2

Related Questions