Forem: Javier Sepúlveda

Using KIRO and AMDF MCP to Build Reusable Kubernetes KRO Packages

Javier Sepúlveda — Sat, 14 Mar 2026 21:16:19 +0000

Continuing our journey with KCL, in this post we will explore how to accelerate the creation of reusable Kubernetes packages from CRDs using KIRO and the AMDF MCP tool.

Kiro + AMDF MCP elevate a process that traditionally requires long times in a conversation of minutes, where the developer simply indicates what resources are needed.

Additionally, by using KCL instead of traditional YAML, KCL provides strong typing, validation at development time, and abstraction capabilities that transform repetitive configurations into reusable and maintainable code. The result is infrastructure as data that is not only generated quickly, but is also robust, validated, and ready.

Prerequisites

Kubernetes cluster
CRDS in Kubernetes Cluster, for this demo ACK, KRO and External Secrets Operator
AMDF
KIRO
KCL

Step 1.

Validate your CRDS.
In this case the cluster have CRDS from ESO and ACK EC2-RDS Controllers.

Step 2.

Connect MCP.
With AMDF installed is so simple like as execute

amdf mcp-server 
Starting AMDF MCP Server...

Step 3.

With the MCP Server running, open KIRO for start to create reusable packages using a basic prompt.

Kiro, I need to create a ResourceGraphDefinition CRD KCL schema for generate an abstraction of multiple resources.

Step 4.

With the prompt running, the AMDF MCP tools start to working.

Step 5.

AMDF Automatically create this directorys using KCL sintax.

Step 6.

For this demo, I migrated a code from crossplane to KRO, using
helper functions and CEL expretions required for KRO.

Check the code in this repository

segoja7 / mcp-kcl-infra-accelerator

Kubernetes packages using KRO, KCL, and MCP (KIRO + AMDF).

Keycloak Stack

A reusable Keycloak deployment abstraction built with KRO and KCL. It provisions Keycloak and its database backend — either a local PostgreSQL instance or AWS RDS — from a single Kubernetes custom resource.

Architecture

Description

This example demonstrates how to use KCL to define a KRO ResourceGraphDefinition that generates a KeycloakStack CRD. Applying a KeycloakStack instance creates all the necessary Kubernetes resources for a fully functional Keycloak deployment.

The stack supports two deployment modes controlled by the localTest flag:

Local mode (localTest: true) — Deploys an in-cluster PostgreSQL Deployment, Service, and Secret. Ideal for development and testing.
AWS RDS mode (localTest: false) — Provisions an AWS RDS DBInstance with optional subnet group and security group, and connects Keycloak via an ExternalName Service. Supports three password management strategies.

Project Structure


├── KRO-KEYCLOAK-1.drawio.png          # Architecture diagram
├── kcl_render/
│   └── KeycloakStack.yaml             # Rendered YAML output

…

View on GitHub

Step 7.

Check the Main.k
New to KCL? Don't worry! The syntax is designed to be developer-friendly. You can find a complete introduction in my previous blog

Is time for test that code is correctly and compile.

Step 8.

Test that new KCL package using AMDF, KIRO and RDS, EC2 ACK and External Secrets Controllers are working correctly.

kcl library/main.k | kubectl apply -f -
resourcegraphdefinition.kro.run/keycloak-stack created

Here's an RGD that creates a new KeycloakStack API. When users create an KeycloakStack, kro automatically creates multiples resources defined in the Resource Graph Definition

For now, this is a local test, but let me show you how to bring this to GitOps and integrate it with OCI registries and using the KCL plugin for deployment in the next blog.

Step 9.

check the 02-aws-rds-deploy.yaml.

apiVersion: kro.run/v1alpha1
kind: KeycloakStack
metadata:
  name: keycloak-dev
  namespace: default
spec:
  projectName: "dev"
  environment: "dev"
  keycloakMode: "start-dev"
  keycloakReplicas: 1
  kcProxy: ""  # Sin proxy para port-forward  
  keycloakImage: "quay.io/keycloak/keycloak:latest"
  keycloakAdminUser: "admin"
  keycloakHostname: "keycloakrds.local"
  postgresImage: "postgres:17"
  postgresPassword: ""
  localTest: false
  rdsInstanceClass: "db.t3.micro"
  rdsAllocatedStorage: 20
  rdsEngineVersion: "17"
  rdsDBName: "keycloak"
  rdsUsername: "keycloak"
  rdsManageMasterUserPassword: true 
  rdsSubnetIDs:
    - "subnet-0436a5657992422d2"  # us-east-1a - CAMBIAR
    - "subnet-03fc372cafad1feec"  # us-east-1b - CAMBIAR
  rdsVPCID: "vpc-0d7e4425ca4d23f89"  # CAMBIAR
  rdsAllowedCIDRs:
    - "10.0.0.0/16"  # CIDR de tu VPC

Apply the KeycloakStack yaml resource for deploy and test.

kubectl apply -f sample/02-aws-rds-deploy.yaml 
keycloakstack.kro.run/keycloak-dev created

Step 10.

Validate that resources are ready.

kubectl get keycloakstack,dbsubnetgroups,securitygroups,dbinstances,secretstore,externalsecret,secrets,svc,deployments,pods,ingress -n default

NAME                                 STATE    READY   AGE
keycloakstack.kro.run/keycloak-dev   ACTIVE   True    11m

NAME                                                           AGE
dbsubnetgroup.rds.services.k8s.aws/keycloak-subnet-group-dev   11m

NAME                                                     ID
securitygroup.ec2.services.k8s.aws/keycloak-rds-sg-dev   sg-0bae8ee9ebb07ac3b
securitygroup.ec2.services.k8s.aws/my-webserver-sg       sg-06db013ac4841cf58

NAME                                               STATUS
dbinstance.rds.services.k8s.aws/keycloak-rds-dev   available

NAME                                                  AGE   STATUS   CAPABILITIES   READY
secretstore.external-secrets.io/aws-secretstore-dev   11m   Valid    ReadWrite      True

NAME                                                       STORETYPE     STORE                 REFRESH INTERVAL   STATUS         READY
externalsecret.external-secrets.io/rds-password-sync-dev   SecretStore   aws-secretstore-dev   1h                 SecretSynced   True

NAME                             TYPE     DATA   AGE
secret/aws-credentials           Opaque   4      2m6s
secret/rds-connection-dev        Opaque   4      7m15s
secret/rds-password-synced-dev   Opaque   2      11m

NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP                                                 PORT(S)    AGE
service/keycloak-service-dev   ClusterIP      10.102.50.198   <none>                                                      8080/TCP   11m
service/kubernetes             ClusterIP      10.96.0.1       <none>                                                      443/TCP    4d3h
service/postgres-service       ExternalName   <none>          keycloak-rds-dev.ckxssqysgxjv.us-east-1.rds.amazonaws.com   5432/TCP   7m15s

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/keycloak-dev   0/1     1            0           11m

NAME                                READY   STATUS    RESTARTS   AGE
pod/keycloak-dev-6fc5c4bdd9-kgkzf   1/1     Running   0          8m4s

Create a port forward and use keycloakHostname value, in this case "keycloakrds.local".

For connect con admin, the password is in the secret (rds-password-synced-dev).

CONCLUSION:

The combination of AMDF and KIRO acts as a force multiplier, allowing us to build robust, validated, and reusable OCI packages or in this case Yaml manifests from existing CRDs faster.

Using KCL instead of traditional YAML isn't just a syntax preference—it’s about building a safer, more modular, and maintainable for our Cloud Native ecosystem.

KCL For Managing Infraestructure as Data

Javier Sepúlveda — Wed, 03 Dec 2025 23:01:02 +0000

In the previous blog it's mentioned some benefits about of IaD and how this concept this wide used in cloud native, let me write in this post about KCL for create anything declarative manifest.

KCL

KCL is an open source configuration and policy language, currently a Cloud Native Computing Foundation (CNCF) Sandbox project.

It was created to overcome the limitations of static formats like YAML or JSON, especially in complex cloud-native environments. To achieve this, KCL combines the simplicity of a data language with the power of a modern programming language, allowing you to create abstractions, enforce validations through a constraint system, and automate large-scale data management.

In short, you write in KCL to generate configurations for tools like Kubernetes and any tools that use yaml in a much safer, more scalable, and programmable way.

Think in KCL like as high level language with a DevEx similar a Pyhton.

There is a fundamental concepts that I will omit, but if you have experience with other programing languages, you don't have problems with KCL foundations.

If could be validate this concepts in this official link

KCL Schemas

Basic Schema

schema is a blueprint that defines the structure of your configuration. It tells KCL exactly what attributes an object should have, what type they are, and what their default values are.

Key points**
Attribute Definition: Within a schema, each attribute must have a type (name: str, replica: int).

Optional attributes (?) : If an attribute may not be present, you add a ? to its name (labels?: {str:str}). If you don't add, the attribute is mandatory.

Default values (=): You can assign a default value to any attribute (replica: int = 1). If you do not specify a value when creating an instance, this value will be used.

Create an Instance: You use the schema name followed by braces {} to create a concrete configuration from the blueprint.

1. Schemas and Data Types

The fundamental unit in KCL is the schema, which acts as a blueprint or template for your configuration. Within a schema, you define attributes with specific data types (str, bool, int) and can assign default values.

Example: Basic application configuration.

schema eksCluster:
    clusterName: str
    encryptCluster: bool = True

# It's not necessary to specify 'EncryptCluster' if its default value is desired.
eksCluster {
    clusterName = "segoja7-cluster"
}

Resulting YAML:

clusterName: segoja7-cluster
encryptCluster: true

2. Nested Schemas: Creating Structure

To handle more complex configurations, a schema can use another schema as the type for one of its attributes. This creates a nested and organized structure, mirroring the hierarchy of the final YAML.

Example: Adding a Node section.

schema nodeCluster:
    diskSize : int
    ami: str


schema eksCluster:
    clusterName: str
    encryptCluster: bool = True
    nodeConfig: nodeCluster  # <-- Attribute whose type is another schema

