Aug 3, 2020 by Stu Posluns
At Armory, we are leveraging Spinnaker to help our customers and the broader community make software delivery continuous, scalable, collaborative, and safe. We are furthering that vision today by announcing general availability (GA) of the Spinnaker Kubernetes Operator. The Operator makes managing Spinnaker, which runs in Kubernetes, dramatically simpler and more automated, while introducing new Kubernetes-native features. The Operator will make it even easier for companies around the world to adopt and scale Spinnaker and achieve continuous delivery nirvana. Let’s take a look.
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.
Kubernetes operators are application-specific controllers that leverage the Kubernetes API and deep, domain-specific expertise to automate the creation, configuration, and management of complex stateful applications. Operators have been released for popular open source projects including etcd and Prometheus.
Armory engineers have years of expertise in deploying, scaling, and managing Spinnaker in production in the world’s leading enterprises. But even with our experience, using Halyard to manage our and our customers’ Spinnaker instances was a heavier lift that we would have liked. It involved numerous manual steps entered through the CLI, lacked an easy way to store and manage configurations as code, and required engineers to ramp up on Halyard, a domain-specific tool for managing Spinnaker. Furthermore, we heard a desire from the community to be able to manage Spinnaker through the same tools they use to manage Kubernetes, without the need for context switching.
And so, we productized our years of Spinnaker expertise into the Spinnaker Operator. The Operator makes managing Spinnaker declarative, automating manual processes and enabling our teams to treat Spinnaker like just another Kubernetes deployment using kubectl
and kustomize
. On top of it all, the Operator enables new functionality not available in Halyard, such as pre-flight validation of config changes and the use of Kubernetes Secrets as a secrets store.
We’ve made the Operator available for free so that the entire Spinnaker community can spend more time deploying with Spinnaker and less time managing Spinnaker. Check out a quick demo here to see the Operator in action.
kubectl
and kustomize
to install and manage Spinnaker.“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
Want a deeper dive on the Spinnaker Operator? Keep reading!
Installing and upgrading Spinnaker using Halyard is a bit of a pain. It involves creating and mounting a standalone Halyard machine, ensuring that the config files in the machine are up-to-date, and learning to use the Halyard CLI.
The Operator lives natively within your Kubernetes cluster – no need to mount a separate machine. Once you have the Operator installed (which takes just a few simple commands), all you need to do is have a Spinnaker config manifest and hit kubectl apply
. These are regular Kubernetes manifest files, and we’ve provided a template to get started. To upgrade versions, simply change the version number in the manifest and apply – that’s it!
With Halyard, config files need to be mounted within the Halyard machine and applied using hal
commands. Halyard does not have a native way to manage the lifecycle of your config files, which creates numerous manual steps, operates outside of your Git workflow, and makes it difficult to track changes. There is also not an easy way to validate config changes before applying them.
With the Operator, you can have One File to Rule them All. All you have to do is make changes to the SpinnakerService.yml
manifest and apply with kubectl
. The manifest is stored in source control, enabling version control, auditability, and a GitOps workflow for managing Spinnaker. It also allows you to cut down on the number of individual settings you need to manage for Spinnaker’s various microservices.
For more complex use cases, you can use kustomization files to break up your configurations into smaller chunks, and even create dynamic configuration processes. With the Operator, you get the best of both worlds – simplicity by default, and more fine-grained ability to configure the manifest if you choose.
Another powerful benefit of the Operator is the ability (using Kubernetes’ validation webhook) to perform pre-flight validation on config changes. This brings additional safety and stability and helps to ensure that you don’t accidentally break your Spinnaker instance with a missing comma.
Disaster recovery with Halyard could be problematic. If the Halyard machine went down, configs may or may not be backed up, and the virtual machine needs to be remounted before you can recover Spinnaker.
With the Operator, Spinnaker manifests are stored separately, in your repo. If your cluster goes down or if you want to roll back a bad change, simply reapply the desired manifest from source control and the rest is taken care of declaratively.
With the Spinnaker Operator all of your Spinnaker configurations are stored 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 Spinnaker.
With the Spinnaker Operator, you can:
kubectl
to install and configure a brand new Spinnaker instance (OSS or Armory Spinnaker).SpinnakerService
manifest (i.e. Packer templates, support config files, etc.)SpinnakerService
manifest can contain references to secrets stored in S3, GCS or Vault (Vault is Armory Spinnaker only).Additionally, Spinnaker Operator has some exclusive new features not available with other deployment methods like Halyard:
SpinnakerService
configuration.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:
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:
kubeconfig
file of the new account in a Kubernetes secret, in the same namespace where Spinnaker is installed.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
Reduce management overhead and focus on innovating using the Spinnaker Operator!
The Operator is currently GA and is available open source from our repo under the Apache 2.0 license.
In the meantime, we are continuing to invest in the Operator to make installing, configuring and managing Spinnaker easier and more powerful. We’re enhancing Spinnaker iteratively, and deeply appreciate your feedback. Issues and PRs are very welcome!
Interested in learning more about the Spinnaker Operator? Reach out to us here or on Spinnaker Slack – we’d love to chat!
Software deployment processes differ across organizations, teams, and applications. The most basic, and perhaps the riskiest, is the “big bang deployment.” This strategy updates all nodes within the target environment simultaneously with the new software version. This deployment strategy causes many issues, including potential downtime or other issues while the update is in progress. It […]
Read more →
Multi-target deployments can feel tedious as you deploy the same code over and over to multiple clouds and environments — and none of them in the same way. With an automatic multi-target deployment tool, on the other hand, you do the work once and deliver your code everywhere it needs to be. Armory provides an […]
Read more →
KubeCon+CloudNativeCon EU is one of the world’s largest tech conferences. Here, users, developers, and companies who have and intend to adopt the Cloud Native standard of running applications with Kubernetes in their organizations come together for 5 days. From May 16-20, 2022, tech enthusiasts will congregate both virtually and in person in Valencia, Spain to […]
Read more →