Implementation best practices

Cluster API doesn’t define strict rules about how providers should implement controllers.

However, some best practice are worth to notice:

  • Infrastructure objects (e.g. load balancers, VMs etc) generated by the Infra providers SHOULD adopt a naming convention that directly links to the Kubernetes resource that originated those objects. Please note that in most cases external constraints might impact this decision, like e.g.

    • Differences in naming conversions from Kubernetes CRDs and the target infrastructure
    • The fact that the InfraCluster Kubernetes CRD is namespace-scoped while target infrastructure might have different approaches to grouping resources

  • Naming convention above should not be used and advertised as a contract to build on top. Instead more robust mechanism MUST always be provided and used for identifying objects, like tagging or labeling. Please note that this is necessary not only to prevent issues in case Cluster API changes default naming strategies for the Kubernetes objects generated by core controllers, but also to handle use cases where users intentionally influence Cluster API naming strategies.

  • Cluster API offers a great development environment based on Tilt, which can be easily extended to work with any provider. Use it! See Rapid iterative development with Tilt

  • Cluster API defines a set of best practices and standards that, if adopted, could speed up provider development and improve consistency with core Cluster API. See:

  • Cluster API implements a test framework that, if adopted, could help in ensuring the quality of the provider. See:

  • While standard security practices for developing Kubernetes controllers apply, it is important to recognize that given that infrastructure provider deal with cloud credentials and cloud infrastructure, there are additional critical security concern that must be addressed to ensure secure operations. See: