How do you use Crossplane Composition Functions (KCL, Go templates)?

Crossplane Composition Functions represent a paradigm shift from the declarative patch-based Composition model to a programmable pipeline architecture. While patches handle simple field mapping well, real-world infrastructure for services like the payments-api or order-processing-service often requires conditional logic, loops, string manipulation, and data lookups that become unwieldy with dozens of nested patch transforms. Composition Functions solve this by letting platform teams write actual programs that receive the composite resource as input and return a list of desired composed resources as output, running as gRPC servers inside containers that the Crossplane runtime calls during each reconciliation cycle.

The Composition Function pipeline is defined in the Composition spec under the pipeline field, replacing the traditional resources array. Each step in the pipeline references a Function custom resource that points to a container image. The pipeline executes sequentially, with each function receiving the output of the previous step plus the original composite resource. The function-kcl step might generate the base resources, then a function-auto-ready step automatically sets readiness checks, and finally a function-cel-filter step validates that the output meets organizational policies. This pipeline architecture is composable itself, meaning platform teams can mix and match functions from the Crossplane community with custom functions built in-house.

KCL (Kusion Configuration Language) is one of the most popular function languages for Crossplane because it is purpose-built for configuration with strong typing, schema validation, and a familiar Python-like syntax. A KCL function for the checkout-service infrastructure can define a schema that validates input parameters, use conditional expressions to set different resource configurations per environment, iterate over a list of regions to create multi-region resources, and compute derived values like CIDR ranges from a base network address. The function-kcl runtime accepts KCL source code directly in the Composition through an inline source field or references external KCL packages from an OCI registry. When the inventory-sync team submits a claim requesting a multi-region cache, the KCL function generates ElastiCache clusters in each requested region, creates the replication group linking them, and sets up the appropriate security groups with computed CIDR rules.

Go template functions use the familiar Go text/template syntax that Helm users already know, making them an accessible entry point for teams transitioning from Helm-based infrastructure to Crossplane. The function-go-templating runtime renders Go templates with the composite resource available as a data context, supporting Sprig functions for string manipulation, math operations, and encoding. However, Go templates lack type safety and can produce subtle YAML formatting errors, so they are better suited for simpler compositions where KCL or a custom Go function would be overengineered. For the user-auth-service team, a Go template function might generate a standard set of IAM roles and policies based on the service name and environment, using range to iterate over a list of AWS actions and if conditions to add extra permissions for production environments.

Custom Go functions provide the most flexibility when KCL or Go templates are insufficient. Teams write a Go program implementing the Crossplane function SDK's RunFunction interface, build it into a container image, and reference it as a Function resource. The payments-api platform team might write a custom function that queries an internal service catalog API to look up compliance requirements, generates resources based on those requirements, and injects organization-specific annotations and labels. The function SDK provides helper methods for reading the composite resource, building desired resources, setting conditions, and returning results. Testing is done using the crossplane beta render command, which simulates the function pipeline locally and outputs the rendered resources without connecting to any cloud provider, enabling fast iteration during development.