Skip to content

Instantly share code, notes, and snippets.

@thebsdbox
Last active October 27, 2019 17:00
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save thebsdbox/fec25caee1fed30f222d7e8f1eebec65 to your computer and use it in GitHub Desktop.
Save thebsdbox/fec25caee1fed30f222d7e8f1eebec65 to your computer and use it in GitHub Desktop.
# Details for building the repository
PROVIDER=cluster-api-provider-plunder
mkdir $PROVIDER
cd $PROVIDER
echo Create the initial repository for $PROVIDER
git init
echo Initialise a basic layout
GO111MODULE=on /usr/local/kubebuilder/bin/kubebuilder init --domain cluster.x-k8s.io --license apache2 --owner "The Kubernetes Authors"
git add .
git commit -m "Generate the basic layout for $PROVIDER"
GO111MODULE=on /usr/local/kubebuilder/bin/kubebuilder create api --group infrastructure --resource=true --controller=true --version v1alpha1 --kind PlunderCluster
GO111MODULE=on /usr/local/kubebuilder/bin/kubebuilder create api --group infrastructure --resource=true --controller=true --version v1alpha1 --kind PlunderMachine
echo Moving the manager code to the correct location, and patching paths
mkdir -p cmd/manager
mv main.go cmd/manager
sed -i.bak 's/main.go/cmd\/manager\/main.go/'g Makefile
git add .
git commit -m "Generate $PROVIDER Cluster and Machine resources."
`main.go`
Add ` clusterv1 "sigs.k8s.io/cluster-api/api/v1alpha2"` to import(s)
Add ` _ = clusterv1.AddToScheme(scheme)` to `init()`
============= cluster
Add Finalizer to `<x>cluster_types.go`
```
const (
// ClusterFinalizer allows PlunderClusterReconciler to clean up resources associated with PlunderCluster before
// removing it from the apiserver.
ClusterFinalizer = "plundercluster.infrastructure.cluster.x-k8s.io"
)
```
Add additional fields to Status
```
// Ready denotes that the docker cluster (infrastructure) is ready.
Ready bool `json:"ready"`
// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
// Important: Run "make" to regenerate code after modifying this file
// APIEndpoints represents the endpoints to communicate with the control plane.
// +optional
APIEndpoints []APIEndpoint `json:"apiEndpoints,omitempty"`
```
Cluster specific endpoints
```
// APIEndpoint represents a reachable Kubernetes API endpoint.
type APIEndpoint struct {
// Host is the hostname on which the API server is serving.
Host string `json:"host"`
// Port is the port on which the API server is serving.
Port int `json:"port"`
}
```
@thebsdbox
Copy link
Author

Now you just need to write all the code...

@thebsdbox
Copy link
Author

thebsdbox commented Aug 14, 2019

Anatomy of a typical cluster-api provider folder structure

Note Not all providers follow the same structure but this is a good starting point for getting your head around where to look for things.

/api

This contains the variables and structures that are used to define various settings and configurations around the elements and that will typically be used to build the cluster

/cmp

manager contains all of the code for starting the lifecycle of the specific provider controller, it typically will add all of the relevant scheme (definitions and structures defined by the api) to Kubernetes.

cap{x}ctl if this exists it typically will contain code to further allow configuration of the provider (API details, load balancer config, initial set up steps).

/controller

Contains all of the code that defines the functionality of the controller itself. For cluster API there will be a reconciler (reconciliation loop/function) for both the cluster definition and the machine definition that is then provider specific.

/docs

(usually empty (bad joke)) - Here you should find all of the documentation that deals with the usage of the cluster-api provider

/object

If this exists it contains code that is used to generate various kubernetes objects such as the cluster-api provider definitions/objects that can then be applied to the Kubernetes API server. Code in here is typically used by the cap{x}ctl tool to "load" the cluster-api controller.

/provider

This /provider folder (usually named for the actual provider itself e.g. OpenStack or AWS) contains all of the code that the controller can use to actual to provide the provisioning capabilities:

  • Create / Delete a Node
  • Configure a node / cluster
  • Implement a load balancer etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment