The Cluster API is a Kubernetes project to bring declarative, Kubernetes-style APIs to cluster creation, configuration, and management. It provides optional, additive functionality on top of core Kubernetes.
Note that Cluster API effort is still in the prototype stage while we get feedback on the API types themselves. All of the code here is to experiment with the API and demo its abilities, in order to drive more technical feedback to the API design. Because of this, all of the prototype code is rapidly changing.
- GitBook: cluster-api.sigs.k8s.io
kubectlis required, see here.clusterctlis a SIG-cluster-lifecycle sponsored tool to manage Cluster API clusters. See here
- Doc here
Learn more about the project's scope, objectives, goals and requirements, feature proposals and reference use cases.
How does Cluster API compare to Kubernetes Cloud Providers?
Cloud Providers and the Cluster API work in concert to provide a rich Kubernetes experience in cloud environments. The Cluster API initializes new nodes and clusters using available providers. Running clusters can then use Cloud Providers to provision support infrastructure like load balancers and persistent volumes.
-
Join the Cluster API discuss forum.
-
Join the sig-cluster-lifecycle Google Group for access to documents and calendars.
-
Join our Cluster API working group sessions
- Weekly on Wednesdays @ 10:00 PT on Zoom
- Previous meetings: [ notes | recordings ]
-
Provider implementer office hours
-
Chat with us on Slack: #cluster-api
The code in this repository is independent of any specific deployment environment. Provider specific code is being developed in separate repositories, some of which are also sponsored by SIG-cluster-lifecycle:
- AWS, https://github.com/kubernetes-sigs/cluster-api-provider-aws
- Azure, https://github.com/kubernetes-sigs/cluster-api-provider-azure
- Baidu Cloud, https://github.com/baidu/cluster-api-provider-baiducloud
- Bare Metal, https://github.com/metal3-io/cluster-api-provider-baremetal
- DigitalOcean, https://github.com/kubernetes-sigs/cluster-api-provider-digitalocean
- Exoscale, https://github.com/exoscale/cluster-api-provider-exoscale
- GCP, https://github.com/kubernetes-sigs/cluster-api-provider-gcp
- IBM Cloud, https://github.com/kubernetes-sigs/cluster-api-provider-ibmcloud
- OpenStack, https://github.com/kubernetes-sigs/cluster-api-provider-openstack
- Packet, https://github.com/packethost/cluster-api-provider-packet
- Talos, https://github.com/talos-systems/cluster-api-provider-talos
- Tencent Cloud, https://github.com/TencentCloud/cluster-api-provider-tencent
- vSphere, https://github.com/kubernetes-sigs/cluster-api-provider-vsphere
Following are the implementations managed by third-parties adopting the standard cluster-api and/or machine-api being developed here.
- Kubermatic machine-controller, https://github.com/kubermatic/machine-controller/tree/master
- Machine API Operator, https://github.com/openshift/machine-api-operator/tree/master
- Machine-controller-manager, https://github.com/gardener/machine-controller-manager/tree/cluster-api
- We follow Semantic Versioning (semver).
- Cluster API release cadence is Kubernetes Release + 6 weeks.
- The cadence is subject to change if necessary, refer to the Milestones page for up-to-date information.
- The master branch is where development happens, this might include breaking changes.
- The release-X branches contain stable, backward compatible code. A new release-X branch is created at every major (X) release.