Core Concepts¶
This document provides a high level overview of the Core Concepts that are embedded in the eks-blueprints framework. For the purposes of this document, we will assume the reader is familiar with Git, Docker, Kubernetes and AWS.
| Concept | Description |
|---|---|
| Blueprint | A blueprint combines clusters, add-ons, and teams into a cohesive object that can deployed as a whole |
| Cluster | A Well-Architected EKS Cluster. |
| Resource Provider | Resource providers are abstractions that supply external AWS resources to the cluster (e.g. hosted zones, VPCs, etc.) |
| Add-on | Allow you to configure, deploy, and update the operational software, or add-ons, that provide key functionality to support your Kubernetes applications. |
| Team | A logical grouping of IAM identities that have access to a Kubernetes namespace(s). |
| Pipeline | Continuous Delivery pipelines for deploying clusters and add-ons. |
| Application | An application that runs within an EKS Cluster. |
Blueprint¶
The eks-blueprints framework allows you to configure and deploy what we call blueprint clusters. A blueprint consists of an EKS cluster, a set of add-ons that will be deployed into the cluster, and a set of teams who will have access to a cluster. Once a blueprint is configured, it can be easily deployed across any number of AWS accounts and regions. Blueprints also leverage GitOps tooling to facilitate cluster bootstrapping and workload onboarding.
To view sample blueprint implementations, please see our patterns repository.
Cluster¶
A cluster is simply an EKS cluster. The eks-blueprints framework provides for customizing the compute options you leverage with your clusters. The framework currently supports EC2, Fargate and BottleRocket instances. To specify the type of compute you want to use for your cluster, you supply a ClusterProvider object to your blueprint. The framework defaults to leveraging the MngClusterProvider.
Each ClusterProvider provides additional configuration options as well. For example, the MngClusterProvider allows you to configure instance types, min and max instance counts, and amiType, among other options.
See our Cluster Providers documentation page for detailed information.
Resource Provider¶
A resource is a CDK construct that implements IResource interface from aws-cdk-lib which is a generic interface for any AWS resource. An example of a resource could be a hosted zone in Route53 IHostedZone, an ACM certificate ICertificate, a VPC or even a DynamoDB table which could be leveraged either in add-ons or teams.
ResourceProviders enable customers to supply resources for add-ons, teams and/or post-deployment steps. Resources may be imported (e.g., if created outside of the platform) or created with the blueprint.
See our Resource Providers documentation page for detailed information.
Add-on¶
Add-ons allow you to configure the tools and services that you would like to run in order to support your EKS workloads. When you configure add-ons for a blueprint, the add-ons will be provisioned at deploy time. Add-ons can deploy both Kubernetes specific resources and AWS resources needed to support add-on functionality.
For example, the MetricsServerAddOn only deploys the Kubernetes manifests that are needed to run the Kubernetes Metrics Server (as a Helm chart). By contrast, the AWSLoadBalancerControllerAddon deploys Kubernetes resources, in addition to creating resources via AWS APIs that are needed to support the AWS Load Balancer Controller. The most common case to address via an add-on is configuration of IAM roles and permissions and the Kubernetes service account, leveraging IRSA to access AWS resources.
See our Add-ons documentation page for detailed information.
Team¶
Teams allow you to configure the logical grouping of users that have access to your EKS clusters, in addition to the access permissions they are granted. The framework currently supports two types of teams: ApplicationTeam and PlatformTeam. ApplicationTeam members are granted access to specific namespaces. PlatformTeam members are granted administrative access to your clusters.
See our Teams documentation page for detailed information.
Pipeline¶
Pipelines allow you to configure Continuous Delivery (CD) pipelines for your cluster blueprints that are directly integrated with your Git provider.
See our Pipelines documentation page for detailed information.
Application¶
Applications represent the actual workloads that run within a Kubernetes cluster. The framework leverages a GitOps approach for deploying applications onto clusters.
See our Workload Bootstrapping documentation for detailed information.