Quick Start: Spinnaker and the Armory Scale Agent
Quick start overview
In this guide, you deploy a basic instance of Spinnaker 1.28+ and the corresponding Scale Agent plugin and service. You can evaluate:
- Dynamic accounts for dynamically adding and managing Kubernetes accounts
- Automated scanning for newly created accounts in Clouddriver and migrating those accounts to Scale Agent management
- Intercepting and processing requests sent to Clouddriver’s
- Meet the requirements listed in the Before you begin section.
- Learn the options for migrating Clouddriver accounts to the Scale Agent.
- Deploy the Spinnaker Operator.
- Get the spinnaker-kustomize-patches repo.
- Configure Spinnaker.
- Deploy Spinnaker and the Scale Agent.
Since this guide is for installing the Armory Scale Agent in a test environment, it does not include mTLS configuration. The Scale Agent service and plugin do not communicate securely.
Before you begin
- You are familiar with Kubernetes Operators, which use custom resources to manage applications and their components.
- You understand the concept of managing Kubernetes resources using manifests.
- You have read how Armory’s operators deploy Spinnaker or Armory CD.
- You have a cluster with at least least 4 cores and 16 GB of RAM available.
Options for migrating Kubernetes accounts
In Spinnaker, you can configure Kubernetes accounts in multiple places:
- Clouddriver configuration files:
- Clouddriver database:
- Spring Cloud Config Server reading accounts from Git, Vault, or another supported backend
You have the following options for migrating accounts to the Scale Agent:
- You can configure the Scale Agent service to manage specific accounts by adding those accounts to a ConfigMap. This approach means you should remove the accounts from the Clouddriver credential source before you deploy the service.
- You can dynamically migrate accounts after the service has been deployed. This requires
kubectlaccess to the cluster so you can port-forward the endpoint to your local machine.
This guide shows you how to statically add an account to the Scale Agent service configuration before deployment.
Deploy the Spinnaker Operator
Decide which Spinnaker Operator release you need based on the Kubernetes version you are using.
|Kubernetes Version||Spinnaker Operator Version||Spinnaker Version|
Fetch the Spinnaker Operator.
<release-version>with a specific version or use
latestto fetch the latest release.
mkdir -p spinnaker-operator && cd spinnaker-operator bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/<release-version>/download/manifests.tgz | tar -xz'
From the root of your
spinnaker-operatordirectory, install the Spinnaker Operator CRDs cluster-wide.
kubectl apply -f deploy/crds/
Install the Spinnaker Operator in namespace
kubectl create ns spinnaker kubectl -n spinnaker apply -f deploy/operator/cluster
Verify that the Spinnaker Operator is running before you deploy Spinnaker.
kubectl get pods -n spinnaker | grep operator
Output is similar to:
spinnaker-operator-79599cbf55-js5pg 2/2 Running 0 159m
Get the spinnaker-kustomize-patches repo
Armory maintains the
spinnakaker-kustomize-patches repo, which contains common configuration options for Armory Continuous Deployment or Spinnaker as well as helper scripts. The patches in this repo give you a reliable starting point when adding and removing features.
Configuration in this repository is meant for Armory Continuous Delivery. To make it compatible with Spinnaker instead, apply the
To start, create your own copy of the
by clicking the
Use this template button:
If you intend to update your copy from upstream, use Fork instead. See Creating a repository from a template for the difference between Use this template and Fork.
Once created, clone this repository to your local machine.
You can find the recipe for deploying Spinnaker and the Scale Agent in
#------------------------------------------------------------------------------- # Minimum Starting Point Recipe with Armory Scale Agent. # # Self contained Spinnaker installation with no external dependencies and no # additional configuration needed. This is intended as a starting point for any # kubernetes cluster. Not for production use. # # Features: # - Spinnaker Operator # - One Kubernetes account (Spinnaker's own cluster) using the Scale Agent # - Spinnaker authentication disabled # - Self hosted minio as a persistent storage # - Self hosted redis backend for caching and temporal storage of services #------------------------------------------------------------------------------- apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: spinnaker resources: - infrastructure/mysql.yml # (Optional, not for production use). MySQL server needed if using SQL backend in Spinnaker components: - core/base # Defines base configuration across the cluster - core/persistence/in-cluster # Enables persistence using MinIO in-cluster - targets/kubernetes/scale-agent # Enables the plugin version of the Scale Agent patchesStrategicMerge: - core/patches/oss-version.yml # Sets the OSS version to use - persistence/patch-sql-clouddriver.yml # setup clouddriver to use SQL for storage transformers: - utilities/unique-service-account.yml # Ensures that ServiceAccounts are unique # This patch ensures that the correct OSS apiVersion is used. patches: - target: kind: SpinnakerService path: utilities/switch-to-oss.yml
resourcessection contains files that install apps that you want Spinnaker to use, such as MySQL.
componentssection contains paths to directories that define collections of Kubernetes resources. This section contains a link to the
targets/kubernetes/scale-agentdirectory, which contains the Scale Agent installation files.
patchesStrategicMergesection contains links to files that contain partial resource definitions. Kustomize uses these patch files to overwrite sections of components or resources, such as the
patchessection is a list of files that Kustomize executes to add or replace fields on resources. The
utilities/switch-to-oss.ymlpatch instructs Kustomize to replace
apiVersion: spinnaker.io/v1alpha2in the SpinnakerService manifest.
transformerssection contains links to files that define Kustomize transformers.
What this recipe does
- Configures MinIO as the persistent storage provider (instead of Redis or cloud storage)
- Installs MySQL and configures Clouddriver to use MySQL
- Enables Clouddriver Account Management
- Installs the plugin
- Creates a ServiceAccount, ClusterRole, and ClusterRoleBinding for the Scale Agent service
- Deploys the service
What this recipe does not do
- Publicly expose Spinnaker services
- Configure mTLS; communication between the plugin and service is not secure
To change the Spinnaker version, update
If you chose a Spinnaker version earlier than 1.28, you should modify the
targets/kubernetes/scale-agent/plugin-config file to disable Clouddriver Account Management as in the following example:
spec: spinnakerConfig: profiles: clouddriver: account: storage: enabled: false # This enables Clouddriver Account Management; requires Armory CD 2.28+ or Spinnaker 1.28+
Configure your Kubernetes account
You should configure a Kubernetes account or accounts for the Scale Agent service to manage. You do this in
Add your Kubernetes accounts to the
kubernetes.accounts section. For example:
kubernetes: accounts: - kubeconfigFile: /kubeconfigfiles/kubeconfig name: agent-demo
Execute all commands from the root of
Set the kustomize recipe.
kustomization.ymlfile in the project root is a symlink to
recipes/kustomization-all.yml. Update to point to
ln -vfns ./recipes/kustomization-oss-agent.yml kustomization.yml
(Optional) Verify the Kustomize build output.
kubectl kustomize kustomization.yml
This prints out the contents of the manifest file that Kustomize built based on your
Apply the manifest.
kubectl apply -k .
Verify the installation.
kubectl -n spinnaker get spinsvc && echo "" && kubectl -n spinnaker get pods
You can also access the Clouddriver log to verify that the plugin is running and communicating with the service.
kubectl -n spinnaker logs deployment/spin-clouddriver | grep -E "Start plugin|Starting Kubesvc plugin|Registering agent with"
If you haven’t publicly exposed Spinnaker based on your cloud provider’s guides, you should
port-forward in order to access the Spinnaker UI and API:
# port-forward for the UI kubectl port-forward svc/spin-deck 9000:9000 -n spinnaker # port-forward for the API kubectl port-forward svc/spin-gate 8084:8084 -n spinnaker
Create a pipeline with a
Deploy manifest stage. You should see your target cluster available in the
Accounts list. Deploy a static manifest.
- Dynamic Accounts Architecture and Features
- Migrate Clouddriver Kubernetes Accounts to the Armory Scale Agent
- Troubleshoot the Armory Scale Agent Service and Plugin page if you run into issues.
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified March 3, 2023: (2d06908)