**Help improve this page** 

To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page.

# kro considerations for EKS
<a name="kro-considerations"></a>

This topic covers important considerations for using the EKS Capability for kro, including when to use resource composition, RBAC patterns, and integration with other EKS capabilities.

## When to use kro
<a name="_when_to_use_kro"></a>

kro is designed for creating reusable infrastructure patterns and custom APIs that simplify complex resource management.

 **Use kro when you need to**:
+ Create self-service platforms with simplified APIs for application teams
+ Standardize infrastructure patterns across teams (database \$1 backup \$1 monitoring)
+ Manage resource dependencies and pass values between resources
+ Build custom abstractions that hide implementation complexity
+ Compose multiple ACK resources into higher-level building blocks
+ Enable GitOps workflows for complex infrastructure stacks

 **Don’t use kro when**:
+ Managing simple, standalone resources (use ACK or Kubernetes resources directly)
+ You need dynamic runtime logic (kro is declarative, not imperative)
+ Resources don’t have dependencies or shared configuration

kro excels at creating "paved paths" - opinionated, reusable patterns that make it easy for teams to deploy complex infrastructure correctly.

## RBAC patterns
<a name="_rbac_patterns"></a>

kro enables separation of concerns between platform teams who create ResourceGraphDefinitions and application teams who create instances.

### Platform team responsibilities
<a name="_platform_team_responsibilities"></a>

Platform teams create and maintain ResourceGraphDefinitions (RGDs) that define custom APIs.

 **Permissions needed**:
+ Create, update, delete ResourceGraphDefinitions
+ Manage underlying resource types (Deployments, Services, ACK resources)
+ Access to all namespaces where RGDs will be used

 **Example ClusterRole for platform team**:

```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: platform-kro-admin
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["*"]
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
```

For detailed RBAC configuration, see [Configure kro permissions](kro-permissions.md).

### Application team responsibilities
<a name="_application_team_responsibilities"></a>

Application teams create instances of custom resources defined by RGDs without needing to understand the underlying complexity.

 **Permissions needed**:
+ Create, update, delete instances of custom resources
+ Read access to their namespace
+ No access to underlying resources or RGDs

 **Benefits**:
+ Teams use simple, high-level APIs
+ Platform teams control implementation details
+ Reduced risk of misconfiguration
+ Faster onboarding for new team members

## Integration with other EKS capabilities
<a name="_integration_with_other_eks_capabilities"></a>

### Composing ACK resources
<a name="_composing_ack_resources"></a>

kro is particularly powerful when combined with ACK to create infrastructure patterns.

 **Common patterns**:
+  **Application with storage**: S3 bucket \$1 SQS queue \$1 notification configuration
+  **Database stack**: RDS instance \$1 parameter group \$1 security group \$1 Secrets Manager secret
+  **Networking**: VPC \$1 subnets \$1 route tables \$1 security groups \$1 NAT gateways
+  **Compute with storage**: EC2 instance \$1 EBS volumes \$1 IAM instance profile

kro handles dependency ordering, passes values between resources (like ARNs and connection strings), and manages the full lifecycle as a single unit.

For examples of composing ACK resources, see [ACK concepts](ack-concepts.md).

### GitOps with Argo CD
<a name="_gitops_with_argo_cd"></a>

Use the EKS Capability for Argo CD to deploy both RGDs and instances from Git repositories.

 **Repository organization**:
+  **Platform repo**: Contains ResourceGraphDefinitions managed by platform team
+  **Application repos**: Contain instances of custom resources managed by app teams
+  **Shared repo**: Contains both RGDs and instances for smaller organizations

 **Considerations**:
+ Deploy RGDs before instances (Argo CD sync waves can help)
+ Use separate Argo CD Projects for platform and application teams
+ Platform team controls RGD repository access
+ Application teams have read-only access to RGD definitions

For more on Argo CD, see [Working with Argo CD](working-with-argocd.md).

## Organizing ResourceGraphDefinitions
<a name="_organizing_resourcegraphdefinitions"></a>

Organize RGDs by purpose, complexity, and ownership.

 **By purpose**:
+  **Infrastructure**: Database stacks, networking, storage
+  **Application**: Web apps, APIs, batch jobs
+  **Platform**: Shared services, monitoring, logging

 **By complexity**:
+  **Simple**: 2-3 resources with minimal dependencies
+  **Moderate**: 5-10 resources with some dependencies
+  **Complex**: 10\$1 resources with complex dependencies

 **Naming conventions**:
+ Use descriptive names: `webapp-with-database`, `s3-notification-queue` 
+ Include version in name for breaking changes: `webapp-v2` 
+ Use consistent prefixes for related RGDs: `platform- `, `app-` 

 **Namespace strategy**:
+ RGDs are cluster-scoped (not namespaced)
+ Instances are namespaced
+ Use namespace selectors in RGDs to control where instances can be created

## Versioning and updates
<a name="_versioning_and_updates"></a>

Plan for RGD evolution and instance migration.

 **RGD updates**:
+  **Non-breaking changes**: Update RGD in place (add optional fields, new resources with includeWhen)
+  **Breaking changes**: Create new RGD with different name (webapp-v2)
+  **Deprecation**: Mark old RGDs with annotations, communicate migration timeline

 **Instance migration**:
+ Create new instances with updated RGD
+ Validate new instances work correctly
+ Delete old instances
+ kro handles underlying resource updates automatically

 **Best practices**:
+ Test RGD changes in non-production environments first
+ Use semantic versioning in RGD names for major changes
+ Document breaking changes and migration paths
+ Provide migration examples for application teams

## Validation and testing
<a name="_validation_and_testing"></a>

Validate RGDs before deploying to production.

 **Validation strategies**:
+  **Schema validation**: kro validates RGD structure automatically
+  **Dry-run instances**: Create test instances in development namespaces
+  **Integration tests**: Verify composed resources work together
+  **Policy enforcement**: Use admission controllers to enforce organizational standards

 **Common issues to test**:
+ Resource dependencies and ordering
+ Value passing between resources (CEL expressions)
+ Conditional resource inclusion (includeWhen)
+ Status propagation from underlying resources
+ RBAC permissions for instance creation

## Upstream documentation
<a name="_upstream_documentation"></a>

For detailed information on using kro:
+  [Getting Started with kro](https://kro.run/docs/guides/getting-started) - Creating ResourceGraphDefinitions
+  [CEL Expressions](https://kro.run/docs/concepts/cel) - Writing CEL expressions
+  [kro Guides](https://kro.run/docs/guides/) - Advanced composition patterns
+  [Troubleshooting](https://kro.run/docs/troubleshooting) - Troubleshooting and debugging

## Next steps
<a name="_next_steps"></a>
+  [Configure kro permissions](kro-permissions.md) - Configure RBAC for platform and application teams
+  [kro concepts](kro-concepts.md) - Understand kro concepts and resource lifecycle
+  [Troubleshoot issues with kro capabilities](kro-troubleshooting.md) - Troubleshoot kro issues
+  [ACK concepts](ack-concepts.md) - Learn about ACK resources for composition
+  [Working with Argo CD](working-with-argocd.md) - Deploy RGDs and instances with GitOps