Armory Docs – Get Started with the Armory Scale Agent for Spinnaker and Kubernetes

Plugins: Quick Start: Spinnaker and the Armory Scale Agent

Mon, 01 Jan 0001 00:00:00 +0000

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 <GATE-URL>/credentials endpoint

Objectives

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.yml, clouddriver-local.yml, spinnaker.yml, spinnaker-local.yml
Clouddriver database: clouddriver.accounts table
Spring Cloud Config Server reading accounts from Git, Vault, or another supported backend
Plugins

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 kubectl access 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
1.22+	1.3+	1.27+
1.21	1.2.5	1.27+

Fetch the Spinnaker Operator.

Replace <release-version> with a specific version or use latest to 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-operator directory, install the Spinnaker Operator CRDs cluster-wide.
```
kubectl apply -f deploy/crds/
```

Install the Spinnaker Operator in namespace spinnaker.

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 utilities/switch-to-oss.yml patch.

To start, create your own copy of the spinnaker-kustomize-patches repository 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.

Configure Spinnaker

You can find the recipe for deploying Spinnaker and the Scale Agent in recipes/kustomization-oss-agent.yml.

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

The resources section contains files that install apps that you want Spinnaker to use, such as MySQL.
The components section contains paths to directories that define collections of Kubernetes resources. This section contains a link to the targets/kubernetes/scale-agent directory, which contains the Scale Agent installation files.
The patchesStrategicMerge section contains links to files that contain partial resource definitions. Kustomize uses these patch files to overwrite sections of components or resources, such as the SpinnakerService definition.
The patches section is a list of files that Kustomize executes to add or replace fields on resources. The utilities/switch-to-oss.yml patch instructs Kustomize to replace apiVersion: spinnaker.armory.io/v1alpha2 with apiVersion: spinnaker.io/v1alpha2 in the SpinnakerService manifest.
The transformers section 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

Spinnaker version

To change the Spinnaker version, update spec.spinnakerConfig.config.version in core/patches/oss-version.yml.

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 targets/kubernetes/scale-agent/armory-agent.yml.

Add your Kubernetes accounts to the kubernetes.accounts section. For example:

kubernetes:
 accounts:
 - kubeconfigFile: /kubeconfigfiles/kubeconfig
 name: agent-demo

Deploy Spinnaker

Execute all commands from the root of spinnaker-kustomize-patches.

Set the kustomize recipe.

