Deploy Armory Continuous Deployment or Spinnaker Using Kubernetes Operators

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 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:

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 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	Spinnaker Operator
Deploy open source Spinnaker	❌	✅
Deploy Armory Continuous Deployment for Spinnaker	✅	❌
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	✅	❌
Deploy in an Istio-controlled cluster	✅	❌
Configure diagnostics	✅	❌
Configure Pipelines-as-Code	✅	❌
Configure Policy Engine	✅	❌
Configure Terraform integration	✅	❌
Configure Vault secrets	✅	❌
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

• System Requirements for Armory Continuous Deployment
• Install Operator and Deploy Armory Continuous Deployment Quickstart