eksCluster {
    clusterName = "segoja7-cluster"
    nodeConfig.diskSize = 20
    nodeConfig.ami = "BOTTLEROCKET_x86_64"
}

Resulting YAML:

clusterName: segoja7-cluster
encryptCluster: true
nodeConfig:
  diskSize: 20
  ami: BOTTLEROCKET_x86_64

3. Lists of Schemas: Handling Collections

To define a list of complex objects, you use bracket syntax [] with the schema name (e.g., [MySchema]). This ensures that every element in the list conforms to the structure defined in the schema.

Example: Adding a list of Tags.

schema nodeCluster:
    diskSize : int
    ami: str

schema tags:
    key: str
    value: str 

schema eksCluster:
    clusterName: str
    encryptCluster: bool = True
    nodeConfig: nodeCluster  
    tags: [tags] # <-- Attribute whose type is a LIST of another 


eksCluster {
    clusterName = "segoja7-cluster"
    nodeConfig.diskSize = 20
    nodeConfig.ami = "BOTTLEROCKET_x86_64"
    tags = [
        { key = "Name", value = "NodeGroup" },
    ]
}

Resulting YAML:

clusterName: segoja7-cluster
encryptCluster: true
nodeConfig:
  diskSize: 20
  ami: BOTTLEROCKET_x86_64
tags:
- key: Name
  value: NodeGroup

4. Schemas (Logic and Validation)

This is where schemas become really powerful. They are not only data containers, they can also contain logic and validation rules.

Schema arguments (schema MySchema[argument]: ) You can pass parameters to a schema that are not final attributes, but are used for internal logic.

The check block: This block is the "quality inspector" of your schema. Inside it, you write a series of rules (asserts) that each schema instance must comply with. If any rule fails, KCL will stop the compilation with an error. This is much cleaner than having loose asserts in the file.

schema nodeCluster:
    diskSize : int
    ami: str

schema tags:
    key: str
    value: str 

schema eksCluster[env: str]:
    clusterName: str
    encryptCluster: bool = False
    nodeConfig: nodeCluster  
    tags: [tags]
    check:
        encryptCluster != False if env == "prod", "Production cluster need to be encrypt"


eksCluster(env="prod") {
    clusterName = "segoja7-cluster"
    nodeConfig.diskSize = 20
    nodeConfig.ami = "BOTTLEROCKET_x86_64"
    tags = [
        { key = "Name", value = "NodeGroup" },
    ]
}

Output with encryptCluster = false and check using production env argument:

kcl run main.k 
EvaluationError
  --> /main.k:18:1
   |
