Kubernetes is the new normal when it comes to host your applications.
AWS Elastic Kubernetes service is a managed service where the control plane is deployed in a High Availability and it is completely managed by AWS in the backend allowing the administrators/SRE/DevOps Engineers to manage the data plane and the microservices running as pods.
As of writing the post today Kubernetes community has a three releases per year cadence for the k8s version. On the other hand AWS has their own customized version of Kubernetes(EKS Version) and have their own release cadence. You could find this information at https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
Note - EKS upgrade is a step upgrade and can be upgraded from one minor version at a time for e.g. 1.21 to 1.22
Managing AWS EKS via terraform helps us to maintain the desired state and it also allows us seamlessly to perform the cluster upgrade.
Pre-requisites in Terraform
- Verify that the state file of EKS does not throws any error before the upgrade.
- Ensure the state is stored in a remote place such as Amazon S3
Pre-requisites in EKS
- Ensure 5 free IP addresses from the VPC subnets of EKS cluster (explained in below section)
- Ensure the Kubelet version is same as the control plane version
- Verify EKS addons version and upgrade if necessary before the start of cluster upgrade.
- Pod Disruption Budget (PDB) some time cause error while draining pods (recommended to disable it while upgrading)
- Use an K8s API depreciation finder tool like Pluto to support the API changes on the newer version.
Upgrade Process
https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html
Let me break down the upgrade process that happens when we perform the upgrade. This is a sequential upgrade
Control Plane upgrade
The control plane upgrade is an in-place upgrade means that it launches new control plane with the target version within the same subnet of the existing control plane and that is the where we need atleast 5 free IPs in the EKS subnet to accommodate the new control plane. The new control plane will go through readiness and health check and once passed the new control plane will replace the old plane. This process happens in the backend within AWS infrastructure and there will be no impact to application
Node upgrade
The node upgrade is also an in-place upgrade where it launches new nodes with the target version and the pod from old nodes will get evicted and launched in the new node.
Add-ons upgrade
The addons such as coredns, VPC CNI, kube-proxy etc on your cluster need to be upgraded accrodingly as per the matrix in https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#vpc-add-on-update.
Let us take an example of upgrading from 1.21 to 1.22
Step-1:
Ensure control plane and nodes are in same version
kubectl version --short
kubectl get nodes
Step-2:
Before updating your cluster, ensure that the proper Pod security policies are in place. This is to avoid potential security issues
kubectl get psp eks.privileged
Step-3:
Update you target version in your terraform file to the target version say 1.22 and then perform a TF plan and apply
Step-4:
Once the control is upgraded,the managed worker nodes upgrade process get invoked automatically. In case you are using the self managed worker nodes upgrade. Choose the AMI as per your control plane version and region in the matrix below https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html
Update your worker nodes TF file with the new AMI id and run TF plan and apply
Step-5:
Once control plane and workernodes upgrade were completed. Now it is time to upgrade the addons, see what addons are enabled in your cluster and upgrade each addons via console or eksctl based on how you manage it.
Each addons has the compatiblity matrix from the AWS documentation and it has to be upgraded appropriately
sample ref : https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html#vpc-add-on-update
Step-6:
If you wish to upgrade from 1.22 to 1.23 repeat the steps above
Top comments (0)