Spinnaker Operator
Simplified Spinnaker management using a GitOps workflow.
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.
Spend less time managing Spinnaker and more time innovating.
Kubernetes-native management of Spinnaker and access to powerful Kubernetes features.
Bring Spinnaker into your GitOps workflow by managing all configs through Git.
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:
Additionally, Spinnaker Operator has some exclusive new features not available with other deployment methods like Halyard:
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.
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:
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
Reduce management overhead and focus on innovating using the Spinnaker Operator!