Deprecate KubernetesApplication

[negz]

What problem are you facing?

Crossplane uses a KubernetesApplication to schedule and deploy arbitrary resources to a 'remote' Kubernetes cluster - specifically to a KubernetesTarget. KubernetesApplication is so named because we originally envisioned that it would be an application model, but it has since become more of a "behind the scenes" delivery mechanism used by higher level application models - it's a little like a ReplicaSet to a Kubernetes Deployment. The Application name is misleading.

How could Crossplane help solve your problem?

Crossplane should at least rename KubernetesApplication and the underlying KubernetesApplicationResource kind, which represents an individual component of a "Kubernetes application".

I suggest we consider going one step further and removing or rethinking KubernetesApplication altogether. A KubernetesApplication is basically an array of opaque Kubernetes resources. Each of these resources is rendered to a KubernetesApplicationResource, which must be updated when the KubernetesApplication is updated. This has proven problematic and confusing to maintain due to the quirks of Kubernetes update and patch or "apply" semantics.

The only real value a KubernetesApplication adds is that it acts as a logical grouping of Kubernetes resources that should all be scheduled to a particular cluster. We might consider removing KubernetesApplication altogether and instead scheduling higher level app concepts like OAM AppConfigs, or we might take the approach I proposed in my original design (#399) and make KubernetesApplication a simple scheduling target that matches a bunch of KARs by label, but does not actually template and render those KARs.

[wonderflow]

I think users will glad to see KubernetesApplication being OAM ContainerizedWorkload + ClusterScope.

OAM AppConfig is the Application layer of Crossplane, we can use OAM concepts to accomplish this target. Then users don't need to learn one more concept.

Besides automatically schedule cluster(cloud provider), we can do more on ClusterScope.

[negz]

I think one consideration there @wonderflow is that we might want a lower level construct to schedule. For example if we ended up with multiple kinds of workload that could be scheduled to a remote cluster, we'd probably want a single type for the scheduler to work with.

[wonderflow]

Yes, in my view, the scheduler can only work with the ClusterScope type. Do you mean that? @negz

[muvaf]

I believe #1617 removes the need for workload scheduling API. @negz do you want to keep this issue open to track actual deprecation & removal?

[negz]

@negz do you want to keep this issue open to track actual deprecation & removal?

Yes please. We should make sure to at least add comments to the CRDs letting folks know they'll be removed in a few releases.

[negz]

I just realised that we've effectively aligned on deprecating KubernetesApplication, but haven't actually communicated that yet. We should add a note to the types so that https://doc.crds.dev/github.com/crossplane/crossplane/workload.crossplane.io/KubernetesApplication/v1alpha1 indicates the deprecation.

[turkenh]

I made a quick POC of provider-kubernetes which could provide the same functionality around new concepts, i.e. usable inside a composition.
This would be useful together with provider-helm in case it does not make sense to build a helm chart just to deploy some Kubernetes resources (e.g. just want to create a namespace but nothing else).

[negz]

Fixed by #1720