Deploy Armory Continuous Deployment or Spinnaker Using Kubernetes Operators

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

Armory Continuous Deployment (Armory CD) 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 Continuous Deployment’s features, such as Pipelines-as-Code and Policy Engine. The Armory Operator and Armory Continuous Deployment 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 Continuous Deployment deployment

  • Use a Kubernetes manifest to deploy and manage Armory Continuous Deployment or Spinnaker.
  • Use kubectl to deploy, manage, and access Armory Continuous Deployment 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 Continuous Deployment 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:

kind: CustomResourceDefinition
    kind: SpinnakerService
    listKind: SpinnakerServiceList
    plural: spinnakerservices
    - 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:

kind: SpinnakerService
  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 Continuous Deployment 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 Continuous Deployment and use its proprietary features.

Armory Operator ProprietarySpinnaker Operator
Deploy open source Spinnaker
Deploy Armory Continuous Deployment 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 May 26, 2023: (a7d5a9eb)