Repository Naming
The naming convention for new Cluster API provider repositories
is generally of the form cluster-api-provider-${env}, where ${env} is a,
possibly short, name for the environment in question. For example
cluster-api-provider-gcp is an implementation for the Google Cloud Platform,
and cluster-api-provider-aws is one for Amazon Web Services. Note that an
environment may refer to a cloud, bare metal, virtual machines, or any other
infrastructure hosting Kubernetes. Finally, a single environment may include
more than one variant. So for example,
cluster-api-provider-aws may include both an implementation based on EC2 as
well as one based on their hosted EKS solution.
For the purposes of this guide we will create a fictional provider for a
cloud provider named solas. Therefore the name of the repository will be
cluster-api-provider-solas.
Resource Naming
Every Kubernetes resource has a Group, Version and Kind that uniquely identifies it.
- The resource Kind is the short name of the API, for example,
SolasMachineSpecandSolasMachineStatuscould be the provider specific API forMachineresources. - The resource Version defines the stability of the API and its backward compatibility guarantees. Examples include v1alpha1, v1beta1, v1, etc. and are governed by the Kubernetes API Deprecation Policy 1.
- The resource Group is similar to package in a language. It disambiguates
different APIs that may happen to have identically named Kinds. Groups
often contain a domain name, such as k8s.io. The domain for Cluster API
resources is
cluster.k8s.io.
apiVersion: solas.cluster.k8s.io/v1alpha1
kind: SolasMachineSpec
apiVersion: solas.cluster.k8s.io/v1alpha1
kind: SolasMachineStatus
1. https://kubernetes.io/docs/reference/using-api/deprecation-policy/ ↩