gtexec (General Task Executor)

This repository implements a simple controller for watching gtexec resources as defined with a CustomResourceDefinition (CRD).

Note: go-get or vendor this package as github.com/samuel-sujith/gtexec.

This particular example demonstrates how to perform basic operations such as:

• How to register a new custom resource (custom resource type) of type Foo using a CustomResourceDefinition.
• How to create/get/list instances of your new resource type Foo.
• How to setup a controller on resource handling create/update/delete events.

It makes use of the generators in k8s.io/code-generator to generate a typed client, informers, listers and deep-copy functions. You can do this yourself using the ./hack/update-codegen.sh script.

The update-codegen script will automatically generate the following files & directories:

• pkg/apis/samplecontroller/v1alpha1/zz_generated.deepcopy.go
• pkg/generated/

Changes should not be made to these files manually, and when creating your own controller based off of this implementation you should not copy these files and instead run the update-codegen script to generate your own.

Fetch with godep

When NOT using go 1.11 modules, you can use the following commands.

go get -d github.com/samuel-sujith/gtexec
cd $GOPATH/src/github.com/samuel-sujith/gtexec
godep restore

When using go 1.11 modules

When using go 1.11 modules (GO111MODULE=on), issue the following commands --- starting in whatever working directory you like.

git clone https://github.com/samuel-sujith/gtexec.git
cd gtexec

Note, however, that if you intend to generate code then you will also need the code-generator repo to exist in an old-style location. One easy way to do this is to use the command go mod vendor to create and populate the vendor directory.

Running

Prerequisite: Since the sample-controller uses apps/v1 deployments, the Kubernetes cluster version should be greater than 1.9.

# assumes you have a working kubeconfig, not required if operating in-cluster
go build -o gtexec .
./gtexec -kubeconfig=$HOME/.kube/config

# create a CustomResourceDefinition
kubectl create -f artifacts/examples/crd.yaml

# create a custom resource of type Foo
kubectl create -f artifacts/examples/example-foo.yaml

# check deployments created through the custom resource
kubectl get deployments

Defining types

Each instance of your custom resource has an attached Spec, which should be defined via a struct{} to provide data format validation. In practice, this Spec is arbitrary key-value data that specifies the configuration/behavior of your Resource.

For example, if you were implementing a custom resource for a Database, you might provide a DatabaseSpec like the following:

type DatabaseSpec struct {
	Databases []string `json:"databases"`
	Users     []User   `json:"users"`
	Version   string   `json:"version"`
}

type User struct {
	Name     string `json:"name"`
	Password string `json:"password"`
}

Validation

To validate custom resources, use the CustomResourceValidation feature.

This feature is beta and enabled by default in v1.9.

Example

The schema in crd-validation.yaml applies the following validation on the custom resource: spec.replicas must be an integer and must have a minimum value of 1 and a maximum value of 10.

In the above steps, use crd-validation.yaml to create the CRD:

# create a CustomResourceDefinition supporting validation
kubectl create -f artifacts/examples/crd-validation.yaml

Subresources

Custom Resources support /status and /scale subresources as a beta feature in v1.11 and is enabled by default. This feature is alpha in v1.10 and to enable it you need to set the CustomResourceSubresources feature gate on the kube-apiserver:

--feature-gates=CustomResourceSubresources=true