Machine API Operator

The Machine API Operator manages the lifecycle of specific purpose CRDs, controllers and RBAC objects that extend the Kubernetes API. This allows to convey desired state of machines in a cluster in a declarative fashion.

See https://github.com/openshift/enhancements/tree/master/enhancements/machine-api for more details.

Have a question? See our Frequently Asked Questions for common inquiries.

Architecture

CRDs

MachineSet
Machine
MachineHealthCheck

Controllers

MachineSet Controller

Ensure presence of expected number of replicas and a given provider config for a set of machines.
Machine Controller

Ensure that a provider instance is created for a Machine object in a given provider.
Nodelink Controller

Ensure machines have a nodeRef based on IPs or providerID matching. Annotate nodes with a label containing the machine name.
MachineHealthCheck Controller

Ensure machines targeted by MachineHealthCheck objects satisfy a healthiness criteria or are remediated otherwise.

Creating machines

You can create a new machine by applying a manifest representing an instance of the machine CRD

The machine.openshift.io/cluster-api-cluster label will be used by the controllers to lookup for the right cloud instance.

You can set other labels to provide a convenient way for users and consumers to retrieve groups of machines:

machine.openshift.io/cluster-api-machine-role: worker
machine.openshift.io/cluster-api-machine-type: worker

Dev

Generate code (if needed):
```
$ make generate
```
Build:
```
$ make build
```
Run:

Extract images.json to a file from install/0000_30_machine-api-operator_01_images.configmap.yaml and run:
```
$ ./bin/machine-api-operator start --kubeconfig ${HOME}/.kube/config --images-json=path/to/images.json
```
Image:
```
$ make image
```

The Machine API Operator is designed to work in conjunction with the Cluster Version Operator. You can see it in action by running an OpenShift Cluster deployed by the Installer.

However you can run it in a vanilla Kubernetes cluster by precreating some assets:

Create a openshift-machine-api namespace
Create a CRD Status definition
Create a CRD Machine definition
Create a CRD MachineSet definition
Create a Installer config
Then you can run it as a deployment
You should then be able to deploy a machineSet object

For more information see hacking-guide.

Machine API operator with Kubemark over Kubernetes

INFO: For development and testing purposes only

Deploy MAO over Kubernetes:

 $ kustomize build | kubectl apply -f -

Deploy Kubemark actuator prerequisities:

$ kustomize build config | kubectl apply -f -

Create cluster infrastructure.config.openshift.io to tell the MAO to deploy kubemark provider:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: infrastructures.config.openshift.io
spec:
  group: config.openshift.io
  names:
    kind: Infrastructure
    listKind: InfrastructureList
    plural: infrastructures
    singular: infrastructure
  scope: Cluster
  versions:
  - name: v1
    served: true
storage: true
---
apiVersion: config.openshift.io/v1
kind: Infrastructure
metadata:
  name: cluster
status:
  platform: kubemark

The file is already present under config/kubemark-config-infra.yaml so it's sufficient to run:

$ kubectl apply -f config/kubemark-config-infra.yaml

OpenShift Bugzilla

The Bugzilla product for this repository is "Cloud Compute" under OpenShift Container Platform.

CI & tests

Run unit test:

$ make test

Run e2e-aws-operator tests. This tests assume that a cluster deployed by the Installer is up and running and a KUBECONFIG environment variable is set:

$ make test-e2e

Tests are located under machine-api-operator repository and executed in prow CI system. A link to failing tests is published as a comment in PR by @openshift-ci-robot. Current test status for all OpenShift components can be found in https://deck-ci.svc.ci.openshift.org.

CI configuration is stored under openshift/release repository and is split into 4 files:

cluster/ci/config/prow/plugins.yaml - says which prow plugins are available and where job config is stored
ci-operator/config/openshift/machine-api-operator/master.yaml - configuration for machine-api-operator component repository
ci-operator/jobs/openshift/machine-api-operator/openshift-machine-api-operator-master-presubmits.yaml - prow jobs configuration for presubmits
ci-operator/jobs/openshift/machine-api-operator/openshift-machine-api-operator-master-postsubmits.yaml - prow jobs configuration for postsubmits

More information about those files can be found in ci-operator onboarding file.

elmiko/machine-api-operator