AWS EKS Configuration

This repository contains an Upbound project, tailored for users establishing their initial control plane with Upbound. This configuration deploys fully managed Amazon Elastic Kubernetes Service (EKS) instances.

Overview

The core components of a custom API in Upbound Project include:

• CompositeResourceDefinition (XRD): Defines the API's structure.
• Composition(s): Configures the Functions Pipeline
• Embedded Function(s): Encapsulates the Composition logic and implementation within a self-contained, reusable unit

In this specific configuration, the API contains:

• an AWS EKS custom resource type.
• Composition: Configured in /apis/eks/composition.yaml
• Embedded Function: The Composition logic is encapsulated within embedded function

Deployment

• Execute up project run
• Alternatively, install the Configuration from the Upbound Marketplace
• Check examples for example XR(Composite Resource)

Testing

The configuration can be tested using:

• up composition render --xrd=apis/eks/definition.yaml apis/eks/composition.yaml examples/eks/eks-xr.yaml to render the composition
• up test run tests/* to run composition tests in tests/test-eks/
• up test run tests/* --e2e to run end-to-end tests in tests/e2etest-eks/

Next steps

This repository serves as a foundational step. To enhance your configuration, consider:

1. create new API definitions in this same repo
2. editing the existing API definition to your needs

To learn more about how to build APIs for your managed control planes in Upbound, read the guide on Upbound's docs.

Adopting an existing cluster

bootstrapSelfManagedAddons is create-only and DescribeCluster never returns it, so an adopted cluster observes false against the schema default true. In forProvider that replace-diff never resolves, the cluster stays Synced=False, and the composition stalls at kubernetesClusterAuth - no node group, no add-ons, no kubeconfig. It is set through initProvider, whose keys upjet filters out of the update diff, and must never also appear in forProvider.

Managed Resource Activation Policy

This configuration includes a ManagedResourceActivationPolicy (MRAP) that enables only the required CRDs from dependent providers. If you're running Crossplane without a default activation policy, this ensures that only the necessary CRDs are activated, reducing resource overhead and improving control plane performance.

To view the MRAP:

kubectl get managedresourceactivationpolicy configuration-aws-eks -o yaml