Spinnaker Operator Architecture
Operators are software extensions to Kubernetes that make use of custom resources (CRD) to manage applications and their components. Operators follow Kubernetes principles, notably the control loop. Spinnaker Operator is deployed to a Kubernetes cluster as a new Deployment:
Its main components are the Validation Webhook Controller and Reconciler Controller.
The Validation Webhook Controller is used to perform validations and preflight checks before a SpinnakerService manifest file is accepted for processing. This is an example of trying to apply an invalid manifest:
$ k apply -f spinsvc.yaml
Error from server: error when creating "deploy/spinnaker/examples/basic/spinsvc.yaml": admission webhook "validating.k8s.io" denied the request: SpinnakerService must be unique per namespace
Note that Spinnaker Operator needs to be installed cluster wide as opposed to namespace scoped to be able to run its admission controller.
This controller continuously polls the Kubernetes API server, in order to watch for changes in operator managed resources like SpinnakerService resources, configurations, and all running Spinnaker Deployments. The purpose of the polling is to ensure that the current state of Spinnaker matches the desired state.
The Reconciler Controller consists of two main parts:
-
ChangeDetectors: These are responsible for comparing the current state of Spinnaker and the desired state. Desired state is taken from the manifest definitions of
SpinnakerServiceand its referenced ConfigMap or Secret. Current state is taken fromSpinnakerServicestatus and running Spinnaker Deployments and Services. -
Transformers: These perform 2 types of transformations:
- Transform Spinnaker configs: Transformers get a chance to make any modifications to config definitions before they are converted to Kubernetes manifests.
- Transform manifests: After Halyard generates all the manifests for Spinnaker services, transformers get a chance to make any modifications to them before being applied.