Skip to content

0.5.0 - VPC CNI Prefix Delegation support

Latest
Latest
Compare
Choose a tag to compare
@bmonkman bmonkman released this 16 Aug 19:22
· 32 commits to main since this release
v0.5.0
960b6e9
This commit was signed with the committer’s verified signature.
bmonkman Bill Monkman
GPG key ID: E44C6C1F3DEA82D0
Learn about vigilant mode.

This change adds support for IP Prefix Delegation in the VPC CNI, which solves the biggest problem we've had with EKS so far - the limitation of the number of IPs per node.
Previous to this change, small/medium nodes like the t3.medium had only 17 IP addresses available to them, which meant you could have a maximum of 17 pods per node, even if the utilization of other resources like memory or CPU was low. This was an unnecessary additional cost for small cluster owners, and we're happy AWS was able to implement this change.

After applying this change, people with 2 or more nodes in their staging clusters may be able to reduce their cluster size to 1, depending on their workloads (this may happen automatically due to the cluster autoscaler).
We still recommend that any production clusters maintain more than one node at all times.

To upgrade an existing cluster you can follow these steps:

  • EKS version to 1.21, and the EKS CNI version to v1.9.0-eksbuild.1 (this may require first upgrading to 1.8.0 as you can't skip over a minor version.
  • terraform apply - this will take a while as it updates the Kubernetes version in your cluster
  • Bump the Zero EKS module version to 0.5.0
  • In your existing EKS node groups, add use_large_ip_range = false option to maintain their current config
  • Add new node groups with new names that don't specify the above flag, so they have the new config
  • terraform apply - this will bring up new node groups and tear down the old ones, transferring your k8s workloads over.

Unfortunately, there was a breaking change with how we are using security groups which may cause a small downtime since during the second apply above the cluster may be unable to access the database. If you want to apply this to an existing production cluster and want zero downtime you can achieve that by doing a terraform plan before the second apply, finding any security group removal lines, and removing those records from your state using terraform state rm which means you'll have both the new and old security group rules during the apply.
Feel free to ask in the Zero Slack community if you'd like any help with this process!

Assets 2
Loading