The Spinnaker Operator is a Kubernetes operator to deploy and manage Spinnaker using familiar tools. We're sharing it to let the community evaluate it and provide feedback. Please let us know what would make your life easier when installing Spinnaker! You can use GitHub issues for the time being.
- Stop using Halyard commands: just
kubectl apply
your Spinnaker configuration. This includes support for local files. - Expose Spinnaker to the outside world (via
LoadBalancer
). You can still disable that behavior if you prefer to manage ingresses and LBs yourself. - Deploy any version of Spinnaker. Operator is not tied to a particular version of Spinnaker.
- Keep secrets separate from your config. Store your config in
git
and have an easy Gitops workflow. - Validate your configuration before applying it (by using kubernetes's webhook validation).
- Store Spinnaker secrets in Kubernetes secrets.
- Patch versions, accounts or any setting with
kustomize
. - Monitor the health of Spinnaker through
kubectl
. - Store kubeconfig inline, in Kubernetes secrets, in S3, or GCS.
- Define Kubernetes accounts in
SpinnakerAccount
objects [experimental] - Total control over generated manifests with inline kustomization
The validating admission controller requires:
- Kubernetes server v1.13+
- Admission controllers enabled (
-enable-admission-plugins
) ValidatingAdmissionWebhook
enabled in the kube-apiserver (should be the default)
Note: If you can't use the validation webhook, pass the --disable-admission-controller
to the operator (like in deploy/operator/basic/deployment.yaml
).
This is a high-level view of the commands you need to run for those who want to jump right in. More explanation can be found in the sections after this one.
# Pick a release from https://github.com/armory/spinnaker-operator/releases (or clone the repo and use the master branch for the latest development work)
$ mkdir -p spinnaker-operator && cd spinnaker-operator
$ bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'
# Install or update CRDs cluster wide
$ kubectl apply -f deploy/crds/
# Install operator in namespace spinnaker-operator, see below if you want a different namespace
$ kubectl create ns spinnaker-operator
$ kubectl -n spinnaker-operator apply -f deploy/operator/cluster
# Update deploy/spinnaker/basic/spinnakerservice.yml to change Spinnaker's persistence bucket name to a unique name (persistentStorage.s3.bucket value)
# Install Spinnaker in "spinnaker" namespace
$ kubectl create ns spinnaker
$ kubectl -n spinnaker apply -f deploy/spinnaker/basic
# Watch the install progress, check out the pods being created too!
$ kubectl -n spinnaker get spinsvc spinnaker -w
The Spinnaker Operator introduces a new CRD for Spinnaker accounts. A SpinnakerAccount
is defined in an object -- separate
from the main Spinnaker config -- so creation and maintenance can easily be automated.
The long term goal is to support all accounts (providers, CI, notifications, ...), but the first implementation deals with Kubernetes accounts.
Account type | Status |
---|---|
Kubernetes |
alpha |
Read more at Spinnaker accounts.
Download CRDs and example manifests from the latest stable release.
CRD and examples on master
are unstable and subject to change, but feedback is greatly appreciated.
First, we'll install the SpinnakerService
and SpinnakerAccount
CRDs:
$ mkdir -p spinnaker-operator && cd spinnaker-operator
$ tar -xvf manifests.tgz .
$ kubectl apply -f deploy/crds/
Note: SpinnakerAccount
CRD is optional.
There are two modes for the operator:
- Basic mode installs Spinnaker in a single namespace without validating admission webhook.
- Cluster mode works across namespaces and requires a
ClusterRole
to perform validation.
The main difference between the two modes is that basic only requires a Role
(vs a ClusterRole
) and has no validating webhook.
Once installed, you should see a new deployment representing the operator. The operator watches for changes to the SpinnakerService
objects. You can check on the status of the operator using kubectl
.
To install Operator run:
$ kubectl apply -n <namespace> -f deploy/operator/basic
namespace
is the namespace where you want the operator to live and deploy to.
To install Operator:
- Decide what namespace you want to use for Operator and create that namespace. We suggest
spinnaker-operator
. - If you pick a different namespace than
spinnaker-operator
, edit the namespace indeploy/operator/cluster/role_binding.yml
. - Run:
$ kubectl apply -n spinnaker-operator -f deploy/operator/cluster
If you use a namespace other than spinnaker-operator
, replace spinnaker-operator
with your namespace.
Once you've installed CRDs and Operator, check out examples in deploy/spinnaker/
. Below, the
spinnaker-namespace
parameter refers to the namespace where you want to install
Spinnaker. It is likely different from the operator's namespace.
In deploy/spinnaker/basic/spinnakerservice.yml
, change the config.persistentStorage
section to point to an S3 bucket you own or use a different persistent storage. Also make sure to update the Spinnaker version to the desired version.
$ kubectl create ns <spinnaker-namespace>
$ kubectl -n <spinnaker-namespace> apply -f deploy/spinnaker/basic/spinnakerservice.yml
This configuration does not contain any connected accounts, just a persistent storage.
You'll find a more complete example under deploy/spinnaker/complete/spinnakerservice.yml
with all parameters available.
Set your own values in deploy/spinnaker/kustomize/kustomization.yml
, then:
$ kubectl create ns <spinnaker-namespace>
$ kustomize build deploy/spinnaker/kustomize/ | kubectl -n <spinnaker-namespace> apply -f -
See the Armory Operator Plugins reference and the pf4jStagePlugin Deployment Using the Armory Operator guide.
See how to migrate from Halyard to Spinnaker Operator.
See all SpinnakerService options.
See this section.