EKS Blueprints are a new approach to Kubernetes cluster development released by AWS to simplify how EKS administrators build and deploy cluster infrastructure while following best practices. Blueprints are provided as modules for the Cloud Development Kit (CDK) and Terraform, and they are capable of deploying Kubernetes addons, AWS infrastructure, EKS node groups, observability tools, and other useful resources. The modules enable administrators to quickly assemble building blocks to deploy their clusters and the surrounding infrastructure.
This article will cover how Blueprints work, how administrators can deploy them, and what best practices they should follow.
|What are EKS Blueprints?||Blueprints are preconfigured templates for CDK or Terraform to deploy components for an EKS cluster. Their purpose is to provide building blocks for cluster administrators to quickly develop EKS clusters and the supporting infrastructure.|
|How are EKS Blueprints deployed?||EKS Blueprints are deployed via either the Terraform or CDK tools. The Blueprint libraries are imported as modules imported into these IaC tools.|
|Gathering requirements||Administrators need to determine their EKS infrastructure requirements to plan which Blueprints could fulfill their use cases. Having a clear understanding of the target architecture is important for effective planning.|
|Exploring EKS Blueprint resources||There are several key resources for administrators to investigate, containing Blueprint libraries, examples, and tutorials. Researching these resources will help administrators understand what Blueprints are available and how they can be implemented.|
|Testing and validation||Testing Blueprints in a development environment will enable administrators to validate their Blueprints’ functionality and determine if they are meeting use case requirements.|
|How can GitOps be implemented with EKS Blueprints?||The EKS Blueprint from ArgoCD enables administrators to automatically bootstrap EKS clusters with workloads stored in Git repositories. The modern GitOps model allows faster cluster setup and reduced operational overhead.|
|EKS Blueprints best practices?||To leverage Blueprints effectively, administrators will need to effectively plan their architecture, determine appropriate Blueprints to implement, test their functionality, validate their flexibility, and ensure that security best practices are being followed.|
|Conclusion||EKS Blueprints can be a useful tool for administrators to quickly build EKS cluster infrastructure via IaC and GitOps. Administrators can benefit from reduced operational overhead and faster setup times.|
EKS Blueprints are predefined templates provided by AWS to help cluster administrators easily set up their cluster infrastructures. A Blueprint defines configurations for resources like the cluster control plane, node groups, networking resources, addons, and third-party project integrations. The goal of the feature is for administrators to have access to a well-tested library of predefined configurations following operational best practices. Blueprints enable administrators to reduce the operational overhead of developing solutions from scratch by leveraging existing templates as building blocks for their infrastructures.
EKS Blueprints are currently provided in two flavors: Terraform and CDK. Both tools offer an approach to deploying cloud resources via infrastructure as code (IaC), a modern approach to deploying resources that involves defining infrastructure requirements in configuration files. This enables developers to leverage version control for tracking configuration changes over time and allows infrastructure to be deployed in a consistent and deterministic manner.
Terraform and CDK are two IaC tools that allow developers to define their infrastructure configurations and deploy these resources to a cloud environment. EKS Blueprints are available as modules for Terraform and CDK, allowing cluster administrators to quickly develop their EKS cluster infrastructure without manually writing excessive code to define their resources.
An additional benefit of EKS Blueprints is that the default configurations will follow operational best practices. AWS configures security, high-availability, and scalability defaults to follow best practice recommendations, which helps ensure that administrators are building their clusters with appropriate settings.
For example, there is an EKS Blueprint for the AWS Load Balancer Controller. The Controller provisions Load Balancer resources for EKS clusters. Administrators need to take additional steps to enable an IAM Role specific to the Controller’s pod when installed manually. Without this additional step, the Controller pod will instead use the worker node’s IAM Role, which is a security risk: The node IAM Role will have excessive permissions, so it should not be utilized by pods.
The EKS Blueprint for the Load Balancer Controller will automate the Controller installation and perform the entire IAM Role setup. The pod-specific IAM Roles are attached with the IAM Roles for Service Accounts (IRSA) feature. The EKS Blueprint will automate the Controller’s configuration, including creating the IAM Role and IAM Policy and modifying the pod’s Annotations to enable IRSA.
This Blueprint automation for the Load Balancer Controller will ensure that security best practices are being followed without any additional intervention by the administrator.
Overall, administrators benefit from reduced operational head and improving production readiness by leveraging EKS Blueprints to set up their EKS environments.
EKS Blueprints can be deployed via either Terraform or CDK. Typically, administrators should select the tool that is suitable for managing all of their AWS infrastructure. This will ensure that a single IaC tool is used for both general AWS infrastructure and the EKS cluster resources.
Administrators can begin planning for EKS Blueprints integration by determining their infrastructure requirements. Planning the desired EKS cluster architecture will help inform decisions about what EKS Blueprints will be helpful for fulfilling requirements. Details about the cluster’s desired functionality will need to be gathered, including:
In summary, administrators will benefit from carefully gathering requirements to effectively plan their EKS cluster setups and determine what Blueprints can be leveraged to simplify operational overhead.
Once the basic requirements have been gathered to determine the cluster’s design and operational needs, administrators can begin exploring what EKS Blueprints are available to fulfill their design requirements. This exploration will involve evaluating the CDK or Terraform Blueprint libraries available for use and what configuration parameters they allow.
The latter aspect is important for administrators to evaluate. When implementing Blueprints, some parameters will not be configurable, which will impose limitations on administrators. The administrator should consider which parameters are configurable and what parameters are restricted to determine if the Blueprint will still fit the requirements. Administrators who require maximum configuration flexibility may need to avoid using Blueprints and instead manually deploy their solutions. The benefit of Blueprints is a preconfigured packaged solution, but this also becomes a limitation on flexibility, depending on the use case.
There are a few key locations that administrators should research to gather information on implementing EKS Blueprints. Analyzing the available libraries and associated documentation will help administrators understand the Blueprint’s capabilities and how to begin testing them with their EKS clusters.
These resources contain tutorials for administrators to get started with deploying EKS Blueprints. The tutorials explain setting up a local development environment and deploying sample applications. Administrators should begin with these resources to gain familiarity with how Blueprints are used.
These repositories contain useful resources like code samples for administrators to leverage. The repositories are frequently updated with new resources, and administrators should keep an eye on newly released features that they can leverage in their own environments.
Administrators should validate EKS Blueprint functionality in a development environment to gather information on the Blueprint’s usefulness. Testing Blueprints should be done in non-production environments due to the potential impact of the various AWS infrastructure changes being applied.
Validation may include answering these questions:
There are Blueprints available for Kubernetes addons as well as for AWS infrastructure. Testing both of these would be ideal for gathering the most data. Since every EKS cluster will require some node group infrastructure, trying to deploy a managed node group Blueprint would be a reasonable starting point to begin testing Blueprint capabilities:
Testing EKS Blueprints in a development environment will help administrators gain confidence about whether the libraries are helping their EKS journeys, meeting their requirements, and are a suitable option for long-term adoption. It is essential for thorough testing to be completed to ensure that administrators can make the right design decisions for their EKS environments.
GitOps is a deployment model enabling users to define their Kubernetes workloads and infrastructure requirements in a version-controlled repository. It involves configuring a Kubernetes Controller like ArgoCD to watch for changes to the repository and automatically deploy manifests to the Kubernetes cluster. The benefit of this model is it allows both infrastructure and application workloads to be stored in a Git repository as a source of truth. Users can simply push new manifests to the repository and expect them to be automatically deployed to the cluster. This model goes beyond traditional CI/CD pipelines by leveraging Kubernetes principles like “Desired State,” “Continuous Reconciliation,” and “Pull-Based Deployment.”
EKS Blueprints can provide out-of-the-box GitOps functionality via the ArgoCD Blueprint. The EKS Blueprint for ArgoCD can install the ArgoCD Controller into the target EKS cluster during cluster creation and configure ArgoCD to point to a specified Git repository containing the Kubernetes manifests (YAML files, Helm Charts, Kustomize files, etc.). This functionality allows administrators to store Kubernetes resources in a Git repository and let ArgoCD synchronize and deploy the manifests into the cluster.
Here is a CDK Blueprint example demonstrating how ArgoCD integration can be added to an EKS cluster:
The example can be extended to change the default admin password and point ArgoCD to an external Git repository to begin bootstrapping the cluster with additional Kubernetes workloads. When an administrator or developer commits new workload objects to the Git repository, ArgoCD will automatically download and deploy the Kubernetes objects into the EKS cluster without any additional steps required by the user.
Here are the key best practices to follow when implementing EKS Blueprints:
EKS Blueprints are a useful tool for administrators implementing Terraform or CDK to deploy their EKS cluster infrastructure. Blueprints enable administrators to quickly deploy prepackaged infrastructure components like node groups and Kubernetes addons using only a few lines of code, with best practices enabled by default.
Leveraging Blueprints to accelerate infrastructure development can reduce operational overhead and increase operational readiness. Administrators will still need to test and validate that the selected Blueprints provide sufficient functionality and flexibility to meet their use case requirements. When using IaC and GitOps, testing Blueprints in a development environment is relatively straightforward and will provide insight into the environment’s operational readiness. Overall, Blueprints are a worthwhile feature for EKS administrators to evaluate as part of their infrastructure development workflows.
Subscribe to our monthly LinkedIn educational digest for content like this.Subscribe now