Deprecation & Promotion Notice 🚀

[rushmash91]

Overview

As part of ACK's evolution towards more robust and maintainable solutions, we are announcing the deprecation of two key Custom Resource Definitions (CRDs):

• AdoptedResource CRD - Being replaced by annotation-based ResourceAdoption

Timeline

Phase	Date	Description
Announcement & Beta	July 31, 2025	Official deprecation announcement, alternative features promoted to Beta
Changed Defaults	Aug 31, 2025	Deprecated features are turned off by default
Removal & GA	October 31, 2025	Deprecated features completely removed AND alternative features graduate to GA

What's Changing

Deprecations Overview

Feature	Status	Replacement	Migration Resources
AdoptedResource CRD	Deprecated (Default off) Removal: Oct 31, 2025	ResourceAdoption via annotations	• AdoptedResource docs • ResourceAdoption docs

Features Moving to GA

The following features were promoted to Beta in July 2025 and are graduating to General Availability (GA) status in October 2025:

Feature	Current Status	Next Milestone	Info
ResourceAdoption	Beta (July 2025)	GA: October 2025	Replacement for AdoptedResource CRD
ReadOnlyResources	Beta (July 2025)	GA: October 2025	-

Migration Actions Required

For AdoptedResource Users:

1. Audit your current AdoptedResource usage:

   kubectl get adoptedresources --all-namespaces

2. Change deletion policy to retain

3. Convert AdoptedResource manifests to annotation-based ResourceAdoption

4. Test adoption functionality in development environments

5. Migrate production workloads before October 31, 2025

6. Remove AdoptedResource CRDs after migration

Getting Help

Documentation

• ResourceAdoption Feature Documentation
• KRO Documentation

Community Support

• Slack: Join #aws-controllers-k8s on Kubernetes Slack
• Discussions: ACK Community Discussions
• Issues: File migration questions in this repository

[arichtman]

Hi all - thanks for ACK so far!

We rely on FieldExport to allow the Kubernetes control plane to be aware of cross-resource "wiring". For example, RDS address/port/username -> Secret -> Pod for consumption. This allows us to enjoy benefits of the rendered manifests pattern but also have dynamic, self-correcting infrastructure.

Kro can achieve this individual case at the cost of adding a CRD to the API server, but I'm concerned about how it composes.

If we want the above, and also a pod that has the above RDS and an SQS queue, with Kro the options are:

• ResourceGraphDefinition for just RDS+Pod, ResourceGraphDefinition for RDS+SQS+Pod
• ResourceGraphDefinition for RDS+Pod, ResourceGraphDefinition for SQS+(the previous ResourceGraphDefinition's CRD)

Now what for a pod that just wants SQS? We need another ResourceGraphDefinition, and another dedicated CRD.
With FieldExport we can avoid CRD blowout, and handle composition in the manifest inflation process (e.g. Helm).

I've been developing a controller that feeds on ConfigMaps as input and allows patching values into arbitrary Kubernetes resources. We wanted to use it to wire up stuff like acm.services.k8s.aws/v1alpha1/Certificate's status.domainValidations.resourceRecord -> route53.services.k8s.aws/v1alpha1/RecordSet's spec.resourceRecords. This sample CR hopefully demonstrates the idea

FieldExport is a unique feature that allows me to sidestep having to do dynamic watches for inputs. I recognize this is an extremely niche concern though - and if Kro's DynamicController gets published as mooted it may solve this issue for me.

[alagukannan]

I use fieldExports CRD to export data to configmaps and secrets for use by K8s workloads. An example is we export the OIDC endpoint for EKS server which our downstream apps make use of.
Also we use FieldExports to validate if a resource is actually created since the sync status on resource doesn't always reflect successful status.

Switching to Kro isn't an option for now since I'm not inclined to invest more resources in to a new tool outside of ACK.