API

In Cluster API, API resources are defined using Kubernetes Custom Resources (CRD).

The API defines the main contract with the Cluster API users. This makes API design a critical part of Cluster API development and usually:

• Breaking/major API changes should go through the CAEP process and be strictly synchronized with the major release cadence.
• Non-breaking/minor API changes can go in minor releases; non-breaking changes are generally:
  • additive in nature
  • default to pre-existing behavior
  • optional as part of the API contract

Kubernetes API guidelines

This project follows the Kubernetes API conventions.

We enforce the API conventions via kube-api-linter. The corresponding configuration field can be found here.

API versioning and guarantees are inspired by the Kubernetes deprecation policy and API change guidelines.

Other considerations

Following considerations should apply when working to API changes in this project:

• CRD relations allows to model the entire set of objects in a cluster, including also provider’s objects
• Owner references are the foundation of several internal processes
• Metadata propagation defines how metadata propagates across API kinds
• Printer columns guidelines