The kustomization.yml file in the project root is a symlink to recipes/kustomization-all.yml. Update to point to recipes/kustomization-oss-agent.yml.
```
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 kustomization file.
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"

Confirm success

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.

What’s next

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.

Plugins: Install the Armory Scale Agent in an Existing Spinnaker Instance

Mon, 01 Jan 0001 00:00:00 +0000

How to get started using the Scale Agent with open source Spinnaker

This guide assumes you want to evaluate the Scale Agent with an existing Spinnaker test instance. With that in mind:

Your Spinnaker test instance is running in the spinnaker namespace.
You have Kubernetes accounts configured in Clouddriver so you can evaluate account migration.
You are going to deploy the Scale Agent service in the same cluster and namespace as your Spinnaker test instance.

The following features require Spinnaker 1.28+ and Clouddriver Account Management:

Automated scanning for newly created accounts in Clouddriver and migrating those accounts to Scale Agent management
Intercepting and processing requests sent to Clouddriver’s <GATE-URL>/credentials endpoint

Objectives

Meet the prerequisites outlined in the Before you begin section.
Configure the Clouddriver plugin in your clouddriver-local.yml file and deploy using Halyard.
Learn the options for migrating Clouddriver accounts to the Scale Agent.
Configure and deploy the Scale Agent service in the cluster and namespace where Spinnaker is running (Spinnaker Service mode).
Confirm success.

Since this guide is for installing the Armory Scale Agent in a test environment, it does not include mTLS configuration. The Armory Agent service and plugin do not communicate securely.

Before you begin

You are familiar with how plugins work in Spinnaker. See open source Spinnaker’s Plugin User Guide.
You have read the Scale Agent overview.
You have configured Clouddriver to use MySQL or PostgreSQL. See the Configure Clouddriver to use a SQL Database guide for instructions. The Scale Agent plugin uses the SQL database to store cache data and dynamically created Kubernetes accounts.

For Clouddriver pods, you have mounted a service account with permissions to list and watch the Kubernetes kind Endpoint in the namespace where Clouddriver is running.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: spin-sa
rules:
 - apiGroups:
 - ""
 resources:
 - endpoints
 verbs:
 - list
 - watch

Verify that there is a Kubernetes Service with prefix name spin-clouddriver (configurable) routing HTTP traffic to Clouddriver pods, having a port with name http (configurable).
You have at least one Kubernetes cluster to serve as your deployment target cluster.

Choose the Scale Agent version that is compatible with your Spinnaker version.

Armory CD (Spinnaker) Version	Scale Agent Plugin Version	Scale Agent Service Version
2.28.x (1.28.x)	0.11.56	1.0.84
1.29.x	0.12.21	1.0.84
2.30.x (1.30.x)	0.13.20	1.0.84
2.31.x (1.31.x)	0.14.1	1.0.84
2.32.x (1.32.x)	0.14.1	1.0.84
2.35.x (1.35.x)	0.16.2	1.0.84

Database compatibility:

MySQL	PostgreSQL
5.7; AWS Aurora	10+

Install the plugin

Warning

The Scale Agent plugin extends Clouddriver. When Halyard adds a plugin to a Spinnaker installation, it adds the plugin repository information to each service. This means that when you restart Spinnaker, each service restarts, downloads the plugin, and checks if an extension exists for that service. Each service restarting is not ideal for large Spinnaker installations due to service restart times. To avoid each service restarting and downloading the plugin, configure the plugin in Clouddriver’s local profile.

This guide show how to install the plugin using a plugin repository. You can also install the plugin from Docker if you want to cache the plugin and run security scans on it before installation.

If you don’t have a Clouddriver local profile, create one in the same directory as the other Halyard configuration files. This is usually ~/.hal/default/profiles on the machine where Halyard is running.

Add the following to your clouddriver-local.yml file:

This code snippet includes enabling Clouddriver Account Management configuration so you can evaluate the Scale Agent’s interceptor and automatic scanning features.

spinnaker:
 extensibility:
 repositories:
 armory-agent-k8s-spinplug-releases:
 enabled: true
 url: https://raw.githubusercontent.com/armory-io/agent-k8s-spinplug-releases/master/repositories.json
 plugins:
 Armory.Kubesvc:
 enabled: true
 version: 0.16.2 # check compatibility matrix for your Armory CD version
 extensions:
 armory.kubesvc:
 enabled: true
 # Plugin config
 kubesvc:
 cluster: kubernetes
spinnaker:
 extensibility:
 repositories:
 armory-agent-k8s-spinplug-releases:
 enabled: true
 url: https://raw.githubusercontent.com/armory-io/agent-k8s-spinplug-releases/master/repositories.json
 plugins:
 Armory.Kubesvc:
 enabled: true
 version: 0.11.32
 extensions:
 armory.kubesvc:
 enabled: true
kubesvc:
 cluster: kubernetes
kubernetes:
 enabled: true
# enable Clouddriver Account Management https://spinnaker.io/docs/setup/other_config/accounts/
account:
 storage:
 enabled: true

This code snippet does not enable Clouddriver Account Management, which is not supported in Spinnaker versions 1.27.x and earlier.

spinnaker:
 extensibility:
 repositories:
 armory-agent-k8s-spinplug-releases:
 enabled: true
 url: https://raw.githubusercontent.com/armory-io/agent-k8s-spinplug-releases/master/repositories.json
 plugins:
 Armory.Kubesvc:
 enabled: true
 version: 0.14.1 # check compatibility matrix for your Spinnaker version
 extensions:
 armory.kubesvc:
 enabled: true
kubesvc:
 cluster: kubernetes
kubernetes:
 enabled: true

Save your file and apply your changes by running hal deploy apply. Kubernetes terminates the existing Clouddriver pod and creates a new one. You can validate plugin installation by executing kubectl -n spinnaker logs deployments/spin-clouddriver | grep "Plugin". Output is similar to:

org.pf4j.AbstractPluginManager : Plugin 'Armory.Kubesvc@0.11.32' resolved
org.pf4j.AbstractPluginManager : Start plugin 'Armory.Kubesvc@0.11.32'
io.armory.kubesvc.KubesvcPlugin : Starting Kubesvc plugin...

Expose Clouddriver as a LoadBalancer

To expose Clouddriver as a Kubernetes-type LoadBalancer, kubectl apply the following manifest:

apiVersion: v1
kind: Service
metadata:
 namespace: spinnaker
 labels:
 app: spin
 cluster: spin-clouddriver
 name: spin-clouddriver-grpc
spec:
 ports:
 - name: grpc
 port: 9091
 protocol: TCP
 targetPort: 9091
 selector:
 app: spin
 cluster: spin-clouddriver

Various cloud providers may require additional annotations for LoadBalancer. Consult your cloud provider’s documentation.

Apply the manifest using kubectl.

Get the LoadBalancer IP address

Use kubectl get svc spin-clouddriver-grpc -n spinnaker to make note of the LoadBalancer IP external address. You need this address when you configure the Scale Agent service.

Confirm Clouddriver is listening

Use netcat to confirm Clouddriver is listening on port 9091 by executing nc -zv [LB address] 9091. Perform this check from a node in your Spinnaker cluster and one in your target cluster.

Options for migrating accounts

In Spinnaker, you can configure Kubernetes accounts in multiple places:

Clouddriver configuration files: clouddriver.yml, clouddriver-local.yml, spinnaker.yml, spinnaker-local.yml
Clouddriver database: clouddriver.accounts table
Spring Cloud Config Server reading accounts from Git, Vault, or another supported backend
Plugins

You have the following options for migrating accounts:

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 kubectl access 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 service using manifests

The Scale Agent service can run with most features on the default ServiceAccount. However, if you want the Scale Agent service to load balance connections or assign a precise Zone ID, the Scale Agent service needs permissions to get Pods, Deployments, ReplicaSets, and Namespaces in your cluster. Rather than modifying the default ServiceAccount permissions, Armory recommends creating a new ServiceAccount, ClusterRole, and ClusterRoleBinding for the Scale Agent.

Configure permissions

The following manifest creates a ServiceAccount, ClusterRole, and ClusterRoleBinding. Apply the manifest in your spinnaker namespace.

# Create agent cluster role
apiVersion: rbac.authorizati
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: scale-agent-cluster-role
rules:
 - apiGroups:
 - ""
 resources:
 - configmaps
 - endpoints
 - events
 - ingresses
 - ingresses/status
 - jobs
 - jobs/status
 - namespaces
 - namespaces/finalize
 - namespaces/status
 - pods
 - pods/log
 - pods/status
 - secrets
 - services
 - services/status
 - services/finalizers
 verbs:
 - create
 - get
 - list
 - update
 - watch
 - patch
 - delete
 - apiGroups:
 - batch
 resources:
 - jobs
 - jobs/status
 verbs:
 - create
 - get
 - list
 - update
 - watch
 - patch
 - delete
 - apiGroups:
 - apps
 - extensions
 resources:
 - daemonsets
 - daemonsets/status
 - deployments
 - deployments/finalizers
 - deployments/scale
 - deployments/status
 - replicasets
 - replicasets/finalizers
 - replicasets/scale
 - replicasets/status
 - statefulsets
 - statefulsets/finalizers
 - statefulsets/scale
 - statefulsets/status
 verbs:
 - create
 - get
 - list
 - update
 - watch
 - patch
 - delete
 - apiGroups:
 - monitoring.coreos.com
 resources:
 - servicemonitors
 verbs:
 - get
 - create
 - apiGroups:
 - spinnaker.armory.io
 resources:
 - "*"
 - spinnakerservices
 verbs:
 - create
 - get
 - list
 - update
 - watch
 - patch
 - apiGroups:
 - apiextensions.k8s.io
 resources:
 - customresourcedefinitions
 verbs:
 - "*"
 - apiGroups:
 - admissionregistration.k8s.io
 resources:
 - validatingwebhookconfigurations
 verbs:
 - "*"
 - apiGroups:
 - argoproj.io
 resources:
 - "*"
 verbs:
 - "*"
---
# Create agent service account
apiVersion: v1
kind: ServiceAccount
metadata:
 namespace: spinnaker
 name: scale-agent-sa
---
# Bind agent cluster role and service account
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: scale-agent-cluster-role-binding
subjects:
 - kind: ServiceAccount
 name: scale-agent-sa
 namespace: spinnaker
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: scale-agent-cluster-role

Configure the service

Configure the Armory Scale Agent service using a ConfigMap. In the data section, configure the LoadBalancer and and the Kubernetes account you want the Scale Agent to manage.

Define armory-agent.yml in the data section:

apiVersion: v1
kind: ConfigMap
metadata:
 name: armory-agent-config
 namespace: spinnaker
data:
 armory-agent.yml: |

Clouddriver plugin LoadBalancer

Replace with the IP address you obtained in the Get the LoadBalancer IP address section.

apiVersion: v1
kind: ConfigMap
metadata:
 name: armory-agent-config
 namespace: spinnaker
data:
 armory-agent.yaml: |
 clouddriver:
 grpc: <LoadBalancer-exposed-address>:9091
 insecure: true

Kubernetes account

Add your Kubernetes account configuration. This account should not exist in Clouddriver.

apiVersion: v1
kind: ConfigMap
metadata:
 name: armory-agent-config
 namespace: spinnaker
data:
 armory-agent.yaml: |
 clouddriver:
 grpc: <LoadBalancer-exposed-address>:9091
 insecure: true
 kubernetes:
 accounts:
 - name:
 kubeconfigFile:
 insecure:
 context:
 oAuthScopes:
 serviceAccount: true
 serviceAccountName: spin-sa
 namespaces: []
 omitNamespaces: []
 onlyNamespacedResources:
 kinds: []
 omitKinds: []
 customResourceDefinitions: [{kind:}]
 metrics:
 permissions: []
 maxResumableResourceAgeMs:
 onlySpinnakerManaged:
 noProxy:

See the Agent options for field explanations.

Apply the manifest in your spinnaker namespace.

Deploy the Armory Scale Agent service

Apply the following manifest in your spinnaker namespace:

apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: spinnaker
 labels:
 app: spin
 app.kubernetes.io/name: armory-agent
 app.kubernetes.io/part-of: spinnaker
 cluster: spin-armory-agent
 name: spin-armory-agent
spec:
 replicas: 1
 selector:
 matchLabels:
 app: spin
 cluster: spin-armory-agent
 template:
 metadata:
 labels:
 app: spin
 app.kubernetes.io/name: armory-agent
 app.kubernetes.io/part-of: spinnaker
 cluster: spin-armory-agent
 spec:
 serviceAccount: scale-agent-sa
 containers:
 - image: armory/agent-k8s:<version> # must be compatible with your Armory CD version
 imagePullPolicy: IfNotPresent
 name: armory-agent
 ports:
 - name: health
 containerPort: 8082
 protocol: TCP
 - name: metrics
 containerPort: 8008
 protocol: TCP
 readinessProbe:
 httpGet:
 port: health
 path: /health
 failureThreshold: 3
 periodSeconds: 10
 successThreshold: 1
 timeoutSeconds: 1
 terminationMessagePath: /dev/termination-log
 terminationMessagePolicy: File
 volumeMounts:
 - mountPath: /opt/armory/config
 name: volume-armory-agent-config
 # - mountPath: /kubeconfigfiles
 # name: volume-armory-agent-kubeconfigs
 restartPolicy: Always
 volumes:
 - name: volume-armory-agent-config
 configMap:
 name: armory-agent-config
 # - name: volume-armory-agent-kubeconfigs
 # secret:
 # defaultMode: 420
 # secretName: kubeconfigs-secret

Verify that the plugin and service are communicating

You can 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"

Confirm success

Create a pipeline with a Deploy manifest stage. You should see your target cluster available in the Accounts list. Deploy a static manifest.

Uninstall the plugin

Remove the Scale Agent plugin config from clouddriver-local.yml and hal deploy apply the changes.

Uninstall the service

You can use kubectl to delete all Scale Agent service’s Deployment objects and their accompanying ConfigMap and Secret.

What’s next

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.

Plugins: Install the Armory Scale Agent in an Existing Armory CD Instance

Mon, 01 Jan 0001 00:00:00 +0000

Before you begin

This guide assumes you want to evaluate the Scale Agent with an existing Armory CD test instance that you deployed using the Armory Operator and Kustomize patches (spinnaker-kustomize-patches repo). With that in mind:

Your Armory CD test instance is running in the spinnaker namespace.
Your Clouddriver service uses a SQL backend. The Scale Agent plugin uses the SQL database to store cache data and dynamically created Kubernetes accounts.
You have Kubernetes accounts configured in Clouddriver so you can evaluate account migration.
You are going to deploy the Scale Agent service in the same cluster and namespace as your Armory CD test instance.
You are not going to configure mTLS, so the Scale Agent service and plugin are not going to communicate securely.

Choose the Scale Agent version that is compatible with your Armory CD version.

Armory CD (Spinnaker) Version	Scale Agent Plugin Version	Scale Agent Service Version
2.28.x (1.28.x)	0.11.56	1.0.84
1.29.x	0.12.21	1.0.84
2.30.x (1.30.x)	0.13.20	1.0.84
2.31.x (1.31.x)	0.14.1	1.0.84
2.32.x (1.32.x)	0.14.1	1.0.84
2.35.x (1.35.x)	0.16.2	1.0.84

Database compatibility:

MySQL	PostgreSQL
5.7; AWS Aurora	10+

Scale Agent Features Limitation

The following Scale Agent features require Armory CD 2.28+ and Clouddriver Account Management:

Automated scanning for newly created accounts in Clouddriver and migrating those accounts to Scale Agent management
Intercepting and processing requests sent to Clouddriver’s <GATE-URL>/credentials endpoint

If your Armory CD version is earlier than 2.28, see the Configure the plugin section for how to disable Clouddriver Account Management.

Objectives

Read about options for migrating Kubernetes accounts.
Access the latest Scale Agent installation files.
Update your local kustomization recipe.
Configure the plugin.
Configure the service
Install the Scale Agent

Options for migrating Kubernetes accounts

In Armory CD, you can configure Kubernetes accounts in multiple places:

Clouddriver configuration files: clouddriver.yml, clouddriver-local.yml, spinnaker.yml, spinnaker-local.yml
Clouddriver database: clouddriver.accounts table
Spring Cloud Config Server reading accounts from Git, Vault, or another supported backend
Plugins

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 kubectl access to the cluster so you can port-forward the endpoint to your local machine.

This guide shows you how to statically add an accounts to the Scale Agent service configuration before deployment.

Access the installation files

You can find the files that install the Scale Agent in the spinnaker-kustomize-patches/targets/kubernetes/scale-agent repo. Update your local copy from master to get the latest updates.

Update your Kustomization recipe

components section: add targets/kubernetes/scale-agent
transformers section: add utilities/unique-service-account.yml

Configure the plugin

Set the plugin version that is compatible with your Armory CD version

In plugin-config.yml, check that the version listed is compatible with your Armory CD version. If it isn’t, replace with a plugin version that is.

spec:
 spinnakerConfig:
 profiles:
 clouddriver:
 spinnaker:
 extensibility:
 repositories:
 armory-agent-k8s-spinplug-releases:
 enabled: true
 url: https://raw.githubusercontent.com/armory-io/agent-k8s-spinplug-releases/master/repositories.json
 plugins:
 Armory.Kubesvc:
 enabled: true
 version: 0.11.32 # Replace with a version compatible with your Armory CD version
 extensions:
 armory.kubesvc:
 enabled: true

(Optional) Disable Clouddriver Account Management if your Armory CD version is earlier than 2.28.

Set spec.spinnakerConfig.profiles.clouddriver.account.storage.enabled to false.
```
spec:
 spinnakerConfig:
 profiles:
 clouddriver:
 account:
 storage:
 enabled: true