18 | eksCluster(env="prod") {
   | ^ Instance check failed
   |

  --> /main.k:15:1
   |
15 |         encryptCluster != False if env == "prod", "Production cluster need to be encrypt"
   |  Check failed on the condition: Production cluster need to be encrypt
   |

Output with encryptCluster = true and check using production env argument:

clusterName: segoja7-cluster
encryptCluster: true
nodeConfig:
  diskSize: 20
  ami: BOTTLEROCKET_x86_64
tags:
- key: Name
  value: NodeGroup

Inheritance, protocol and Mixins The Core Concepts: When to Use Each.

The key is to identify the relationship between your schemas.

Inheritance: Use inheritance when one schema is a more specialized version of another. It creates a clear parent-child hierarchy.

protocol/Mixin: Use a protocol/mixin when you want to add a reusable packet of features to different, unrelated schemas.

Protocol: Is a contract that defines a set of attributes that a schema must have in order to use a specific functionality.
mixin: A mixin is a block of code containing attributes and logic that can be "mixed" or injected into a schema.
The data flow is always: ➡️ Esquema ➡️ Mixin ➡️ Protocol.

Example: Inheritance, protocol and Mixins.

schema nodeCluster:
    diskSize : int
    ami: str

schema tags:
    key: str
    value: str 

schema eksCluster[env: str]:
    clusterName: str
    encryptCluster: bool = True
    nodeConfig: nodeCluster  
    tags: [tags]
    monitoring_logs?: [str] = []
    check:
        encryptCluster != False if env == "prod", "Production cluster need to be encrypt"

protocol monitoringProtocol: # <-- Protocol: contract for mixin with optional field enabledLogs
    enabledLogs?: bool

mixin monitoringMixin for monitoringProtocol: # <-- Mixin: adds monitoring monitoring_logs if enabledLogs is provided  
    if enabledLogs:
        monitoring_logs = [
            "api",
            "audit",
            "authenticator",
            "controllerManager",
            "scheduler",
        ]

schema eksClusterWithMonitoring[env: str](eksCluster): # <-- Inheritance
    mixin [monitoringMixin]
    enabledLogs: bool 

prod = eksClusterWithMonitoring(env="prod") { #Prod with logs
    clusterName = "segoja7-cluster"
    nodeConfig.diskSize = 20
    nodeConfig.ami = "BOTTLEROCKET_x86_64"
    tags = [
        { key = "Name", value = "NodeGroup" },
    ]
    enabledLogs = True
}

dev = eksCluster(env="dev"){ #Dev without logs
    clusterName = "segoja7-cluster"
    encryptCluster = False
    nodeConfig.diskSize = 20
    nodeConfig.ami = "BOTTLEROCKET_x86_64"
    tags = [
        { key = "Name", value = "NodeGroup" },
    ]   
}

Final Resulting YAML:

prod:
  clusterName: segoja7-cluster
  encryptCluster: true
  nodeConfig:
    diskSize: 20
    ami: BOTTLEROCKET_x86_64
  tags:
  - key: Name
    value: NodeGroup
  monitoring_logs:
  - api
  - audit
  - authenticator
  - controllerManager
  - scheduler
  enabledLogs: true
dev:
  clusterName: segoja7-cluster
  encryptCluster: false
  nodeConfig:
    diskSize: 20
    ami: BOTTLEROCKET_x86_64
  tags:
  - key: Name
    value: NodeGroup
  monitoring_logs: []

CONCLUSION:

KCl is a language with features like as another high level programing language with a DevEx similar to Python, KCL create declarative manifests that all tools from cloud-native systems understand. With KCL we can introduce abstraction, early validation and modularity enabling platform teams to scale their operations safely and efficiently.

Fast Overview for Infraestructure as Data

Javier Sepúlveda — Fri, 07 Nov 2025 17:52:41 +0000

Infrastructure as Data (IaD)

Infrastructure as Data (IaD) is basically about defining your infrastructure using structured data files—stuff like YAML or JSON—instead of traditional scripts or config languages that mix in programming logic. No code, just data.

Think of it as an evolution or a tighter subset of "Infrastructure as Code" (IaC). While IaC encompasses any method for managing infrastructure through code, IaD focuses on a purely declarative model.

In another words you declare the desire state of your declarative manifests then let automation systems work. They’ll constantly check and enforce that what’s running matches what you described.

IaD was created to solve this problem through its main mechanism: the reconciliation loop.

The Reconciliation Loop

IaD is primarily implemented in the Kubernetes ecosystem, using its API as a universal control plane.

Definition as Data: You define a cloud resource (a database, a bucket, a network) in a YAML file, as if it were a Kubernetes object.
Active Controllers: Tools such as Crossplane, Config Connector (GCP) or ACK (AWS) install "Controllers" in your cluster.
Continuous Reconciliation: These drivers constantly observe two things: the desired state (your YAML file) and the actual state (in the cloud). If they detect a difference, they automatically take action to bring reality back to match the definition. This loop is perpetual.

This model ensures that any manual changes are reverted, keeping the infrastructure in sync with your Git statement at all times.

Problem Solving: The Limitations of IaC (configuration drift).

Example: If a Engineer make a change of a resource directly in the console for any reason, IaC tools doesn't have the capacity for detect that change, this require an manual execution.

Key Benefits of IaD

Infrastructure as Data (IaD) marks a advancement in how we manage infrastructure, particularly when compared to traditional Infrastructure as Code (IaC) methods. In cloud-native and GitOps contexts, the impact of IaD becomes even more apparent.

Elimination of Configuration Drift: IaD ensures that the actual state of the infrastructure always matches the definition in Git.
Desired states: By leaving out logic, no loops or conditionals in the definition files and focusing only on data, the deployment process becomes much more transparent.
Cognitive Load Reduction: The learning curve and cognitive load for teams already running Kubernetes is reduced, pure YAML/JSON files are inherently easier to read and write.
Permissions Model: Developers or application teams can "request" (claim) standardized infrastructure (ej. "Database") without having direct credentials in the cloud.
Centralization of Security: Platform teams can encapsulate security, compliance and governance best practices within the abstract resource definitions, ensuring that all provisioned infrastructure complies with the organization's policies.
Traceability: All definitions are in Git and changes are applied through an automated system, you get a complete and clear audit trail of all infrastructure changes.
Automation: It aligns perfectly with the GitOps methodology, where any infrastructure change is initiated with a git push, which automates the entire lifecycle.
Modularity and Reusability: It can be created and destroyed with complete confidence and reproducibility,

IaD Tools

This a ecosystem of Infrastructure as Data (IaD) tools that complement each other to leverage this philosophy to the maximum.

The key is that these tools focus on defining resources as declarative data and/or use a reconciliation loop to maintain state.

1. Infrastructure Abstraction and Control Plane (IaD Core)

Crossplane Agnostic any cloud provider.

2. Continuous Delivery (GitOps) for IaD

3. Configuration and Customization Management (IaD Support)

4. Policy and Governance (IaD Policy)

5. Others tools and will continue ...

CONCLUSION

IaD is not just a different way of writing infrastructure, it is a philosophy that boosts reliability, security and agility in cloud infrastructure management by leveraging declarative principles and control loops to maintain the desired state in a continuous and automated manner.

Hands-on Lab #1: Creating Crossplane v1.20 Configuration Packages for Keycloak on AWS

Javier Sepúlveda — Wed, 09 Jul 2025 20:37:05 +0000

What are Crossplane Configuration Packages?

Crossplane Configuration Packages are the high level of infrastructure reusability in the Crossplane ecosystem. Think of Crossplane Configuration Packages like Docker images for infrastructure. The configurations allow generated distributable packages that can be deployed consistently any environments.

So, for create configurations package is necessary create compositions and compositions resource definitions (xrd), if you have any doubts about these concepts, check this blog.

Javier Sepúlveda

Nov 19 '24

KCL Function+ Crossplane: A Declarative Language for Deploying Complex Infrastructure on AWS with Kubernetes.

#kubernetes #aws #crossplane #iac

Comments

5 min read

Requirements for local test

Kubernetes cluster (Minikube)
Helm version v3.13.1 or later
Crossplane
programmatic access AWS
Crossplane CLI

Link Repositoy

segoja7 / configuration-crossplane-keycloak

This a repository for crossplane configuration package keycloak in AWS

Project Overview

This is a Crossplane-based infrastructure-as-code project that deploys a comprehensive AWS EKS cluster with associated infrastructure using KCL. The project creates a multi-AZ infrastructure including VPC, subnets, EKS cluster, RDS database, and various controllers.

Architecture

Core Components

Crossplane Configuration: Manages AWS infrastructure through Crossplane providers
KCL Functions: KCL for infrastructure composition
AWS Resources: Creates VPC, EKS cluster, RDS, security groups, IAM roles, and networking components
Helm Charts: Deploys cert-manager, AWS Load Balancer Controller, ingress-nginx, and external-dns
Kubernetes Objetcs: Deploys objects of kubernets such as Deployments, services, ingress and others

Key Files

resources/compositions/infra/composition.k: Main KCL composition defining all AWS resources
resources/compositions/infra/crd.k: Custom Resource Definition for the infrastructure
resources/examples/claim.yaml: Example claim to provision infrastructure
configuration/crossplane.yaml: Crossplane configuration metadata
configuration/apis/infra/composition.yaml: Render from resources/compositions/infra/composition.k > any change is overwrite
configuration/apis/infra/crd.yaml: Render from resources/compositions/infra/crd.k
function.yaml: Crossplane functions (KCL and auto-ready)
provider.yaml…

View on GitHub

Key Files

resources/compositions/infra/composition.k: Main KCL composition defining all AWS resources
resources/compositions/infra/crd.k: Custom Resource Definition for the infrastructure
resources/examples/claim.yaml: Example claim to provision infrastructure
configuration/crossplane.yaml: Crossplane configuration metadata
configuration/apis/infra/composition.yaml: Render from resources/compositions/infra/composition.k
configuration/apis/infra/crd.yaml: Render from resources/compositions/infra/crd.k
function.yaml: Crossplane functions (KCL and auto-ready)
install-configuration.yaml: Crossplane configuration metadata for install configuration package in the cluster.
provider.yaml: AWS, Kubernetes and helm providers
providerconfig.yaml: Provider configuration

Architecture.

Step 1.

First, create a profile in minikube

minikube start -p crossplane

With minikube running is moment for install Helm and crossplane, check this link.

with the profile of minikube created and helm and crossplane running it is needed to create a txt file, for this case the document name is profile.txt

[default]
aws_access_key_id = <Your access key id>
aws_secret_access_key = <Your secret access key>

when the txt file is created it is necessary created a generic secret.

kubectl create secret generic aws-secret -n crossplane-system --from-file=creds=./profile.txt

Step 2.

Install functions.

The configuration have dependencies from this functions.

kubectl apply -f function.yaml

Step 3.

Installing a provider, in this case providers for aws, kubernetes and helm from community.

kubectl apply -f provider.yaml

Step 4.

Install providersconfig, it is using the key from secret with the name creds.

kubectl apply -f providerconfig.yaml

Step 5.

echo "<github token>" | docker login ghcr.io -u <user> --password-stdin

Step 6.

Create Gihub Secret in the cluster for pull packages from github and install configuration package.

 kubectl create secret docker-registry ghcr-secret \
    --docker-server=ghcr.io \
    --docker-username=<username>\
    --docker-password=<token> \
    -n crossplane-system

Step 7.

Render compositions and XRD

These files are the result of the composition and crd created using kcl, any changes should be made from the .k files.

kcl run resources/compositions/infra/crd.k > configuration/apis/crd.yaml
kcl run resources/compositions/infra/composition.k > configuration/apis/composition.yaml

Step 8.

Build package configuration.

crossplane xpkg build --package-root=./configuration/ --package-file=segoja7-configuration-keycloack.xpkg

Step 9.

Push package configuration in the github account.

crossplane xpkg push ghcr.io/segoja7/segoja7-configuration-keycloack:v1.0.0 -f segoja7-configuration-keycloack.xpkg

Step 10.

Install-configuration.yaml allow install the configuration package in the cluster using the secret for authenticated and pull the OCI package configuration.

➜ kubectl apply -f install-configuration.yaml
configuration.pkg.crossplane.io/segoja7-configuration-keycloack created

Step 11.

Apply Claim is the end step, basically is create all resources abstracted and wait for her (status = True) for make probes.

➜ kubectl apply -f resources/examples/claim.yaml
multiazinfraclaim.segoja7.example/infra-claim created

Step 12.

Verify all resources created.

➜ kubectl get configuration.pkg
NAME                              INSTALLED   HEALTHY   PACKAGE                                                  AGE
segoja7-configuration-keycloack   True        True      ghcr.io/segoja7/segoja7-configuration-keycloack:v1.0.0   3h15m
➜ kubectl get compositions
NAME                XR-KIND         XR-APIVERSION              AGE
infra-composition   XMultiAzInfra   segoja7.example/v1alpha1   3h15m

➜ kubectl get managed
Warning: BucketPolicy has been deprecated. Use spec.forProvider.policy in Bucket instead.
NAME                                                                  READY   SYNCED   AGE
dbsubnetgroup.database.aws.crossplane.io/backstage-subnet-group-idp   True    True     173m

NAME                                                       READY   SYNCED   STATE       ENGINE     VERSION   AGE
rdsinstance.database.aws.crossplane.io/storedata-rds-idp   True    True     available   postgres   17.4      173m

NAME                                    READY   SYNCED   ID                           IP              AGE
address.ec2.aws.crossplane.io/eip-idp   True    True     eipalloc-084d47829c9883e7f   54.146.16.193   173m

NAME                                            READY   SYNCED   ID                      VPC                     AGE
internetgateway.ec2.aws.crossplane.io/igw-idp   True    True     igw-0070a8d25d170cd90   vpc-0194aa72b31ff1d10   173m

NAME                                      READY   SYNCED   ID                      VPC                     SUBNET                     ALLOCATION ID                AGE
natgateway.ec2.aws.crossplane.io/ng-idp   True    True     nat-023fe7472e37f1f37   vpc-0194aa72b31ff1d10   subnet-026e050150dc85f90   eipalloc-084d47829c9883e7f   173m

NAME                                              READY   SYNCED   ID                      VPC                     AGE
routetable.ec2.aws.crossplane.io/rt-private-idp   True    True     rtb-0b62322c0b2315bd6   vpc-0194aa72b31ff1d10   173m
routetable.ec2.aws.crossplane.io/rt-public-idp    True    True     rtb-0aedc83d1aed5cdca   vpc-0194aa72b31ff1d10   173m

NAME                                                       READY   SYNCED   ID                     VPC                     AGE
securitygroup.ec2.aws.crossplane.io/backstage-rds-sg-idp   True    True     sg-071aed1f2a6d58405   vpc-0194aa72b31ff1d10   173m

NAME                                                       READY   SYNCED   ID                         VPC                     CIDR            AGE
subnet.ec2.aws.crossplane.io/app-private-subnet-az1-idp    True    True     subnet-0a5e735e87bccc368   vpc-0194aa72b31ff1d10   172.16.3.0/24   173m
subnet.ec2.aws.crossplane.io/app-private-subnet-az2-idp    True    True     subnet-09b23d56234e463fe   vpc-0194aa72b31ff1d10   172.16.4.0/24   173m
subnet.ec2.aws.crossplane.io/data-private-subnet-az1-idp   True    True     subnet-07be7b51481002165   vpc-0194aa72b31ff1d10   172.16.1.0/24   173m
subnet.ec2.aws.crossplane.io/data-private-subnet-az2-idp   True    True     subnet-0407ee651c0c58509   vpc-0194aa72b31ff1d10   172.16.2.0/24   173m
subnet.ec2.aws.crossplane.io/public-subnet-az1-idp         True    True     subnet-026e050150dc85f90   vpc-0194aa72b31ff1d10   172.16.5.0/24   173m
subnet.ec2.aws.crossplane.io/public-subnet-az2-idp         True    True     subnet-06404627395c08051   vpc-0194aa72b31ff1d10   172.16.6.0/24   173m

NAME                                READY   SYNCED   ID                      CIDR            IPV6CIDR   AGE
vpc.ec2.aws.crossplane.io/vpc-idp   True    True     vpc-0194aa72b31ff1d10   172.16.0.0/16              173m

NAME                                        READY   SYNCED   AGE
cluster.eks.aws.crossplane.io/cluster-idp   True    True     173m

NAME                                                           READY   SYNCED   EXTERNAL-NAME                                                                                                      AGE
addon.eks.aws.crossplane.io/addon-coredns-idp                  True    True     arn:aws:eks:us-east-1:476114125818:addon/cluster-idp/coredns/4ccbf7c3-52dd-d8ca-bf02-ccdf71f63fae                  173m        
addon.eks.aws.crossplane.io/addon-eks-pod-identity-agent-idp   True    True     arn:aws:eks:us-east-1:476114125818:addon/cluster-idp/eks-pod-identity-agent/c6cbf7c3-7123-3fae-d85d-bf0def5f9222   173m        
addon.eks.aws.crossplane.io/addon-kube-proxy-idp               True    True     arn:aws:eks:us-east-1:476114125818:addon/cluster-idp/kube-proxy/a8cbf7c3-537e-5279-faba-1c655083254d               173m        
addon.eks.aws.crossplane.io/addon-vpc-cni-idp                  True    True     arn:aws:eks:us-east-1:476114125818:addon/cluster-idp/vpc-cni/40cbf7c3-7117-f2a4-05db-9fd138a12831                  173m        

NAME                                            READY   SYNCED   CLUSTER       AGE
nodegroup.eks.aws.crossplane.io/nodegroup-idp   True    True     cluster-idp   173m

NAME                                                          CHART                          VERSION   SYNCED   READY   STATE      REVISION   DESCRIPTION        AGE
release.helm.crossplane.io/aws-load-balancer-controller-idp   aws-load-balancer-controller   1.13.3    True     True    deployed   152        Upgrade complete   173m
release.helm.crossplane.io/cert-manageridp                    cert-manager                   v1.18.2   True     False                                            173m
release.helm.crossplane.io/external-dnsidp                    external-dns                   1.17.0    True     True    deployed   155        Upgrade complete   173m
release.helm.crossplane.io/ingress-nginxidp                   ingress-nginx                  4.12.2    True     True    deployed   1          Install complete   173m

NAME                                                         READY   SYNCED   URL
openidconnectprovider.iam.aws.crossplane.io/eks-openid-idp   True    True     https://oidc.eks.us-east-1.amazonaws.com/id/C9C33D016B220174E50834BA11189416

NAME                                                          ARN                                                               READY   SYNCED   AGE
policy.iam.aws.crossplane.io/awsloadbalancer-controller-idp   arn:aws:iam::476114125818:policy/awsloadbalancer-controller-idp   True    True     173m
policy.iam.aws.crossplane.io/external-dns-idp                 arn:aws:iam::476114125818:policy/external-dns-idp                 True    True     173m

NAME                                                                                  READY   SYNCED   ROLENAME                            POLICYARN                                                         AGE
rolepolicyattachment.iam.aws.crossplane.io/clusteradminrolepolicy-idp                 True    True     clusteradminrole-idp                arn:aws:iam::aws:policy/AdministratorAccess                       173m
rolepolicyattachment.iam.aws.crossplane.io/clusternoderolepolicy-idp-1                True    True     clusternoderole-idp                 arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy                 173m
rolepolicyattachment.iam.aws.crossplane.io/clusternoderolepolicy-idp-2                True    True     clusternoderole-idp                 arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy                      173m
rolepolicyattachment.iam.aws.crossplane.io/clusternoderolepolicy-idp-3                True    True     clusternoderole-idp                 arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly        173m
rolepolicyattachment.iam.aws.crossplane.io/clusternoderolepolicy-idp-4                True    True     clusternoderole-idp                 arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore              173m
rolepolicyattachment.iam.aws.crossplane.io/clusternoderolepolicy-idp-5                True    True     clusternoderole-idp                 arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly        173m
rolepolicyattachment.iam.aws.crossplane.io/clusterrolepolicy-idp                      True    True     clusterrole-idp                     arn:aws:iam::aws:policy/AmazonEKSClusterPolicy                    173m
rolepolicyattachment.iam.aws.crossplane.io/sa-awsloadbalancer-controller-policy-idp   True    True     sa-awsloadbalancer-controller-idp   arn:aws:iam::476114125818:policy/awsloadbalancer-controller-idp   173m
rolepolicyattachment.iam.aws.crossplane.io/sa-cert-manager-policy-idp                 True    True     sa-cert-manager-idp                 arn:aws:iam::aws:policy/AmazonRoute53FullAccess                   173m
rolepolicyattachment.iam.aws.crossplane.io/sa-external-dns-policy-idp                 True    True     sa-external-dns-idp                 arn:aws:iam::476114125818:policy/external-dns-idp                 173m

NAME                                                           ARN                                                                READY   SYNCED   AGE
role.iam.aws.crossplane.io/clusteradminrole-idp                arn:aws:iam::476114125818:role/clusteradminrole-idp                True    True     173m
role.iam.aws.crossplane.io/clusternoderole-idp                 arn:aws:iam::476114125818:role/clusternoderole-idp                 True    True     173m
role.iam.aws.crossplane.io/clusterrole-idp                     arn:aws:iam::476114125818:role/clusterrole-idp                     True    True     173m
role.iam.aws.crossplane.io/sa-awsloadbalancer-controller-idp   arn:aws:iam::476114125818:role/sa-awsloadbalancer-controller-idp   True    True     173m
role.iam.aws.crossplane.io/sa-cert-manager-idp                 arn:aws:iam::476114125818:role/sa-cert-manager-idp                 True    True     173m
role.iam.aws.crossplane.io/sa-external-dns-idp                 arn:aws:iam::476114125818:role/sa-external-dns-idp                 True    True     173m

NAME                                                             KIND            PROVIDERCONFIG     SYNCED   READY   AGE
object.kubernetes.crossplane.io/cert-manager-certificate-idp     Certificate     provider-k8s-idp   True     True    173m
object.kubernetes.crossplane.io/cert-manager-clusterissuer-idp   ClusterIssuer   provider-k8s-idp   True     True    173m
object.kubernetes.crossplane.io/k8s-secret-idp                   Secret          provider-k8s-idp   True     True    173m
object.kubernetes.crossplane.io/keycloak-deployment-idp          Deployment      provider-k8s-idp   True     True    173m
object.kubernetes.crossplane.io/keycloak-ingress-idp             Ingress         provider-k8s-idp   True     True    173m
object.kubernetes.crossplane.io/keycloak-service-idp             Service         provider-k8s-idp   True     True    173m

TESTING URL FOR KEYCLOAK

ROUTE 53 Configuration from external-DNS

CERTIFICATE FROM CERT-MANAGER

Step 13.

key points the claim

The claim receive the following important parameters:

hostedZoneID: Is a hostzoneID created for route53, is used for cert-manager and external-dns.
keycloakHostname: "idp.segoja7.com" You need to change this parameter for a different url.
domainNames: Is a list for create certificates and use in the keycloack deployment or ingress controller. > Note: The configuration package create rds secret in the eks cluster, additional the password rds is the same for keycloack admin password.

CONCLUSION:
The configuration packages are:

Composable: Combine multiple cloud resources into higher-level abstractions
Reusable: Package once, deploy many times across teams and environments
Versionable: Semantic versioning for infrastructure components
Distributable: Share via OCI registries, just like container images.

Creating APIS with AWS Controllers for Kubernetes (ACK) and Kube Resource Orchestrator(KRO) using KCL.

Javier Sepúlveda — Mon, 10 Feb 2025 18:25:24 +0000

In November 2024 AWS announces and releases Kro as an opensource tool to simplify the use and creation of Custom APIs in Kubernetes and on January 30, 2025 google publishes on its blog a collaboration between Azure, GCP and AWS for the development of this tool, at the moment Kro is experimental and is working to make kro ready for production.

What is Kro?

Kro is a native tool and agonostic cloud, is way to define and groupings applications and their dependencies encapsulating all this as a single resource that can be easily used by end users.

What is ACK?

ACK are controllers for define and use AWS service resources directly from Kubernetes, check this introduction blog with an basic example using ACK in EKS.

What is KCL?

KCL is a configuration language that let us integrated Programming language techniques, in this blog Kcl is used for generated kubernetes manifests and reducing limitations of managing YAML configurations.

Later of a short introduction, it is time to deploy an application using ack controllers to deploy resources on AWS packaging all dependencies with Kro and using KCL to generate kubernetes manifests with more ease, order, control and reducing code repetition (DRY).

Requirements

Kubernetes cluster (Minikube)
programmatic access AWS
Helm version v3.16.2 or later
KCL

Please check all code from this blog in this repository

segoja7 / kro_ack_k8s

This is an example integrating kro and ack controllers using minikube

Kubernetes Deployments Simplified with Kro, ACK, and KCL

This repository demonstrates how to deploy an application on AWS EKS using Kro, ACK controllers, and KCL. This powerful combination simplifies infrastructure management, reduces code duplication, and streamlines the deployment process.

Key Technologies

Kro: A cloud-agnostic, Kubernetes-native tool for defining and grouping applications and their dependencies. Kro simplifies application management by encapsulating components as a single resource. (Currently experimental and under active development. See the Kro Status Update below.)
ACK (AWS Controllers for Kubernetes): Manage AWS service resources directly from your Kubernetes cluster. ACK provides a bridge between your Kubernetes environment and various AWS services.
KCL (Kubernetes Configuration Language): A modern configuration language that leverages programming language techniques to generate Kubernetes manifests. KCL promotes DRY (Don't Repeat Yourself) principles and reduces the complexity of managing YAML files.

Kro Status Update

Open Source Release (November 2024): Kro is now open-source!
Cross-Cloud Collaboration (January…

View on GitHub

All examples are divided in 2 sections

Infra resources are in the path ./infra
deploy resources are in the path ./deploy

Step 1.

Creating minikube profile.

minikube start -p kro

Step 2.

Installing KRO.

export KRO_VERSION=$(curl -sL \
    https://api.github.com/repos/kro-run/kro/releases/latest | \
    jq -r '.tag_name | ltrimstr("v")'
  )

helm install kro oci://ghcr.io/kro-run/kro/kro \
  --namespace kro \
  --create-namespace \
  --version=${KRO_VERSION}

Step 3.

Installing ACK Controllers.

Creating new namespace for ACK.

➜ kubectl create ns ack-system
namespace/ack-system created

With the namespace created is necessary defined an profile of AWS for create the resources, in this case an profile.txt is used for create after an secret in the namespace created.

➜ cat ~/kro/profile.txt
[default]
aws_access_key_id = <access_key_id>
aws_secret_access_key = <secret_access_key>

Note: This profile is used in a experimental and basic example, in another scenario IRSA is recommended

kubectl create secret generic aws-credentials -n ack-system --from-file=credentials=/home/segoja7/kro/profile.txt
secret/aws-credentials created

Install ACK Controllers

CONTROLLER_REGION=us-east-1; \
SERVICES=("iam" "ec2" "eks"); \
for SERVICE in "${SERVICES[@]}"; do \
  RELEASE_VERSION=$(curl -sL https://api.github.com/repos/aws-controllers-k8s/${SERVICE}-controller/releases/latest | jq -r '.tag_name | ltrimstr("v")'); \
  if [[ -z "$RELEASE_VERSION" ]]; then \
    echo "Error: Could not retrieve release version for ${SERVICE}."; \
    continue; \
  fi; \
  helm install --create-namespace -n ack-system \
    oci://public.ecr.aws/aws-controllers-k8s/${SERVICE}-chart \
    --version="${RELEASE_VERSION}" \
    --generate-name \
    --set aws.region="${CONTROLLER_REGION}" \
    --set aws.credentials.secretName=aws-credentials \
    --set aws.credentials.profile=default; \
  if [[ $? -eq 0 ]]; then \
    echo "Successfully installed ${SERVICE} controller."; \
  else \
    echo "Error: Failed to install ${SERVICE} controller."; \
  fi; \
done

Step 4.

Creating an ResourceGraphDefinition for Infrastructure

KCL is used to applied for defined on only resource and evit duplicate code.

In an scenario normal is necessary defined multiples times the same resource.
For example: validate this example in ACK page. link

with KCL it is possible to apply a logic to create in this case the subnets and associate them with their correct routetable.

    resources += [{    
        id = subnet_config.name
        template = {
            apiVersion = "ec2.services.k8s.aws/v1alpha1"
            kind = "Subnet"
            metadata = {
                name = subnet_config.name + my_config.project_name
            }
            spec = {
                availabilityZone = subnet_config.zone
                cidrBlock = subnet_config.cidr
                vpcID = r"""${vpc.status.vpcID}"""
                if subnet_config.type == "public":
                    mapPublicIPOnLaunch = True 
                    routeTables = [
                        r"""${routetablepublic.status.routeTableID}""" 
                    ]
                    tags = [
                        {
                            key = "ManagedBy"
                            value = apiVersion
                        }
                        {
                            key = "Name"
                            value = metadata.name
                        }
                        {
                            key = "kubernetes.io/role/elb" 
                            value = "1"
                        }
                        {
                            key = r"""kubernetes.io/cluster/cluster""" + my_config.project_name + """"""
                            value = "shared"
                        }
                    ]
                else:
                    mapPublicIPOnLaunch = False
                    routeTables = [
                        r"""${routetableprivate.status.routeTableID}"""
                    ]
                    tags = [
                        {
                            key = "ManagedBy"
                            value = apiVersion
                        }
                        {
                            key = "Name"
                            value = metadata.name
                        }
                        {
                            key = "kubernetes.io/role/internal-elb"
                            value = "1"
                        }
                        {
                            key = r"""kubernetes.io/cluster/cluster""" + my_config.project_name + """"""
                            value = "shared"
                        }
                    ]
            }
        }
    } for subnet_config in my_config.subnet_configs]

Aplying Infra ResourceGraphDefinition

kcl infra-sample-app-stack.k | kubectl apply -f -
resourcegraphdefinition.kro.run/infrasampleappstack.kro.run created

In this case all infrastructure resources are packaged in a Custom Resource Definition called infrasampleappstacks with a KIND InfraSampleAppStack ready to be instantiated by an end user.

What resources are created:

vpc
internetgateway
routetablepublic
elasticipaddress
clusterrole
clusternoderole
clusteradminrole
publicsubnetaz1
publicsubnetaz2
natgateway
routetableprivate
appprivatesubnetaz1
appprivatesubnetaz2
cluster
clusternodegroup

Creating an Instance with new CRD InfraSampleAppStack

kubectl apply -f sample-app-instance.yaml
infrasampleappstack.kro.run/infrasampleappstack created

Validating Resources in console.

When all resources are deployed, the state change from IN_PROGRESS to ACTIVE.

Step 5.

Deploying an ResourceGraphDefinition for the application

After the all infraestructure is created is time for deploy the application, in this case a popular "Deploy 2048 Game" using a basic pipeline with TEKTON.

Installing TEKTON

 kubectl create ns tekton-tasks
namespace/tekton-tasks created

Copying secret from aws secret from ack-system to tekton-tasks namespace, this secret is after used for tasks of the pipeline.

kubectl get secret aws-credentials -n ack-system -o yaml \
  | sed "s/namespace: ack-system/namespace: tekton-tasks/" \
  | kubectl apply -f -
secret/aws-credentials created

Installing Tekton CRDS

kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
namespace/tekton-pipelines created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-controller-cluster-access created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-controller-tenant-access created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-webhook-cluster-access created
clusterrole.rbac.authorization.k8s.io/tekton-events-controller-cluster-access created

Aplying deploy ResourceGraphDefinition

kcl sample-app-stack.k | kubectl apply -f -
resourcegraphdefinition.kro.run/deploysampleappstack.kro.run created

In this case all deploy resources are packaged in a Custom Resource Definition called deploysampleappstack with a KIND DeploySampleAppStack ready to be instantiated by an end user.

What resources are created:

authenticateanddeploy: Is a task that receive 3 parameters, "cluster-name", "aws-region" and "game-yaml-url", this task have 5 steps:

Install kubectl.

Export the enviroment variable AWS_SHARED_CREDENTIALS_FILE using the secret and after run (aws eks update-kubeconfig --name $(params.cluster-name) --region $(params.aws-region) for connect with the eks cluster.

Execute an kubectl get nodes for validate connectivity with the cluster

Deploy the game 2048 with a service that create an classic load balancer using an raw url with the parameter "game-yaml-url".

exeute an kubectl get svc -n default for retrieve dns from classic load balancer

tektonpipeline: refers to the task (authenticateanddeploy) and passes the parameters for the steps.

Creating an Instance with new CRD DeploySampleAppStack

kubectl apply -f sample-app-instance.yaml
deploysampleappstack.kro.run/deploysampleappstack created

Validating Resources

Trigger Tekton Pipeline.

kubectl apply -f pipelinerun.yaml
pipelinerun.tekton.dev/deploy-to-eks-run created

When the pipelinerun.yaml is executed a new pod is created where are executed tasks from pipeline that deploying the app in eks cluster.

Testing APP.

Cleanup.

kubectl delete -f deploy/pipelinerun.yaml
pipelinerun.tekton.dev "deploy-to-eks-run" deleted

kubectl delete -f deploy/sample-app-instance.yaml
deploysampleappstack.kro.run "deploysampleappstack" deleted

kcl deploy/sample-app-stack.k | kubectl delete -f -
resourcegraphdefinition.kro.run "deploysampleappstack.kro.run" deleted

kubectl delete -f infra/sample-app-instance.yaml
infrasampleappstack.kro.run "infrasampleappstack" deleted

kcl infra/infra-sample-app-stack.k | kubectl delete -f -
resourcegraphdefinition.kro.run "infrasampleappstack.kro.run" deleted

Don't forget clean ALB Classic

Conclusion: This tutorial takes an approach to deploying applications on AWS EKS using Kro, ACK Controllers, and KCL. This combination of tools significantly reduces code duplication, improves maintainability and overall developer productivity, and provides a robust and efficient workflow for managing Kubernetes deployments on AWS.

Comparing KRO by AWS and Crossplane v1.20

Javier Sepúlveda — Wed, 08 Jan 2025 17:32:45 +0000

Today there is a new opensource tool for kubernetes, is the case of KRO (Kube Resources Orchestator). This a experimental project created by AWS, by the moment in phase beta and not is recommend for productions environment.

When validating this project I see that it is another tool like Crossplane with a big difference in maturity, both can do the same, but competition is always good, so welcome.

Comparating crossplane and KRO

In crossplane for you create an API you need to create a CompositeResourceDefinition and a Composition with this you are enabled your developers for create an claim and deploy applications as API, but in KRO is a little different, the concept is similar but you need an ResourceGroup where are defined all components of the API for that the developers can be create the Application as Instances.

How to Work KRO.

Check the offical documentacion

Check my blog related to ACK Controller.

Creating Infraestructure with the ACK from EKS AWS

Kro is simple and easy, Kro uses a single ResourceGroup to define and manage collections of Kubernetes resources and automatically creates CRDs and controllers for your custom resources.

How to Work Crossplane.

Check my lasts blogs.
Crossplane + AWS Overview for Managing Infrastructure as Code (IaC) with Kubernetes.
Crossplane AWS First Demo for Managing Infrastructure as Code (IaC) with Kubernetes..
Self-Service: Building and Enabling APIs with Crossplane and AWS
KCL + Crossplane: A Declarative Language for Deploying Complex Infrastructure on AWS with Kubernetes.

Compositions and Composite Resource Definitions are key configurations for composing higher-level APIs. The composite resource defines the schema of the new custom API, it is a definition of a new CRD and the Composition is the bridge between the new CRD schema and the existing managed resources.

Conclusion

KRO (Kube Resources Orchestator) is a new open-source tool for Kubernetes and this is an experimental project created by AWS and is currently in beta, I think that KRO is similar to Crossplane but less mature.Both help simplify complex applications or architectures for product teams or developers, allowing the complexity to be left to the platform teams.

KCL Function+ Crossplane: A Declarative Language for Deploying Complex Infrastructure on AWS with Kubernetes.

Javier Sepúlveda — Tue, 19 Nov 2024 15:29:36 +0000

In recent blogs, the exploration of how Crossplane works and its potential to create self-service models by enabling custom APIs has been discussed. The previous example, however, was quite basic.

Javier Sepúlveda

Oct 8 '24

Self-Service : Building and Enabling APIs with Crossplane and AWS

#crossplane #aws #kubernetes #devops

Comments

4 min read

This time, the focus shifts to a more advanced concept in Crossplane: functions.

One limitation of Crossplane is its inability to use loops or conditionals when creating resources. A previous experiment highlighted this challenge, requiring resources to be defined individually. This approach often resulted in manifests that were difficult to manage and prone to complexity, resembling spaghetti code.

For context, here is an example using only providers: My first steps with Crossplane.

segoja7 / crossplane_app_aws

To address these issues, functions provide a solution that improves code reusability, adheres to the DRY (Don't Repeat Yourself) principle, and reduces the likelihood of human error. Functions enable the use of complex logic within compositions, making them more robust and easier to maintain.

function-kcl

By incorporating functions like these, Crossplane compositions can overcome many limitations, becoming more flexible and capable of handling intricate scenarios.

Deploying A network Layer with crossplane and KCL.

Requirements

Kubernetes cluster (Minikube)
Helm version v3.13.1 or later
Crossplane
programmatic access AWS

Step 1.

This blog assumes that you have all requirements completed and assume that you have installed the providers and the ProviderConfig used in the last blog.
If you have any doubt, please check the this post.

Step 2.

Install kcl function.

kubectl apply -f functions.yaml

Step 3.

Defined the API using the CompositeResourceDefinition.yaml or XRD.

In this case, the API only receives: vpccidrBlock, region, and projectName through claim.yaml.

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
 name: multiazwordpressinfra.segoja7.example
spec:
 group: segoja7.example
 names:
    kind: MultiAzWordpressInfra
    plural: multiazwordpressinfra
 versions:
   - name: v1alpha1
     served: true
     referenceable: true
     schema:
       openAPIV3Schema:
         type: object
         properties:
           spec:
             type: object
             properties:
               parameters:
                 type: object
                 properties:
                   projectName:
                     type: string
                   vpccidrBlock:
                     type: string
                     default: "172.16.0.0/16"
                   region:
                     type: string
                     default: "us-east-1"
                 required:
                   - region

Step 4.

Composition.

Crossplane has two modes of composition: pipeline and resouces(Deprecated) check the documentation.

Following best practices, the compositions have the pipeline mode, and through it, a sequence of steps is defined.

This is the most important lines for the compositions using kcl function.

  pipeline:
  - step: normal
    functionRef:
      name: function-kcl
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLRun
      metadata:
        name: basic
      spec:
        source: |
# Removed for Brevity
  - step: ready
    functionRef:
      name: function-auto-ready

How do KCL functions help users?

As previously mentioned, when needing to deploy complex infrastructure, Crossplane doesn't directly allow this. Functions become necessary, and with KCL functions, users can solve and improve the code for deploying that infrastructure.

For example, this is subnets resource with out kcl function. have a declaration for create 4 subnets type private.

---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Subnet
metadata:
  name: database-private-subnet-az1
  labels:
    dbsubnet1: private1
spec:
  forProvider:
    availabilityZone: us-east-1a
    cidrBlock: 172.16.1.0/24
    mapPublicIpOnLaunch: false
    region: us-east-1
    tags:
      Name: database-private-subnet-az1
      ManagedBy: crossplane
    vpcIdSelector:
      matchLabels:
        vpc: wordpress
  providerConfigRef:
    name: segoja7
---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Subnet
metadata:
  name: database-private-subnet-az2
  labels:
    dbsubnet2: private2
spec:
  forProvider:
    availabilityZone: us-east-1b
    cidrBlock: 172.16.2.0/24
    mapPublicIpOnLaunch: false
    region: us-east-1
    tags:
      Name: database-private-subnet-az2
      ManagedBy: crossplane
    vpcIdSelector:
      matchLabels:
        vpc: wordpress
  providerConfigRef:
    name: segoja7
---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Subnet
metadata:
  name: app-private-subnet-az1
  labels:
    appsubnet1: private1
spec:
  forProvider:
    availabilityZone: us-east-1a
    cidrBlock: 172.16.3.0/24
    mapPublicIpOnLaunch: false
    region: us-east-1
    tags:
      Name: app-private-subnet-az1
      ManagedBy: crossplane
    vpcIdSelector:
      matchLabels:
        vpc: wordpress
  providerConfigRef:
    name: segoja7
---
apiVersion: ec2.aws.upbound.io/v1beta1
kind: Subnet
metadata:
  name: app-private-subnet-az2
  labels:
    appsubnet2: private2
spec:
  forProvider:
    availabilityZone: us-east-1b
    cidrBlock: 172.16.4.0/24
    mapPublicIpOnLaunch: false
    region: us-east-1
    tags:
      Name: app-private-subnet-az2
      ManagedBy: crossplane
    vpcIdSelector:
      matchLabels:
        vpc: wordpress
  providerConfigRef:
    name: segoja7

And this is an example using kcl-function.

Defining an map of objects for iterate about them.

          database_subnet_configs = [
              {"name": "data-private-subnet-az1", "cidr": "172.16.1.0/24", "zone": "us-east-1a", "type": "private"},
              {"name": "data-private-subnet-az2", "cidr": "172.16.2.0/24", "zone": "us-east-1b", "type": "private"},
              {"name": "app-private-subnet-az1", "cidr": "172.16.3.0/24", "zone": "us-east-1a", "type": "private"},
              {"name": "app-private-subnet-az2", "cidr": "172.16.4.0/24", "zone": "us-east-1b", "type": "private"},
              {"name": "public-subnet-az1", "cidr": "172.16.5.0/24", "zone": "us-east-1a", "type": "public"},
              {"name": "public-subnet-az2", "cidr": "172.16.6.0/24", "zone": "us-east-1b", "type": "public"}
          ]

creating subnets using an for.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: multiazwordpressinfra-composition
spec:
  compositeTypeRef:
    apiVersion: segoja7.example/v1alpha1
    kind: MultiAzWordpressInfra
  mode: Pipeline
  pipeline:
  - step: normal
    functionRef:
      name: function-kcl
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLRun
      metadata:
        name: basic
      spec:
        source: |
          # Removed for Brevity

          _resources += [
          {
              apiVersion = "ec2.aws.upbound.io/v1beta1"
              kind = "Subnet"
              metadata.name = subnet_config.name
              metadata.labels = {
                    type = subnet_config.type    
              }
              spec.forProvider = {
                  region = region
                  vpcIdSelector.matchControllerRef = True
                  availabilityZone = subnet_config.zone
                  cidrBlock = subnet_config.cidr
                  mapPublicIpOnLaunch = True if subnet_config.type == "public" else False
                  tags = {
                    "app" = "wordpress"
                    "Name" = metadata.name + "-" + projectName
                    "Type" = subnet_config.type
                  }
              }
              spec.providerConfigRef.name = providerConfigName         
          }for subnet_config in database_subnet_configs 
          ]
# Removed for Brevity                                 
          items = _resources
  - step: ready
    functionRef:
      name: function-auto-ready

For this blog the compositions only allow the resources creation of network layer in AWS.
Check all code in this repo.

segoja7 / crossplane_compositions_kcl

This is an example using compositions with kcl

Step 5.

The claim is the trigger to deploy the resources defined in the compositions.

apiVersion: segoja7.example/v1alpha1
kind: MultiAzWordpressInfra
metadata:
 name: wordpress-claim
 namespace: default
spec:
  parameters:
    projectName: wordpress-team1s

In this claim, the only parameter for the end user is the project name, which allows the abstraction to be on the platform team side and not the product team side.

Step 6.

Verify the Resources

Please check the following help links, which offer valuable information to improve your understanding of the tool and make the most of its features.

Usefull links:

Conclusion: Crossplane, along with KCL, provides a powerful solution for managing cloud resources more flexibly and efficiently. By enabling the creation of reusable compositions and integrating complex logic, it improves maintainability and reduces errors. Additionally, by abstracting technical details, it eases the work of platform teams, optimizing the experience for end users.

Thanks to the Crossplane and KCL-Functions community for the support, they helped me with doubts and questions to make this post.

Thanks for reading this post, let me know if you have any question or comment.

Self-Service : Building and Enabling APIs with Crossplane and AWS

Javier Sepúlveda — Tue, 08 Oct 2024 20:47:52 +0000

In the first blog of crossplane, a glimpse was taken to a crossplane from an understanding of the key concepts, her definition and make some examples for understanding each component.

Javier Sepúlveda

Jul 26 '24

Crossplane + AWS Overview for Managing Infrastructure as Code (IaC) with Kubernetes

#aws #eks #crossplane #iac

Comments

3 min read

Can read above.

In the last blog, work was an exercise of how to deploy a simple app using wordpress with crossplane and creating each layer using Managed resources, that is well, but no is a best practice.

Javier Sepúlveda

Aug 30 '24

Crossplane AWS First Demo for Managing Infrastructure as Code (IaC) with Kubernetes.

#kubernetes #devops #cloud #crossplane

Comments

6 min read

Can read above.

Now is time for applying the best practices using crossplane and make your APIs with a higher level more far from a simple Managed Resources.

Composition and Composite Resource Definition are the configurations that are used to compose a higher-level API.

The composite resource defines the schema of the new custom API, it is a definition of a new CRD and the Composition is the bridge between the new CRD schema and the existing managed resources. When the CompositeResourceDefinition and the Composition are done, it is the moment to start provisioning the infrastructure using a resource claim object.

All this together allow us building reusable infrastructure for our teams, imagine something like to build many APIs or patterns and the teams in a self-service model adding her needs in the car to finally build an app.

Requirements

Kubernetes cluster (Minikube)
Helm version v3.13.1 or later
Crossplane
programmatic access AWS

Step 1.

Step 2.

validating the providers.

kubectl get all -n crossplane-system

kubectl get providerconfig

With this validation, the environment is ready to provision AWS resources using compositions.

Step 3.

It is necessary to know how CompositeResourceDefinition works. Please check this link for more info.

This is the first CompositeResourceDefinition for defining a higher level API for a VPC in AWS.

Download the repository for creating the resources.

segoja7 / crossplane_compositions

This is a copy of crossplane_app_aws but using compositions

crossplane_compositions

This is a copy of crossplane_app_aws but using compositions

View on GitHub

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xvpcs.segoja.example # plural.group
spec:
  group: segoja.example #api group
  names:
    kind: Xvpc #singular name
    plural: xvpcs #plural name
  versions:
    - name: v1alpha1 #Define the versions from alpha to pdn or deprecated
      served: true #version actively
      referenceable: true #indicates which version of the schema Compositions use
      schema: # OpenAPI schema
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                parameters:
                  type: object
                  properties:
                    cidrBlock:
                      type: string
                      #default: "10.0.0.0/16"
                    enableDnsHostnames:
                      type: boolean
                      default: true
                    enableDnsSupport:
                      type: boolean
                      default: true
                    region:
                      type: string
                      default: "us-east-1"
                  required:
                    - region

In this point the compositeResourceDefinition is a new CRD and the Composition like the new controller waiting for a claim for creating the resource according to definitions.

Note: The section patches is very important because is the unique place that is available for that the user could be personalized the resource, in this case the user could be define the name of the vpc and the cidrblock.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xvpc-composition
spec:
  compositeTypeRef: #specific version defined in the
    apiVersion: segoja.example/v1alpha1
    kind: Xvpc
  resources: #Array with the list of Managed Resources
    - name: vpc
      base: #Resource template
        apiVersion: ec2.aws.upbound.io/v1beta1
        kind: VPC
        spec:
          forProvider:
            cidrBlock: 172.0.0.0/16
            enableDnsHostnames: true
            enableDnsSupport: true
            region: us-east-1
            tags:
              app: vpc-wordpress
              ManagedBy: crossplane
          providerConfigRef:
            name: segoja7
      patches: #subattributes
        - fromFieldPath: "spec.parameters.cidrBlock"
          toFieldPath: "spec.forProvider.cidrBlock"
        - fromFieldPath: "metadata.name"
          toFieldPath: "spec.forProvider.tags.Name"
        - fromFieldPath: "metadata.name"
          toFieldPath: "metadata.annotations['crossplane.io/external-name']"

The claim allows a user to create the resource that was defined in the compositeResourceDefinition and Additionally, the user could create that resource in the namespace that was assigned for him.

apiVersion: segoja.example/v1alpha1
kind: Xvpc #singular claim name in the compositeResourceDefinition
metadata:
  name: vpc-wordpress-claim
  namespace: default
spec:
  parameters: #Parameters in the composition
    cidrBlock: 192.178.0.0/16

Step 4

At that time the first API was build.

kubectl apply -R -f resources/network/vpc/

The new API xvpcs, to create vpcs.

The compositeResourceDefinition

The composition

The claim for creating a vpc.

This is the vpc in console, as you can see, the vpc have DNS hostnames and DNS resolution enabled by default, the only values that accept the compositions are cidrblock and vpc_name, in this way it is possible to adjust the compositions to the needs of each company or teams.

Conclusion: This is a practical example of how to quickly enable product teams or developers to use infrastructure or apps quickly, without coding, just using configurations, the platform teams abstracts and encapsulates all the complexity.

Thanks for reading this post, let me know if you have any question or comment.

Crossplane AWS First Demo for Managing Infrastructure as Code (IaC) with Kubernetes.

Javier Sepúlveda — Fri, 30 Aug 2024 21:21:09 +0000

In this opportunity is the moment to know with more detail as deployed resources in AWS using resource definitions in crossplane, In the last post we talked about some definitions of crossplane, you can check them in the following link.

Javier Sepúlveda

Jul 26 '24

Crossplane + AWS Overview for Managing Infrastructure as Code (IaC) with Kubernetes

#aws #eks #crossplane #iac

Comments

3 min read

Requirements

Kubernetes cluster (Minikube)
Helm version v3.13.1 or later
Crossplane
programmatic access AWS

Step 1.

First, create a profile in minikube

minikube start -p crossplane

With minikube running is moment for install Helm and crossplane, check this link.

with the profile of minikube created and helm and crossplane running it is needed to create a txt file, for this case the document name is profile.txt

[default]
aws_access_key_id = <Your access key id>
aws_secret_access_key = <Your secret access key>

when the txt file is created it is necessary created a generic secret.

kubectl create secret generic aws-secret -n crossplane-system --from-file=creds=./profile.txt

Step2.

Installing a provider

installing provider, in this case providers for rds, ec2, efs and elb.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-ec2
spec:
  package: xpkg.upbound.io/upbound/provider-aws-ec2:v1.12.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-rds
spec:
  package: xpkg.upbound.io/upbound/provider-aws-rds:v1.12.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-efs
spec:
  package: xpkg.upbound.io/upbound/provider-aws-efs:v1.12.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-elbv2
spec:
  package: xpkg.upbound.io/upbound/provider-aws-elbv2:v1.13.0

When the provider is installed is time to create an providerconfig, and associated the secret created for autenticated with aws.

Configuring the provider

apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: segoja7
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-secret
      key: creds

In this case, it is using the key from secret with the name creds.

Note: for this lab it is using a credential, but for other environment type is more recommend used roles.

Architecture

This is a simple wordpress app with high availability.

Step3.

Download the repository for create the resources.

segoja7 / crossplane_app_aws

You can check the code in the link above, all the resources are in stack and with the kubectl apply command in a matter of minutes all the services will be deployed in AWS and with the wordpress application ready to install.

A little of spam

kubectl apply -R -f resources/

instance.ec2.aws.upbound.io "ec2-wordpress" created
instance.ec2.aws.upbound.io "ec2-wordpress-2" created
elb.elb.aws.upbound.io "wordpress-elb" created
attachment.elb.aws.upbound.io "attachment-elb-wordpress" created
subnetgroup.rds.aws.upbound.io "wordpress-subnetgroup" created
instance.rds.aws.upbound.io "wordpress-dbinstance" created
securitygroup.ec2.aws.upbound.io "ec2securitygroup" created
securitygroupingressrule.ec2.aws.upbound.io "http-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-ec2-wordpress-sg" created
securitygroup.ec2.aws.upbound.io "efssecuritygroup" created
securitygroupingressrule.ec2.aws.upbound.io "app-to-efs-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-efs-sg" created
securitygroup.ec2.aws.upbound.io "elbsecuritygroup" created
securitygroupingressrule.ec2.aws.upbound.io "world-to-elb-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-elb-wordpress-sg" created
securitygroup.ec2.aws.upbound.io "rdssecuritygroup" created
securitygroupingressrule.ec2.aws.upbound.io "app-to-db-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-rds-sg" created
vpc.ec2.aws.upbound.io "two-tier-vpc-app" created
subnet.ec2.aws.upbound.io "database-private-subnet-az1" created
subnet.ec2.aws.upbound.io "database-private-subnet-az2" created
subnet.ec2.aws.upbound.io "app-private-subnet-az1" created
subnet.ec2.aws.upbound.io "app-private-subnet-az2" created
subnet.ec2.aws.upbound.io "public-subnet-az1" created
subnet.ec2.aws.upbound.io "public-subnet-az2" created
routetable.ec2.aws.upbound.io "public-route-table" created
routetable.ec2.aws.upbound.io "private-route-table" created
internetgateway.ec2.aws.upbound.io "internetgateway" created
eip.ec2.aws.upbound.io "eip-nat-gateway-az1" created
natgateway.ec2.aws.upbound.io "nat-gateway-az1" created
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation1" created
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation2" created
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation1" created
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation2" created
routetableassociation.ec2.aws.upbound.io "public-route-table1" created
routetableassociation.ec2.aws.upbound.io "public-route-table2" created
route.ec2.aws.upbound.io "publicroute" created
route.ec2.aws.upbound.io "privateroute" created
filesystem.efs.aws.upbound.io "efs-wordpress" created
accesspoint.efs.aws.upbound.io "efs-wordpress" created
filesystempolicy.efs.aws.upbound.io "efs-policy" created
mounttarget.efs.aws.upbound.io "efs-mounttarget-az1" created
mounttarget.efs.aws.upbound.io "efs-mounttarget-az2" created

With all resouces created is moment of install wordpress, for brevity this step is skiped but you can check the dns name for validating the site and retrieve the rds values for installing wordpress.

Troubleshooting

In some cases the resources are not created, when the resource is in state ready=false the resource is not deployed and is moment for revise the specs for the desired state of the resource.

When the spec of the resource is modified, it is moment for apply the resource again.

Additional is posible make a list of all resources and verify it is status.

kubectl get managed

Cleanup

kubectl delete -R -f resources/
instance.ec2.aws.upbound.io "ec2-wordpress" deleted
instance.ec2.aws.upbound.io "ec2-wordpress-2" deleted
elb.elb.aws.upbound.io "wordpress-elb" deleted
attachment.elb.aws.upbound.io "attachment-elb-wordpress" deleted
subnetgroup.rds.aws.upbound.io "wordpress-subnetgroup" deleted
instance.rds.aws.upbound.io "wordpress-dbinstance" deleted
securitygroup.ec2.aws.upbound.io "ec2securitygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "http-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-ec2-wordpress-sg" deleted
securitygroup.ec2.aws.upbound.io "efssecuritygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "app-to-efs-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-efs-sg" deleted
securitygroup.ec2.aws.upbound.io "elbsecuritygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "world-to-elb-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-elb-wordpress-sg" deleted
securitygroup.ec2.aws.upbound.io "rdssecuritygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "app-to-db-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-rds-sg" deleted
vpc.ec2.aws.upbound.io "two-tier-vpc-app" deleted
subnet.ec2.aws.upbound.io "database-private-subnet-az1" deleted
subnet.ec2.aws.upbound.io "database-private-subnet-az2" deleted
subnet.ec2.aws.upbound.io "app-private-subnet-az1" deleted
subnet.ec2.aws.upbound.io "app-private-subnet-az2" deleted
subnet.ec2.aws.upbound.io "public-subnet-az1" deleted
subnet.ec2.aws.upbound.io "public-subnet-az2" deleted
routetable.ec2.aws.upbound.io "public-route-table" deleted
routetable.ec2.aws.upbound.io "private-route-table" deleted
internetgateway.ec2.aws.upbound.io "internetgateway" deleted
eip.ec2.aws.upbound.io "eip-nat-gateway-az1" deleted
natgateway.ec2.aws.upbound.io "nat-gateway-az1" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation1" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation2" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation1" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation2" deleted
routetableassociation.ec2.aws.upbound.io "public-route-table1" deleted
routetableassociation.ec2.aws.upbound.io "public-route-table2" deleted
route.ec2.aws.upbound.io "publicroute" deleted
route.ec2.aws.upbound.io "privateroute" deleted
filesystem.efs.aws.upbound.io "efs-wordpress" deleted
accesspoint.efs.aws.upbound.io "efs-wordpress" deleted
filesystempolicy.efs.aws.upbound.io "efs-policy" deleted
mounttarget.efs.aws.upbound.io "efs-mounttarget-az1" deleted
mounttarget.efs.aws.upbound.io "efs-mounttarget-az2" deleted

Conclusion:

This is a short overview of how to deploy managed resources using crossplane, in the next post we will make a demo to deploy resources in the console but with compositions.

Thanks for reading this post, let me know if you have any question or comment.

Crossplane + AWS Overview for Managing Infrastructure as Code (IaC) with Kubernetes

Javier Sepúlveda — Fri, 26 Jul 2024 15:33:53 +0000

Crossplane is an open source platform for managing Infrastructure as Code (IaC) using the Kubernetes API. It allows you to define and manage infrastructure resources (such as databases, networks, storage, etc.) declaratively.

Crossplane is mainly based on Custom Resource Definitions (CRD) or custom controllers that allow us to deploy resources in the cloud provider. Crossplane has other important components such as:

Providers
Managed Resources
Composite Resources

Providers

Providers are the way to authenticate, make API calls and provide MR drivers with the cloud provider, in this case, AWS. Currently, there are two providers available for use with Crossplane:

provider-aws has less crds, and this provider has more crds provider-upjet-aws

The RDS Provider installs a second Provider, the upbound-provider-family-aws.
The family provider manages authentication to AWS across all AWS family Providers.

It is also necessary to create a ControllerConfig, mainly used for credentials (in the case of EKS, a service account):

apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
  name: runtime-config
spec:
  serviceAccountTemplate:
    metadata:
      annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789111:role/crossplane-role-controller

This is an example Provider for deploy RDS

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-rds
spec:
  package: xpkg.upbound.io/upbound/provider-aws-rds:v1.9.1
  runtimeConfigRef:
    name: runtime-config

apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: provider-config
spec:
  credentials:
    source: IRSA

Create a DeploymentRuntimeConfig to associate the IAM role ARN.
Apply the DeploymentRuntimeConfig to the Provider.
Instruct the ProviderConfig to use IRSA credentials.

When your provider is installed, you can see the new CRDS

Managed Resources (MR).

A managed resource (MR) connects a CRD to a controller that deploys the resource. For example, an RDS instance in AWS is an MR, represented in a YAML file that defines an RDS instance.

apiVersion: rds.aws.upbound.io/v1beta2
kind: Instance
metadata:
  annotations:
    meta.upbound.io/example-id: rds/v1beta1/instance
    uptest.upbound.io/timeout: "3600"
  labels:
    testing.upbound.io/example-name: example-dbinstance
  name: example-dbinstance
spec:
  forProvider:
    allocatedStorage: 20
    autoGeneratePassword: true
    autoMinorVersionUpgrade: true
    backupRetentionPeriod: 14
    backupWindow: 09:46-10:16
    dbName: example
    engine: postgres
    engineVersion: "16.1"
    instanceClass: db.t3.micro
    maintenanceWindow: Mon:00:00-Mon:03:00
    passwordSecretRef:
      key: password
      name: example-dbinstance
      namespace: crossplane-system
    publiclyAccessible: false
    region: us-east-1
    skipFinalSnapshot: true
    storageEncrypted: true
    storageType: gp2
    username: adminuser
  providerConfigRef:
    name: providerconfig

Crossplane has the ability to revert any changes to the resource that are not contemplated in the YAML file, using this file as the only source of truth.

In this point you can create a resource, in this case an RDS instance with default values.

Composite resources (XR)

Composite resources allow complex resources to be created and managed. This abstracts the complexity of creating multiple resources and encapsulates the logic and configuration of various infrastructure resources.

There are two types: composite resources (XR) and composite resource claims (XRC), which facilitate infrastructure management in a declarative and reusable manner.

XRs are used in the CompositeResourceDefinition type and their main purpose is to combine related managed resources into a single stack and build reusable infrastructure template APIs.

The following are the critical components in an XR:
Composite Resource Definition (XRD)

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: compositerdsinstances.database.example.org
spec:
  group: database.example.org
  names:
    kind: CompositeRDSInstance
    plural: compositerdsinstances
  claimNames:
    kind: RDSInstance
    plural: rdsinstances
  versions:
  - name: v1
    served: true
    referenceable: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              parameters:
                type: object
                properties:
                  storageGB:
                    type: integer
                  version:
                    type: string

Composition

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: compositerdsinstances.aws.database.example.org
spec:
  compositeTypeRef:
    apiVersion: database.example.org/v1alpha1
    kind: CompositeRDSInstance
  resources:
  - base:
      apiVersion: rds.aws.crossplane.io/v1beta1
      kind: DBInstance
      spec:
        forProvider:
          dbInstanceClass: db.t3.micro
          allocatedStorage: 20
          engine: postgres
          engineVersion: "13"
          masterUsername: admin
    patches:
    - fromFieldPath: "spec.parameters.storageGB"
      toFieldPath: "spec.forProvider.allocatedStorage"
    - fromFieldPath: "spec.parameters.version"
      toFieldPath: "spec.forProvider.engineVersion"

• Claim (XRCs)

XRCs allow users to request XR instances easily and consistently.

apiVersion: database.example.org/v1alpha1
kind: RDSInstance
metadata:
  name: my-rds-claim
spec:
  parameters:
    storageGB: 20
    version: "13"

Conclusion: This is a short overview of important resources used in crossplane to start a deployment of new resources of a manner declarative, in the next post we make a demo deploy resources in the console.

Thanks for reading this post, let me know if you have any question or comment.

Creating Infraestructure with the ACK from EKS AWS.

Javier Sepúlveda — Thu, 27 Jun 2024 21:14:51 +0000

Cloud people!

The turn in this occasion is for the AWS controller for k8s (ack).

I believe that traditional Infrastructure as Code (IaC) tools have some limitations. The transition towards solutions such as Crossplane or similar projects is inevitable and, possibly, in a short time this evolution will be adopted. At another time, we could discuss in detail the pros and cons of these tools.

Requirements

AWS CLI
Kubectl
Terraform
k9s
Helm
K8s cluster (You can use a local cluster or in this demo an eks cluster.)

Let's see how we can do this.

Reference Architecture

In this demo Terraform is used to deploy infrastructure base where ack will be executed.

Please check this link for architecture reference.

Step 1.

In this step you need to deploy a cluster of k8s and all that necessary for that cluster work. For a better brevity, the code is shared in this repository.

segoja7 / ack_controller_demo

Step 2.

With the eks cluster in this case running you need to install the controller inside the cluster, in this opportunity is used helm with the provider of terraform. Check the code. Aditional you need to create a service account with least privileges permissions, in this case our controller is for ec2, with a policy of ec2 is enough and the name of namespace.

module "ack-role-for-service-accounts-eks" {

  source  = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
  version = "5.39.1"

  role_name        = local.workspace["role_name"]
  role_policy_arns = local.workspace["role_policy_arns"]

  oidc_providers = local.workspace["oidc_providers"]

  tags = merge(
    var.required_tags,
    local.workspace["tags"]
  )
}

      role_policy_arns = {
        policy = "arn:aws:iam::aws:policy/AmazonEC2FullAccess"
      }

      oidc_providers = {
        ex = {
          provider_arn               = var.oidc_provider_arn
          namespace_service_accounts = ["ack-system:ack-ec2-controller"]
        }
      }

Step 3.

With the service account created, It is time to deploy the controller, in this case an ec2 controller.

module "eks-blueprints-addons" {
  source  = "aws-ia/eks-blueprints-addons/aws"
  version = "1.16.2"

  cluster_name      = local.workspace["cluster_name"]
  cluster_endpoint  = local.workspace["cluster_endpoint"]
  cluster_version   = local.workspace["cluster_version"]
  oidc_provider_arn = local.workspace["oidc_provider_arn"]
  helm_releases     = local.workspace["helm_releases"]
}

      helm_releases = {
        ec2-controller= {
          name                = "ec2-controller"
          description         = "A Helm chart for ack ec2-controller"
          repository_username = data.aws_ecrpublic_authorization_token.token.user_name
          repository_password = data.aws_ecrpublic_authorization_token.token.password
          namespace           = "ack-system"
          chart_version       = "1.2.12"
          chart               = "ec2-chart"
          create_namespace    = true
          repository          = "oci://public.ecr.aws/aws-controllers-k8s"
          values = [templatefile("./helm-charts/ack_ec2_controller/values.yaml", {
            role-arn = var.role_arn_controller
            region   = "us-east-1"
          })]
        }
      }

Step 4.

Validating controller.

remember that this controller have permissions all this resources, not only ec2 instances. :D

Step 5.

With the controller running without problems, now it is possible to create resources. For that there is the following raw manifest.

apiVersion: ec2.services.k8s.aws/v1alpha1
kind: Instance
metadata:
  name: segoja7-ack
spec:
  imageID: ami-023c11a32b0207432
  instanceType: t3.micro
  subnetID: subnet-0365ed0ebddcdb2a0
  tags:
    - key: ManagedBy
      value: ec2-controller
    - key: Name
      value: segoja7-ack

Conclusion: In this demo, It is demonstrated how to deploy an ack controller, in this case for ec2 service, create a role with permissions for the service account and deploy the resource from eks.

Thanks for reading this post, let me know if you have any question or comment.

Test

Javier Sepúlveda — Tue, 25 Jun 2024 20:34:05 +0000

Test