We have started rolling out EKS 1.18. This brings EKS on Kubernetes
In the process of upgrading EKS the following components have also been upgraded:
- KubeProxy from 1.17.12 to 1.18.9
- CoreDNS from 1.6.6 to 1.7.0
- Cluster Autoscaler from 1.17.4 to 1.18.3.
Upon writing upgrades of customer staging clusters have been rolled out. Production clusters will follow in the next week(s) after some extra validation, so you can expect to be contacted by an engineer to determine an upgrade window.
Important changes between K8s 1.17 and 1.18
Kubernetes 1.18 is a “fit and finish” release. Significant work has gone into improving beta and stable features to ensure users have a better experience. An equal effort has gone into adding new developments and exciting new features that promise to enhance the user experience even more.
Extending Ingress with and replacing a deprecated annotation with IngressClass
pathTypefield and a new
IngressClassresource has been added to the
pathTypefield allows specifying how paths should be matched. In addition to the default
ImplementationSpecifictype, there are new
IngressClassresource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new
ingressClassNamefield on Ingresses. This new resource and field replace the deprecated
Important: We don’t setup an
IngressClassfor our default
nginx-internal) Ingress controllers yet and thus still rely on the
kubernetes.io/ingress.classannotation. We plan to implement this in a future update.
For more detailed information, check the Improvements to the Ingress API in Kubernetes 1.18 page.
Serverside Apply introduces Beta 2
This new version will track and manage changes to fields of all new Kubernetes objects, allowing you to know what changed your resources and when. For more information, check the What is Server-side Apply? documentation.
This feature is still in beta (v2 now) and not used as default. You can run it with
kubectl apply --server-side.
Pod Topology Spread moves to Beta
You can use topology spread constraints to control how pods are spread across your cluster among failure-domains such as Regions, zones, nodes, and other user-defined topology domains. For more information, check the Topology Spread Constraints documentation.
Kubernetes Topology Manager moves to Beta
This feature allows the CPU and Device Manager to coordinate resource allocation decisions, optimizing for low latency with machine learning and analytics workloads. For more information, check the Control Topology Management Policies on a node documentation.
We leave the Topology Manager’s policy unconfigured (so
none, default). If you’re interested in this feature, please let your Lead engineer know.
Configurable Horizontal Pod Autoscaling behavior
Starting from v1.18 the
v2beta2API allows scaling behavior to be configured through the HPA behavior field. For more information, check the Support for configurable scaling behavior documentation.
Actions to take
There are no specific actions to take for your workloads. A Skyscrapers engineer will get in contact in the coming week(s) to plan an upgrade window for production.
However, if not already the case, you should consider moving all
Ingresses from the deprecated
extensions/v1beta1 apiVersion to
networking.k8s.io/v1beta1 in preparation of it’s removal in future Kubernetes versions.