```

Configure the service

Version

The Scale Agent service version is set in spinnaker-kustomize-patches/targets/kubernetes/scale-agent/scale-agent-deployment.yml. You don’t have to configure a version in the spec.template.spec.containers.image field. The manifest pulls the latest version, which is compatible with Armory CD 2.26+ and corresponding plugin versions.

Kubernetes account

You should configure a Kubernetes account for the Scale Agent service to manage. You do this in targets/kubernetes/scale-agent/armory-agent.yml. The Kubernetes account should not exist in Clouddriver.

Add your Kubernetes accounts to the kubernetes.accounts section. For example:

kubernetes:
 accounts:
 - kubeconfigFile: /kubeconfigfiles/kubeconfig
 name: agent-demo

Install the Scale Agent

Execute all commands from the root of spinnaker-kustomize-patches. The following commands assume your Kustomization recipe is named kustomization.yml and is in the root of your spinnaker-patches-kustomize directory.

(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 kustomization file.
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"

Confirm success

Create a pipeline with a Deploy manifest stage. You should see your target cluster available in the Accounts list. Deploy a static manifest.

What’s next

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.

Plugins: Advanced Installation and Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Plugins: Uninstall the Scale Agent - Armory Continuous Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Uninstall the plugin

Remove the Scale Agent plugin manifest file entry from your kustomization file.

bases:
 - agent-service
patchesStrategicMerge:
 - armory-agent/clouddriver-plugin-repo.yaml # or clouddriver-plugin-docker.yaml

Then execute:

 kustomize build </path/to/kustomize> | kubectl delete -f -

Uninstall the service

You can use kubectl to delete all Scale Agent service’s Deployment objects and their accompanying ConfigMap and Secret.