Enhanced deployment support with the Amazon EKS Quick Start

The Amazon Elastic Kubernetes Service (Amazon EKS) helps you to deploy, manage, and scale containerized applications on the Amazon Web Services (AWS) Cloud. If you are just starting your container journey, the Modular and Scalable Amazon EKS Architecture Quick Start serves as a helping hand by providing a best-practice reference architecture. Through the Quick Start AWS CloudFormation templates, you can automate a repeatable, customizable, and highly reliable deployment.

Alfresco, Inc., an open-source Enterprise Content Management Advanced Technology Partner in the AWS Partner Network (APN), enhanced the Alfresco Content Services product to incorporate the Amazon EKS Quick Start. This enhancement gives an additional deployment option for Docker and Kubernetes to address customer demand. The Alfresco development team has adopted the Quick Start as a building block. This approach helps ensure the software deployment follows AWS and Alfresco best practices, and it simplifies software upgrades and hotfix delivery.

While the Amazon EKS Quick Start eliminates undifferentiated heavy-lifting code that customers would have to write themselves, technology partners like Alfresco actively contribute and provide enhancements that help to continually improve the standards and feature set of the EKS Quick Start. For example, recent contributions included: a deployment option for Cluster Autoscaler, a secure way to access custom Kubernetes plugins after installation, and the ability to execute additional commands against worker nodes.

In this blog post, I will review the challenges Alfresco experienced while contributing the enhancements; how they were able to use the GitHub pull request process for review and approval; and how Alfresco made available the new capabilities to the larger AWS community.

Enabling Cluster Autoscaler

Previously, the Amazon EKS Quick Start provided a static scaling feature. Resizing the cluster required manual configuration to define the scale-out boundary. Now the provisioning of the Cluster Autoscaler Helm chart can be enabled and set to a maximum cluster size based on the customer’s requirements.

With Cluster Autoscaler enabled, worker nodes will automatically scale in or out based on the total demand for capacity. If the new pods require additional resources to run, a new working node will be added to the cluster. Similarly, a node will be drained when it is underutilized.

As the worker nodes scale in, the autoscaler might move pods and restart them on other nodes. If your pods have only one replica, your services may experience temporary disruption. You will need to make sure your application is disruption-tolerant prior to enabling Cluster Autoscaler. To better handle disruption and ensure high availability, consider running two or more replicated applications, or spread applications across racks or zones.

Check out the post Run your Kubernetes Workloads on Amazon EC2 Spot Instances with Amazon EKS, which discusses how you can use Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances as Kubernetes worker nodes. The post includes a walkthrough on deploying Cluster Autoscaler and handling interruptions across your cluster.

Access through an SSH tunnel

Alfresco wanted to use Prometheus and Grafana for metrics-based monitoring and alerts, but the Linux bastion host in the Amazon EKS Quick Start was, by default, not set up with the forwarding options to ensure security best practices for those interfaces. That use case required a Secure Shell (SSH) tunnel, so that the interfaces are not exposed to the outside world with public-facing endpoints. Whether to enable the bastion host is a design decision that requires discreet consideration to minimize the risk.

This update opens up the ability to access Kubernetes interfaces via bastion host, thus achieving secure cluster admin operations. You can now install different interfaces like the Kubernetes dashboard, Prometheus, and Grafana in the application, and set up an SSH tunnel from a local machine. This is accomplished through adding BastionEnableTCPForwarding and BastionEnableX11Forwarding parameters into the main Amazon EKS template.

This diagram demonstrates how Alfresco is nesting the Amazon EKS Quick Start in its cluster, and then using its custom resource type for deploying the interfaces that they want to use.

Using AWS Systems Manager

Some use cases go beyond the capability of the current Amazon EKS Quick Start, and you will need to perform these operations against worker nodes through AWS Systems Manager. For example, Alfresco needed to make changes to the property of a Helm installation, which is not currently supported in the Quick Start. AWS Systems Manager, however, does not come pre-installed and enabled. Setting up Systems Manager in your environment would require extra steps.

Now, a managed Systems Manager policy is included in the Amazon EKS Quick Start, and you can use Systems Manager through the bastion host. You might wonder, as Systems Manager Agent (SSM Agent) is not required for Amazon EKS functionality, what other reasons are there to place SSM Agent on your EKS nodes. Check out the post Using AWS Systems Manager Automation and AWS CloudFormation Together to explore how Systems Manager can assist with automation from AWS CloudFormation.

Conclusion

In this blog post, I reviewed the key enhancements achieved by the Alfresco development team on the Amazon EKS Quick Start that are beneficial to your future deployment. I encourage you to start exploring these added values by experimenting with the Amazon EKS Quick Start with your Kubernetes deployment. If you are an experienced user like Alfresco, you are welcome to provide open-source contribution through issues and pull requests in our GitHub repository. Community engagement is an important aspect in growing our Quick Start templates to meet customer requirements.