From 5d41bfa7c0501c4f629ee1e2592fe13064ac136a Mon Sep 17 00:00:00 2001 From: Niall Thomson Date: Mon, 28 Oct 2024 11:00:22 -0600 Subject: [PATCH] Various fixes --- .../ack/configure-application.md | 2 +- .../crossplane/compositions/claims.md | 73 +++---------------- .../compositions/creating-a-composition.md | 12 +-- .../crossplane/compositions/index.md | 18 ++++- .../crossplane/compositions/testing.md | 21 ++++-- .../crossplane/configure-application.md | 34 ++++----- .../controlplanes/crossplane/how-it-works.md | 14 ++-- .../controlplanes/crossplane/index.md | 14 +++- .../controlplanes/crossplane/resources.md | 10 ++- 9 files changed, 89 insertions(+), 109 deletions(-) diff --git a/website/docs/automation/controlplanes/ack/configure-application.md b/website/docs/automation/controlplanes/ack/configure-application.md index 218677567..f79588cf4 100644 --- a/website/docs/automation/controlplanes/ack/configure-application.md +++ b/website/docs/automation/controlplanes/ack/configure-application.md @@ -41,7 +41,7 @@ Now we need to restart the carts Pods to pick up our new ConfigMap contents: ```bash $ kubectl rollout restart -n carts deployment/carts deployment.apps/carts restarted -$ kubectl rollout status -n carts deployment/carts --timeout=20s +$ kubectl rollout status -n carts deployment/carts --timeout=40s Waiting for deployment "carts" rollout to finish: 1 old replicas are pending termination... deployment "carts" successfully rolled out ``` diff --git a/website/docs/automation/controlplanes/crossplane/compositions/claims.md b/website/docs/automation/controlplanes/crossplane/compositions/claims.md index a90bedcff..70842cbf7 100644 --- a/website/docs/automation/controlplanes/crossplane/compositions/claims.md +++ b/website/docs/automation/controlplanes/crossplane/compositions/claims.md @@ -3,22 +3,22 @@ title: "Claims" sidebar_position: 20 --- -Once we’ve configured Crossplane with the details of the new XR we can either create one directly or use a Claim. Typically only the team responsible for configuring Crossplane (often a platform or SRE team) have permission to create XRs directly. Everyone else manages XRs via a lightweight proxy resource called a Composite Resource Claim (or claim for short). +Once we've configured Crossplane with the details of the new XR, we can either create one directly or use a Claim. Typically, only the team responsible for configuring Crossplane (often a platform or SRE team) has permission to create XRs directly. Everyone else manages XRs via a lightweight proxy resource called a Composite Resource Claim (or claim for short). -With this claim the developer only needs to specify a default **DynamoDB table name, hash keys, global index name** to create the table. This allows the platform or SRE team to standardize on aspects such as billing mode, default read/write capacity, projection type, cost and infrastructure related tags. +With this claim, the developer only needs to specify a default **DynamoDB table name, hash keys, and global index name** to create the table. This allows the platform or SRE team to standardize aspects such as billing mode, default read/write capacity, projection type, and cost and infrastructure-related tags. ```file manifests/modules/automation/controlplanes/crossplane/compositions/claim/claim.yaml ``` -Cleanup the Dynamodb table created from the previous Managed Resource section. +Let's start by cleaning up the DynamoDB table created in the previous Managed Resource section: ```bash $ kubectl delete tables.dynamodb.aws.upbound.io --all --ignore-not-found=true $ kubectl wait --for=delete tables.dynamodb.aws.upbound.io --all --timeout=5m ``` -Create the table by creating a `Claim`: +Now, we can re-create the table by creating a `Claim`: ```bash timeout=400 $ cat ~/environment/eks-workshop/modules/automation/controlplanes/crossplane/compositions/claim/claim.yaml \ @@ -28,7 +28,7 @@ $ kubectl wait dynamodbtables.awsblueprints.io ${EKS_CLUSTER_NAME}-carts-crosspl --for=condition=Ready --timeout=5m ``` -It takes some time to provision the AWS managed services, in the case of DynamoDB up to 2 minutes. Crossplane will report the status of the reconciliation in the `SYNCED` field of the Kubernetes Composite and Managed resource. +It takes some time to provision AWS managed services, in the case of DynamoDB up to 2 minutes. Crossplane will report the status of the reconciliation in the `SYNCED` field of the Kubernetes Composite and Managed resource. ```bash $ kubectl get table @@ -36,11 +36,11 @@ NAME READY SYNCED EXTERNAL-NAME eks-workshop-carts-crossplane-bt28w-lnb4r True True eks-workshop-carts-crossplane 6s ``` -Now, lets try to understand how the DynamoDB table is deployed using this claim: +Now, let's understand how the DynamoDB table is deployed using this claim: ![Crossplane reconciler concept](../assets/ddb-claim-architecture.webp) -On querying the claim `DynamoDBTable` deployed in the carts namespace, we can observe that it points to and creates a Composite Resource (XR) `XDynamoDBTable` +When querying the claim `DynamoDBTable` deployed in the carts namespace, we can observe that it points to and creates a Composite Resource (XR) `XDynamoDBTable`: ```bash $ kubectl get DynamoDBTable -n carts -o yaml | grep "resourceRef:" -A 3 @@ -51,7 +51,7 @@ $ kubectl get DynamoDBTable -n carts -o yaml | grep "resourceRef:" -A 3 name: eks-workshop-carts-crossplane-bt28w ``` -The Composition `table.dynamodb.awsblueprints.io` shows Composite Resource Kind (XR-KIND) as `XDynamoDBTable`. This Composition lets Crossplane know what to do when we created the `XDynamoDBTable` XR. Each Composition creates a link between an XR and a set of one or more Managed Resources. +The Composition `table.dynamodb.awsblueprints.io` shows Composite Resource Kind (XR-KIND) as `XDynamoDBTable`. This Composition informs Crossplane what to do when we create the `XDynamoDBTable` XR. Each Composition creates a link between an XR and a set of one or more Managed Resources. ```bash $ kubectl get composition @@ -59,7 +59,7 @@ NAME XR-KIND XR-APIVERSION A table.dynamodb.awsblueprints.io XDynamoDBTable awsblueprints.io/v1alpha1 143m ``` -On querying the `XDynamoDBTable` XR which is not confined to any namespace, we can observe that it creates DynamoDB Managed Resource `Table`. +When querying the `XDynamoDBTable` XR, which is not confined to any namespace, we can observe that it creates a DynamoDB managed resource `Table`: ```bash $ kubectl get XDynamoDBTable -o yaml | grep "resourceRefs:" -A 3 @@ -69,58 +69,3 @@ $ kubectl get XDynamoDBTable -o yaml | grep "resourceRefs:" -A 3 kind: Table name: eks-workshop-carts-crossplane-bt28w-lnb4r ``` - ---- - -When new resources are created or updated, application configurations also need to be updated to use these new resources. We've already configured the workload to use the correct table name in the previous section so lets just restart the pods: - -```bash -$ kubectl rollout restart -n carts deployment/carts -$ kubectl rollout status -n carts deployment/carts --timeout=2m -deployment "carts" successfully rolled out -``` - ---- - -Now, how do we know that the application is working with the new DynamoDB table? - -An NLB has been created to expose the sample application for testing, allowing us to directly interact with the application through the browser: - -```bash -$ kubectl get service -n ui ui-nlb -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}" -k8s-ui-uinlb-a9797f0f61.elb.us-west-2.amazonaws.com -``` - -:::info -Please note that the actual endpoint will be different when you run this command as a new Network Load Balancer endpoint will be provisioned. -::: - -To wait until the load balancer has finished provisioning you can run this command: - -```bash timeout=610 -$ wait-for-lb $(kubectl get service -n ui ui-nlb -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}") -``` - -Once the load balancer is provisioned you can access it by pasting the URL in your web browser. You will see the UI from the web store displayed and will be able to navigate around the site as a user. - - - - - -To verify that the **Carts** module is in fact using the DynamoDB table we just provisioned, try adding a few items to the cart. - -![Cart screenshot](../assets/cart-items-present.webp) - -And to check if items are in the DynamoDB table as well, run - -```bash -$ aws dynamodb scan --table-name "${EKS_CLUSTER_NAME}-carts-crossplane" --query 'Items[].{itemId:itemId,Price:unitPrice}' --output text -PRICE 795 -ITEMID 510a0d7e-8e83-4193-b483-e27e09ddc34d -PRICE 385 -ITEMID 6d62d909-f957-430e-8689-b5129c0bb75e -PRICE 50 -ITEMID a0a4f044-b040-410d-8ead-4de0446aec7e -``` - -Congratulations! You've successfully created AWS Resources without leaving the confines of the Kubernetes API! diff --git a/website/docs/automation/controlplanes/crossplane/compositions/creating-a-composition.md b/website/docs/automation/controlplanes/crossplane/compositions/creating-a-composition.md index c4654dcf1..f06e182f3 100644 --- a/website/docs/automation/controlplanes/crossplane/compositions/creating-a-composition.md +++ b/website/docs/automation/controlplanes/crossplane/compositions/creating-a-composition.md @@ -3,26 +3,28 @@ title: "Creating a Composition" sidebar_position: 10 --- -A `CompositeResourceDefinition` (or XRD) defines the type and schema of your Composite Resource (XR). It lets Crossplane know that you want a particular kind of XR to exist, and what fields that XR should have. An XRD is a little like a CustomResourceDefinition (CRD), but slightly more opinionated. Writing an XRD is mostly a matter of specifying an OpenAPI ["structural schema"](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). +A `CompositeResourceDefinition` (XRD) defines the type and schema of your Composite Resource (XR). It informs Crossplane about the desired XR and its fields. An XRD is similar to a CustomResourceDefinition (CRD) but with a more opinionated structure. Creating an XRD primarily involves specifying an OpenAPI ["structural schema"](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). -First, lets provide a definition that can be used to create a DynamoDB table by members of the application team in their corresponding namespace. In this example the user only needs to specify **name**, **key attributes** and **index name** fields. +Let's start by providing a definition that allows application team members to create a DynamoDB table in their respective namespaces. In this example, users only need to specify the **name**, **key attributes**, and **index name** fields. ```file manifests/modules/automation/controlplanes/crossplane/compositions/composition/definition.yaml ``` -A Composition lets Crossplane know what to do when someone creates a Composite Resource. Each Composition creates a link between an XR and a set of one or more Managed Resources - when the XR is created, updated, or deleted the set of Managed Resources are created, updated or deleted accordingly. +A Composition informs Crossplane about the actions to take when a Composite Resource is created. Each Composition establishes a link between an XR and a set of one or more Managed Resources. When the XR is created, updated, or deleted, the associated Managed Resources are correspondingly created, updated, or deleted. -The following Composition provisions the managed resources `Table` +The following Composition provisions the managed resource `Table`: ```file manifests/modules/automation/controlplanes/crossplane/compositions/composition/table.yaml ``` -Apply this to our EKS cluster: +Let's apply this configuration to our EKS cluster: ```bash $ kubectl apply -k ~/environment/eks-workshop/modules/automation/controlplanes/crossplane/compositions/composition compositeresourcedefinition.apiextensions.crossplane.io/xdynamodbtables.awsblueprints.io created composition.apiextensions.crossplane.io/table.dynamodb.awsblueprints.io created ``` + +With these resources in place, we've successfully set up a Crossplane Composition for creating DynamoDB tables. This abstraction allows application developers to provision standardized DynamoDB tables without needing to understand the underlying AWS-specific details. diff --git a/website/docs/automation/controlplanes/crossplane/compositions/index.md b/website/docs/automation/controlplanes/crossplane/compositions/index.md index 219d4be5d..32a4cc031 100644 --- a/website/docs/automation/controlplanes/crossplane/compositions/index.md +++ b/website/docs/automation/controlplanes/crossplane/compositions/index.md @@ -3,6 +3,20 @@ title: "Compositions" sidebar_position: 30 --- -In addition to provisioning individual cloud resources, Crossplane offers a higher abstraction layer called Compositions. Compositions allow users to build opinionated templates for deploying cloud resources. For example, organizations may require certain tags to be present to all AWS resources or add specific encryption keys for all Amazon Simple Storage (S3) buckets. Platform teams can define these self-service API abstractions within Compositions and ensure that all the resources created through these Compositions meet the organization’s requirements. +In addition to provisioning individual cloud resources, Crossplane offers a higher level of abstraction called Compositions. Compositions enable users to create opinionated templates for deploying cloud resources. This feature is particularly useful for organizations that need to enforce specific requirements across their infrastructure, such as: -In this section of the lab we'll see how to package our DynamoDB table as a Crossplane Composition for easier consumption by development teams. +- Ensuring all AWS resources have certain tags +- Applying specific encryption keys to all Amazon Simple Storage Service (S3) buckets +- Standardizing resource configurations across the organization + +With Compositions, platform teams can define self-service API abstractions that guarantee all resources created through these templates meet the organization's requirements. This approach simplifies resource management and ensures consistency across deployments. + +In this section of the lab, we'll explore how to package our Amazon DynamoDB table as a Crossplane Composition. This will demonstrate how to create a more easily consumable resource for development teams, while maintaining control over the underlying configuration. + +By leveraging Compositions, we'll see how to: + +1. Define a standardized template for DynamoDB tables +2. Simplify the resource creation process for developers +3. Ensure compliance with organizational policies and best practices + +Through this exercise, you'll gain hands-on experience with Crossplane Compositions and understand their benefits in managing cloud resources within a Kubernetes environment. diff --git a/website/docs/automation/controlplanes/crossplane/compositions/testing.md b/website/docs/automation/controlplanes/crossplane/compositions/testing.md index e576a5721..6ebb1c7f5 100644 --- a/website/docs/automation/controlplanes/crossplane/compositions/testing.md +++ b/website/docs/automation/controlplanes/crossplane/compositions/testing.md @@ -3,7 +3,9 @@ title: "Testing the application" sidebar_position: 40 --- -We've already configured the workload to use the correct table name in the previous section so lets just restart the pods: +Now that we've provisioned our DynamoDB table using Crossplane Compositions, let's test the application to ensure it's working correctly with the new table. + +First, we need to restart the pods to ensure they're using the updated configuration: ```bash $ kubectl rollout restart -n carts deployment/carts @@ -11,7 +13,7 @@ $ kubectl rollout status -n carts deployment/carts --timeout=2m deployment "carts" successfully rolled out ``` -The load balancer used to access the application will be the same as the last section: +To access the application, we'll use the same load balancer as in the previous section. Let's retrieve its hostname: ```bash $ LB_HOSTNAME=$(kubectl -n ui get service ui-nlb -o jsonpath='{.status.loadBalancer.ingress[*].hostname}{"\n"}') @@ -19,20 +21,25 @@ $ echo "http://$LB_HOSTNAME" http://k8s-ui-uinlb-647e781087-6717c5049aa96bd9.elb.us-west-2.amazonaws.com ``` -Access it by pasting the URL in your web browser. You will see the UI from the web store displayed and will be able to navigate around the site as a user. +You can now access the application by copying this URL into your web browser. You'll see the web store's user interface, allowing you to navigate the site as a user would. -To verify that the **Carts** module is in fact using the DynamoDB table we just provisioned, try adding a few items to the cart. +To verify that the **Carts** module is indeed using the newly provisioned DynamoDB table, follow these steps: + +1. Add a few items to your cart in the web interface. +2. Observe that the items appear in your cart, as shown in the screenshot below: -![Cart screenshot](../assets/cart-items-present.webp) +![Cart screenshot showing added items](../assets/cart-items-present.webp) -And to check if items are in the DynamoDB table as well, run: +To confirm that these items are being stored in the DynamoDB table, run the following command: ```bash $ aws dynamodb scan --table-name "${EKS_CLUSTER_NAME}-carts-crossplane" ``` -We've now successfully created AWS resources using Crossplane Compositions! +This command will display the contents of the DynamoDB table, which should include the items you've added to your cart. + +Congratulations! You've successfully created AWS resources using Crossplane Compositions and verified that your application is working correctly with these resources. This demonstrates the power of using Crossplane to manage cloud resources directly from your Kubernetes cluster. diff --git a/website/docs/automation/controlplanes/crossplane/configure-application.md b/website/docs/automation/controlplanes/crossplane/configure-application.md index 8d11d7983..d8088b852 100644 --- a/website/docs/automation/controlplanes/crossplane/configure-application.md +++ b/website/docs/automation/controlplanes/crossplane/configure-application.md @@ -3,30 +3,30 @@ title: "Updating the application" sidebar_position: 25 --- -When new resources are created or updated, application configurations also need to be updated to use these new resources. Environment variables are a popular choice for application developers to store configuration, and in Kubernetes we can pass environment variables to containers through the `env` field of the `container` [spec](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) when creating deployments. +When new resources are created or updated, application configurations often need to be adjusted to utilize these new resources. Environment variables are a popular choice for application developers to store configuration, and in Kubernetes, we can pass environment variables to containers through the `env` field of the `container` [spec](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) when creating deployments. -Now, there are two ways to achieve this. +There are two primary ways to achieve this in Kubernetes: -- First, Configmaps. Configmaps are a core resource in Kubernetes that allow us to pass configuration elements such as Environment variables, text fields and other items in a key-value format to be used in pod specs. -- Then, we have secrets (which are not encrypted by design - this is important to remember) to push things like passwords/secrets. +1. **ConfigMaps**: These are core resources in Kubernetes that allow us to pass configuration elements such as environment variables, text fields, and other items in a key-value format to be used in pod specs. +2. **Secrets**: While not encrypted by default (which is important to remember), secrets are used to store sensitive information like passwords. -However, in this lab we'll just directly update the ConfigMap for the carts component, removing the configuration that points it to the local DynamoDB and using the name of the DynamoDB table created by Crossplane: +For this lab, we'll focus on updating the ConfigMap for the carts component. We'll remove the configuration that points it to the local DynamoDB and instead use the name of the DynamoDB table created by Crossplane: ```kustomization modules/automation/controlplanes/crossplane/app/kustomization.yaml ConfigMap/carts ``` -We will also have to provide the carts Pods with the appropriate IAM permissions to access the DynamoDB service. An IAM role has already been created, and we'll apply this to the carts Pods with IAM Roles for Service Accounts: +Additionally, we need to provide the carts Pods with the appropriate IAM permissions to access the DynamoDB service. An IAM role has already been created, and we'll apply this to the carts Pods using IAM Roles for Service Accounts (IRSA): ```kustomization modules/automation/controlplanes/crossplane/app/carts-serviceAccount.yaml ServiceAccount/carts ``` -To learn more about how IRSA works, see [here](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). +To learn more about how IRSA works, refer to the [official documentation](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). -Apply this new configuration: +Let's apply this new configuration: ```bash $ kubectl kustomize ~/environment/eks-workshop/modules/automation/controlplanes/crossplane/app \ @@ -38,14 +38,12 @@ Now we need to recycle all the carts Pods to pick up our new ConfigMap contents: ```bash $ kubectl rollout restart -n carts deployment/carts deployment.apps/carts restarted -$ kubectl rollout status -n carts deployment/carts --timeout=20s +$ kubectl rollout status -n carts deployment/carts --timeout=40s Waiting for deployment "carts" rollout to finish: 1 old replicas are pending termination... deployment "carts" successfully rolled out ``` -How do we know that the application is working with the new DynamoDB table? - -An NLB has been created to expose the sample application for testing, allowing us to directly interact with the application through the browser: +To verify that the application is working with the new DynamoDB table, we can use the Network Load Balancer (NLB) that has been created to expose the sample application for testing. This allows us to directly interact with the application through a web browser: ```bash $ LB_HOSTNAME=$(kubectl -n ui get service ui-nlb -o jsonpath='{.status.loadBalancer.ingress[*].hostname}{"\n"}') @@ -54,29 +52,29 @@ http://k8s-ui-uinlb-647e781087-6717c5049aa96bd9.elb.us-west-2.amazonaws.com ``` :::info -Please note that the actual endpoint will be different when you run this command as a new Network Load Balancer endpoint will be provisioned. +Please note that the actual endpoint will be different when you run this command, as a new Network Load Balancer endpoint will be provisioned. ::: -To wait until the load balancer has finished provisioning you can run this command: +To wait until the load balancer has finished provisioning, you can run this command: ```bash timeout=610 $ wait-for-lb $(kubectl get service -n ui ui-nlb -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}") ``` -Once the load balancer is provisioned you can access it by pasting the URL in your web browser. You will see the UI from the web store displayed and will be able to navigate around the site as a user. +Once the load balancer is provisioned, you can access it by pasting the URL in your web browser. You will see the UI from the web store displayed and will be able to navigate around the site as a user. -To verify that the **Carts** module is in fact using the DynamoDB table we just provisioned, try adding a few items to the cart. +To verify that the **Carts** module is indeed using the DynamoDB table we just provisioned, try adding a few items to the cart. ![Cart screenshot](./assets/cart-items-present.webp) -And to check if items are in the DynamoDB table as well, run: +To check if items are present in the DynamoDB table as well, run: ```bash $ aws dynamodb scan --table-name "${EKS_CLUSTER_NAME}-carts-crossplane" ``` -Congratulations! You've successfully created AWS Resources without leaving the confines of the Kubernetes API! +Congratulations! You've successfully created and utilized AWS resources without leaving the confines of the Kubernetes API! diff --git a/website/docs/automation/controlplanes/crossplane/how-it-works.md b/website/docs/automation/controlplanes/crossplane/how-it-works.md index 135db3b4f..98fe34d46 100644 --- a/website/docs/automation/controlplanes/crossplane/how-it-works.md +++ b/website/docs/automation/controlplanes/crossplane/how-it-works.md @@ -3,12 +3,12 @@ title: "How it works" sidebar_position: 5 --- -Running Crossplane in a cluster consists of two main parts: +Crossplane operates within a cluster using two primary components: -1. The Crossplane controller which provides the core components -2. One or more Crossplane providers which each provide a controller and Custom Resource Definitions to integrate with a particular provider, such as AWS +1. The Crossplane controller, which provides the core functionality +2. One or more Crossplane providers, each offering a controller and Custom Resource Definitions to integrate with a specific provider, such as AWS -The Crossplane controller, Upbound AWS provider and have been pre-installed in our EKS cluster, each running as a deployment in the `crossplane-system` namespace along with the `crossplane-rbac-manager`: +In our EKS cluster, we've pre-installed the Crossplane controller, the Upbound AWS provider, and the necessary components. These run as deployments in the `crossplane-system` namespace, alongside the `crossplane-rbac-manager`: ```bash $ kubectl get deployment -n crossplane-system @@ -19,8 +19,10 @@ upbound-aws-provider-dynamodb-23a48a51e223 1/1 1 1 3h upbound-provider-family-aws-1ac09674120f 1/1 1 1 21h ``` -Here, `upbound-provider-family-aws` represents Crossplane provider for Amazon Web Services (AWS) developed and supported by Upbound. `upbound-aws-provider-dynamodb` is a subset of the prior dedicated to deploy DynamoDB via Crossplane. +Here, `upbound-provider-family-aws` represents the Crossplane provider for Amazon Web Services (AWS), developed and supported by Upbound. The `upbound-aws-provider-dynamodb` is a subset dedicated to deploying DynamoDB via Crossplane. -Crossplane provides a simplified interface for developers to request infrastructure resources via Kubernetes manifests called claims. As shown in this diagram, claims are the only namespace-scoped Crossplane resources, serving as the developer interface and abstracting away implementation details. When a claim is deployed to the cluster, it creates a Composite Resource (XR), a Kubernetes custom resource representing one or more cloud resources defined through templates called Compositions. The Composite Resource creates one or more Managed Resources which interact with the AWS API to request the creation of the desired infrastructure resources. +Crossplane simplifies the process for developers to request infrastructure resources using Kubernetes manifests called claims. As illustrated in the diagram below, claims are the only namespace-scoped Crossplane resources, serving as the developer interface and abstracting implementation details. When a claim is deployed to the cluster, it creates a Composite Resource (XR), a Kubernetes custom resource representing one or more cloud resources defined through templates called Compositions. The Composite Resource then creates one or more Managed Resources, which interact with the AWS API to request the creation of the desired infrastructure resources. ![Crossplane claim](./assets/claim-architecture-drawing.webp) + +This architecture allows for a clear separation of concerns between developers, who work with high-level abstractions (claims), and platform teams, who define the underlying infrastructure implementations (Compositions and Managed Resources). diff --git a/website/docs/automation/controlplanes/crossplane/index.md b/website/docs/automation/controlplanes/crossplane/index.md index b66982566..1a6f3be32 100644 --- a/website/docs/automation/controlplanes/crossplane/index.md +++ b/website/docs/automation/controlplanes/crossplane/index.md @@ -22,7 +22,17 @@ You can view the Terraform that applies these changes [here](https://github.com/ ::: -[Crossplane](https://crossplane.io/) is an open source project in the CNCF that transforms your Kubernetes cluster into a universal control plane. Crossplane enables platform teams to assemble infrastructure from multiple vendors, and expose higher level self-service APIs for application teams to consume, without having to write any code. -Crossplane extends your Kubernetes cluster to support orchestrating any infrastructure or managed service. Compose Crossplane’s granular resources into higher level abstractions that can be versioned, managed, deployed and consumed using your favorite tools and existing processes. +[Crossplane](https://crossplane.io/) is an open-source project in the Cloud Native Computing Foundation (CNCF) that transforms your Kubernetes cluster into a universal control plane. It enables platform teams to assemble infrastructure from multiple vendors and expose higher-level self-service APIs for application teams to consume, without writing any code. + +Crossplane extends your Kubernetes cluster to support orchestrating any infrastructure or managed service. It allows you to compose Crossplane's granular resources into higher-level abstractions that can be versioned, managed, deployed, and consumed using your favorite tools and existing processes. ![EKS with Dynamodb](./assets/eks-workshop-crossplane.webp) + +With Crossplane, you can: + +1. Provision and manage cloud infrastructure directly from your Kubernetes cluster +2. Define custom resources that represent complex infrastructure setups +3. Create abstraction layers that simplify infrastructure management for application developers +4. Implement consistent policies and governance across multiple cloud providers + +In this module, we'll explore how to use Crossplane to manage AWS resources, specifically focusing on provisioning and configuring a DynamoDB table for our sample application. diff --git a/website/docs/automation/controlplanes/crossplane/resources.md b/website/docs/automation/controlplanes/crossplane/resources.md index 2e2c43465..adae4b0d8 100644 --- a/website/docs/automation/controlplanes/crossplane/resources.md +++ b/website/docs/automation/controlplanes/crossplane/resources.md @@ -3,17 +3,17 @@ title: "Managed Resources" sidebar_position: 20 --- -By default the **Carts** component in the sample application uses a DynamoDB local instance running as a pod in the EKS cluster called `carts-dynamodb`. In this section of the lab, we'll provision an Amazon DynamoDB cloud based table for our application using Crossplane managed resources and point the **Carts** deployment to use the newly provisioned DynamoDB table instead of the local copy. +By default, the **Carts** component in the sample application uses a DynamoDB local instance running as a pod in the EKS cluster called `carts-dynamodb`. In this section of the lab, we'll provision an Amazon DynamoDB cloud-based table for our application using Crossplane managed resources and configure the **Carts** deployment to use the newly provisioned DynamoDB table instead of the local copy. ![Crossplane reconciler concept](./assets/Crossplane-desired-current-ddb.webp) -Now, let's explore how we'll create the DynamoDB table via a Crossplane managed resource manifest: +Let's explore how we'll create the DynamoDB table via a Crossplane managed resource manifest: ```file manifests/modules/automation/controlplanes/crossplane/managed/table.yaml ``` -Finally, we can create the configuration for the DynamoDB itself with a `dynamodb.aws.upbound.io` resource. +Now, we can create the configuration for the DynamoDB table using a `dynamodb.aws.upbound.io` resource. ```bash wait=10 timeout=400 hook=table $ kubectl kustomize ~/environment/eks-workshop/modules/automation/controlplanes/crossplane/managed \ @@ -23,10 +23,12 @@ $ kubectl wait tables.dynamodb.aws.upbound.io ${EKS_CLUSTER_NAME}-carts-crosspla --for=condition=Ready --timeout=5m ``` -It takes some time to provision the AWS managed services, in the case of DynamoDB up to 2 minutes. Crossplane will report the status of the reconciliation in the `status` field of the Kubernetes custom resources. +It takes some time to provision AWS managed services, in the case of DynamoDB up to 2 minutes. Crossplane will report the status of the reconciliation in the `status` field of the Kubernetes custom resources. ```bash $ kubectl get tables.dynamodb.aws.upbound.io NAME READY SYNCED EXTERNAL-NAME AGE eks-workshop-carts-crossplane True True eks-workshop-carts-crossplane 6s ``` + +With this configuration applied, Crossplane will create a DynamoDB table in AWS, which can then be used by our application. In the next section, we'll update the application to use this newly created table.