Deploy Armory Enterprise or Spinnaker Using Kubernetes Operators

Armory provides Kubernetes Operators that make it easy to install, deploy, and upgrade Armory Enterprise or Spinnaker. This section covers advantages, configuration, deployment, and migration from Halyard to the Operator.

Armory Enterprise requires a license. For more information, contact Armory.

What are Kubernetes Operators for Spinnaker?

From the Kubernetes Operator pattern docs: “Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components.” In other words, an Operator is a Kubernetes controller that manages a specific application using a custom resource. Both the proprietary Armory Operator and the open source Spinnaker Operator for Kubernetes are custom Kubernetes Operators that you can install in your cluster.

  • The Armory Operator Proprietary extends the Spinnaker Operator’s features by providing the ability to configure Armory Enterprise’s features, such as Pipelines as Code and Policy Engine. The Armory Operator and Armory Enterprise are closed source and not free to use.
  • The Spinnaker Operator is a Kubernetes controller for deploying and managing Spinnaker. The Spinnaker Operator and Spinnaker are both open source and free to use.

Advantages to using a Kubernetes Operator for Armory Enterprise deployment

  • Use a Kubernetes manifest to deploy and manage Armory Enterprise or Spinnaker.
  • Use kubectl to deploy, manage, and access Armory Enterprise or Spinnaker like you would with any other app deployed on Kubernetes.
  • Store and reference configuration secrets in one of the supported secrets engines.
  • Store your configuration in git for an auditable and reversible GitOps workflow.

How the Armory Operator and the Spinnaker Operator work

The Operator is a custom controller of Kubernetes kind Deployment. The Operator works with a Kubernetes custom resource named SpinnakerService to deploy and manage Armory Enterprise or Spinnaker in your cluster.

SpinnakerService Custom Resource Definition

The SpinnakerService CRD declares the resource’s names, the scope of the resource, and the structural schema of the spinnakerservice.yml Kubernetes manifest that contains your Spinnaker configuration:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: spinnakerservices.spinnaker.io
spec:
  group: spinnaker.io
  names:
    kind: SpinnakerService
    listKind: SpinnakerServiceList
    plural: spinnakerservices
    shortNames:
    - spinsvc
    singular: spinnakerservice
  scope: Namespaced

You can view the entire SpinnakerService CRD in the public spinnaker-operator repo.

Spinnnaker manifest

You have the following options for creating the Spinnaker manifest:

  • Create the manifest YAML file yourself using an example spinnakerservice.yml as a starting point.
  • Create a collection of patch files that Kustomize uses to overwrite sections of the spinnakerservice.yml manifest. Kustomize is part of kubectl.

Regardless of the option you use to configure Spinnaker, the spinnakerservice.yml manifest specifies that the Kubernetes kind is SpinnakerService:

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker

You can view the rest of the basic file in the spinnaker-operator repo.

At the highest level, when you use kubectl to apply the manifest:

  1. kubectl parses spinnakerservice.yml and sees that the kind is SpinnakerService.
  2. kubectl delegates manifest validation and deployment to the Operator.
  3. The Operator validates the manifest and uses Halyard to deploy Spinnaker.

The Armory Operator’s SpinnakerService CRD and Armory Enterprise SpinnakerService.yml are slightly different than their open source counterparts so that kubectl knows to delegate to the Armory Operator.

Comparison of the Spinnaker Operator and the Armory Operator

Use the Armory Operator if you want to deploy Armory Enterprise and use its proprietary features.

Armory Operator Proprietary Spinnaker Operator
Deploy open source Spinnaker
Deploy Armory Enterprise for Spinnaker Proprietary
Use kubectl to manage deployment
Validate your configuration before deployment
Use a single spinnakerservice.yml configuration file
Use Kustomize patches instead of a single configuration file
Store Spinnaker secrets in Kubernetes secrets
Store your configuration in git for an easy GitOps workflow
Define Kubernetes accounts in SpinnakerAccount objects
and store kubeconfig inline, in Kubernetes secrets, in s3, or GCS
Expose via LoadBalancer or Ingress Proprietary
Deploy in an Istio-controlled cluster Proprietary
Configure diagnostics Proprietary
Configure Pipelines as Code Proprietary
Configure Policy Engine Proprietary
Configure Terraform integration Proprietary
Configure Vault secrets Proprietary
Configure artifacts
Configure canary
Configure continuous integration providers
Configure deployment environment
Configure features
Configure metric stores
Configure notifications
Configure persistent storage
Configure plugins
Configure pub sub
Configure repository artifactory
Configure security
Configure stats
Configure webhooks

What’s next


Last modified April 16, 2021: (3f9b597)