The Horizontal Pod Autoscaler and Kubernetes Metrics Server are now supported by Amazon Elastic Container Service for Kubernetes (EKS). This makes it easy to scale your Kubernetes workloads managed by Amazon EKS in response to custom metrics.

One of the benefits of using containers is the ability to quickly autoscale your application up or down. For many workloads, it’s crucial to be able to define application scaling based on custom metrics like inbound connection requests or job queue length. The Horizontal Pod Autoscaler (HPA) is a Kubernetes component that automatically scales your service based on CPU utilization or other metrics that you define through the Kubernetes Metrics Server.

How Do I Know if My Cluster Supports the Horizontal Pod Autoscaler?

To know if your EKS cluster currently has support for the Horizontal Pod Autoscaler, you can look at your cluster details in the EKS Console and look for the EKS platform version.

Amazon EKS platform versions are used to refer to a specific patch version of Kubernetes, as well as the Kubernetes API server configuration. New platform versions are released to reflect when Kubernetes patch versions are released or changes are made to how EKS has configured the Kubernetes API server. All EKS clusters created before today are on PlatformVersion “eks.1”, and new clusters created today are on PlatformVersion “eks.2”.

Clusters running PlatformVersion “eks.2” have API Aggregation enabled and, as a result, support the Horizontal Pod Autoscaler and Kubernetes Metrics Server. Please note that you must use version 0.3.0 or greater of Kubernetes Metrics Server with Amazon EKS. Over the coming weeks, all EKS clusters will be patched and will move to the “eks.2” platform version.

Why Was HPA Not Supported Previously?

Previously, HPA was not supported by Amazon EKS because any component with a dependency on API Aggregation, such as the Kubernetes Metrics Server, would not start if the core Kubernetes API server was not using Client Certificate Authentication. Amazon EKS uses only webhook authentication to provide integration with AWS Identity and Access Management (IAM).

To solve this, we made modifications to upstream Kubernetes in order to allow the Metrics Server to work with a Kubernetes API server configuration that does not use Client Certificate Authentication. We worked with the Kubernetes community to merge this change upstream and add this change into Kubernetes versions 1.9, 1.10, and 1.11. Now, the Kubernetes Metrics Server supports a Kubernetes API server that uses webhook authentication. This makes it possible to use the Kubernetes Metrics Server and Horizontal Pod Autoscaling for Amazon EKS clusters, and ensures a consistent authentication mechanism for EKS clusters that maximizes cluster security. This allows you to scale your Kubernetes services based on metrics that you define, making it easier to run production workloads with Amazon EKS.

To get started with setting up the Horizontal Pod Autoscaler on an EKS cluster, see the Kubernetes documentation.

What’s Next?

Of course, our work is not done. Any upstream codebase that has a dependency on the Aggregated API server needs to be updated to the latest Kubernetes patch releases. The next release of the Kubernetes Service Catalog will support Amazon EKS, and we will update this blog post to point to the new version when it is available. (Note: Service Catalog release 0.1.35 now supports EKS!)

We’re excited to be able to contribute to the Kubernetes community to help make it easier to run Kubernetes in the cloud. Thanks to the following community members who helped us out in these efforts:

If you’re interested in joining the team and contributing to Kubernetes or building a Kubernetes service on AWS, we’re hiring Software Development Engineers, System Development Engineers, Software Development Managers, Business Development Managers, and Product Managers.

We look forward to your feedback and suggestions in the comments.