Patch-level EKS version upgrades are performed automatically by AWS, and do not require human intervention.
Major/Minor-level EKS version upgrades require us to explicitly set the version in our deployment configuration, manually update some of the control-plane components and ensure that worker nodes are running compatible versions.
AWS publishes guidance for upgrades on the EKS documentation site.
We try to split the upgrade process into discrete stages so that the impact of each stage can observed:
- Upgrade the control-plane EKS version
- Upgrade control-plane components (if required)
- Upgrade worker nodes
All three stages should be performed and tested in an on-demand cluster before an upgrade to any of the components is merged to master and rolled. This ensures we don't release any time-bombs.
The control plane version is set from a terraform variable.
The value for this variable comes either from the cluster's "cluster-config" or from the default values provided by the gsp deployer pipeline.
Most clusters do not pin a specific EKS version, so updating the default
eks-version is usually all that is required to upgrade all clusters.
- See PR568: upgrade EKS control plane for an example of updating default control-plane version.
As part of the EKS upgrade documentation AWS may recommend that some other components are upgraded to align with control-plane changes.
We maintain these components as templates within the gsp-cluster chart.
- See PR541: upgrade coredns for an example of upgrading DNS components.
- See PR534: upgrade vpc-cni and calico for an example of upgrading networking components.
- See PR542: upgrade kube-proxy for an example of updating the KubeProxy components
We deploy worker nodes as EC2 instances based on the Amazon EKS-Optimized Linux AMI in an AutoScalingGroup losely based on the cloudformation template provided by amazon, but deploy it via terraform.
AWS will advertise the AMI ID that is compatible with a given EKS control-plane version in their documentation.
Changes to the cloudformation template (such as updating the AMI reference) trigger a rolling deployment of each worker node on deploy.
An AutoScaling lifecycle hook helps ensure that instances are drained before retirement as the rolling deployment takes place.
- See PR1134: Bump worker nodes AMI for an example of changing the worker node EKS version.
There's a badge on the README.md that notes the current kubernetes version. Give it a bump!