Skip to main content

Spinnaker Operator

Simplified Spinnaker management using a GitOps workflow.

Overview

The Spinnaker Operator is a Kubernetes Operator for managing Spinnaker, built by Armory and available for free. It makes deploying and managing the full lifecycle of your Spinnaker app simple, automated, and reliable, leveraging a Kubernetes-native GitOps workflow. This represents a significant advance from the current tool for managing Spinnaker (Halyard), which involves significant manual processes and requires Spinnaker domain expertise.

In contrast, the Operator lets you treat Spinnaker as just another Kubernetes deployment, which makes installing and managing Spinnaker easy and reliable. The Operator unlocks the scalability of a GitOps workflow by defining Spinnaker configurations in a code repository rather than in hal commands. With the Operator you can leverage Kubernetes Secrets for secrets management, bring peer review and auditability to your manifests, and enable pre-flight validation for config changes.

Benefits

Automated Spinnaker Management

Spend less time managing Spinnaker and more time innovating.

  • Upgrade your Spinnaker version simply by changing one value in a file and applying it.
  • Enable Spinnaker to deploy itself when there are changes to configs or Spinnaker is in an unhealthy state.
  • Automatically expose Spinnaker via load balancers instead of detailed manual setups.

Kubernetes-native Tools

Kubernetes-native management of Spinnaker and access to powerful Kubernetes features.

  • Instead of learning how to use Halyard, use kubectl and kustomize to install and manage Spinnaker.
  • Store Spinnaker secrets in Kubernetes Secrets.
  • Validate your Spinnaker configurations before applying them. 

GitOps Workflows

Bring Spinnaker into your GitOps workflow by managing all configs through Git.

  • Centralize all of your Spinnaker configurations and manage them in a single Git repo.
  • Enable collaborative code reviews on config changes to ensure that Spinnaker is stable and secure.
  • Built-in config version control allows rapid rollbacks and easy auditability in the event of a bad update.
“We’ve loved using the Spinnaker Operator. To begin with, the migration from Helm charts to the Spinnaker Operator was painless. Now that we have migrated, we have zero need to use Halyard scripts for advanced configurations, and the declarative syntax of the Operator is much more expressive and testable. The Operator has also taken all of the effort out of upgrading Spinnaker to the latest version - all we have to do is change one value in the CRD. The Operator webhook prevents syntax errors from bringing down productive services, and the Halyard configuration simplifies debugging and enables us to automate configuration through templating. Overall, it has been a game changer for us in how we manage Spinnaker.”
Jonathan Hatalla, Lead Infrastructure Engineer at Salesforce Einstein

How the Operator Works

With the Spinnaker Operator, define all the configurations of Spinnaker in native Kubernetes manifest files, as part of the Kubernetes kind “SpinnakerService,” defined in its own Custom Resource Definition (CRD). With this approach, you can customize, save, deploy, and generally manage Spinnaker configurations in a standard Kubernetes workflow for managing manifests. No need to learn a new CLI like Halyard, or worry about how to run that service.

The Spinnaker Operator has two flavors to choose from, depending on which Spinnaker you want to use: Open Source or Armory.

With the Spinnaker Operator, you can:

  • Use “kubectl” to install and configure a brand new Spinnaker (OSS or Armory).
  • Take over an existing Spinnaker installation deployed by Halyard and continue managing it with the Operator going forward.
  • Use Kustomize or Helm Charts to manage different Spinnaker installations.
  • Use Spinnaker profile files to provide service-specific configuration overrides (the equivalent of clouddriver-local.yml, gate-local.yml, etc.)
  • Use Spinnaker service settings files to tweak the way Deployment manifests for Spinnaker microservices are generated.
  • Use any raw files needed by configs in the SpinnakerService manifest (i.e. packer templates, support config files, etc.)
  • Safely store secret-free manifests under source control, since a SpinnakerService manifest can contain references to secrets stored in S3, GCS or Vault (Vault is Armory only).

Additionally, Spinnaker Operator has some exclusive new features not available with other deployment methods like Halyard:

  • Spinnaker secrets can be read from Kubernetes secrets.
  • Spinnaker is automatically exposed with Kubernetes service load balancers (optional).
  • Generated Kubernetes manifests for Spinnaker services can be fully customized by json patches as part of SpinnakerService configuration.

Experimental: Accounts can be provisioned and validated individually by using a different SpinnakerAccount manifest, so that adding new accounts involves creating a new manifest instead of having everything in a single manifest.

Example Workflow

Assuming you have stored SpinnakerService manifests under source control, you have a pipeline in Spinnaker to apply these manifests automatically on source control pushes (Spinnaker deploying Spinnaker) and you want to add a new Kubernetes account:

  1. Save the kubeconfig file of the new account in a Kubernetes secret, in the same namespace where Spinnaker is installed.
  2. Checkout Spinnaker config repository from source control.
  3. Add a new Kubernetes account to the SpinnakerService manifest file, referencing the kubeconfig in the secret: 
    apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    config:
      version: 2.17.1   # the version of Spinnaker to be deployed
      persistentStorage:
        persistentStoreType: s3
        s3:
          bucket: acme-spinnaker
          rootFolder: front50
+      providers:
+        kubernetes:
+          enabled: true
+          accounts:
+          - name: kube-staging
+            requiredGroupMembership: []
+            providerVersion: V2
+            permissions: {}
+            dockerRegistries: []
+            configureImagePullSecrets: true
+            cacheThreads: 1
+            namespaces: []
+            omitNamespaces: []
+            kinds: []
+            omitKinds: []
+            customResources: []
+            cachingPolicies: []
+            oAuthScopes: []
+            onlySpinnakerManaged: false
+            kubeconfigFile: encryptedFile:k8s!n:spinnaker-secrets!k:kube-staging-kubeconfig # secret name: spinnaker-secrets, secret key: kube-staging-kubeconfig
+          primaryAccount: kube-staging
  4. Commit the changes and open a Pull Request for review.
  5. Pull Request approved and merged.
  6. Automatically a Spinnaker pipeline runs and applies the updated manifest.

Reduce management overhead and focus on innovating using the Spinnaker Operator!

Learn More

Collaborate from Code to Cloud with Armory

Request a Demo Install Armory