tahsinrahman/cluster-api

Home for the Cluster Management API work, a subproject of sig-cluster-lifecycle

Cluster API

• What is the Cluster API?
• Getting Started
  • Resources
  • Prerequisites
  • Using clusterctl to create a cluster
  • How does Cluster API compare to Kubernetes Cloud Providers?
• Get involved!
• Provider Implementations
• API Adoption

What is the Cluster API?

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.

Getting Started

Resources

• GitBook: cluster-api.sigs.k8s.io

Prerequisites

• kubectl is required, see here.
• clusterctl is a SIG-cluster-lifecycle sponsored tool to manage Cluster API clusters. See here

Using clusterctl to create a cluster

• 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.

Get involved!

• 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

  • Weekly on Tuesdays @ 12:00 PT (Zoom) and Wednesdays @ 15:00 CET (Zoom)
  • Previous meetings: [ notes ]

• Chat with us on Slack: #cluster-api

Provider Implementations

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

API Adoption

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

Versioning, Maintenance, and Compatibility

• 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.