Install quickly using this guide.
You are viewing version 2.22 of the documentation, which is no longer maintained. For up-to-date documentation, see the latest version.
Armory Agent for Kubernetes
- Caching and deployment scales to thousands of Kubernetes clusters for your largest applications.
- By leveraging the Kubernetes
watchmechanism, the Agent detects changes to Kubernetes and streams them in real time over a single TCP connection per cluster to SpinnakerTM.
- The Agent optimizes how infrastructure information is cached, making Force Cache Refresh almost instantaneous. This means optimal performance for your end users and your pipeline executions.
- Keep your Kubernetes API servers private from Spinnaker.
- Only the information Spinnaker needs leaves the cluster.
- Decentralize your account management. Using Kubernetes Service Accounts, teams control what Spinnaker can do. Add or remove accounts in real time. and then use them without restarting Spinnaker.
- Use Kubernetes Service Accounts or store your
kubeconfigfiles in one of the supported secret engines, or provision them via the method of your choice as Kubernetes secrets.
- Use the Agent alongside Spinnaker and benefit from performance improvements.
- Use the Agent in a target cluster and get Kubernetes accounts automatically registered.
- Use YAML, a HELM chart, or a Kustomize template to inject the Agent into newly provisioned Kubernetes clusters, and immediately make those clusters software deployment targets.
- Use the Agent with little operational overhead or changes in the way you currently manage Spinnaker.
Check out the Quick Start guide to deploy the Agent on your Kubernetes infrastructure.
Spinnaker service mode
In this mode, the Agent is installed as a new Spinnaker service (
spin-kubesvc) and can be configured like other services.
If you provision clusters automatically, the Agent can dynamically reload accounts when
kubesvc.yaml changes. You could, for example, configure accounts in a
configMap mounting to
/opt/spinnaker/config/kubesvc-local.yaml. The Agent reflects
configMap within seconds after etcd sync.
In infrastructure mode, multiple Agent deployments handle different groups of Kubernetes clusters. Each deployment is configured separately.
Account name must still be unique across all your infrastructure. Clouddriver will reject new accounts with a name that matches a different cluster.
If Spinnaker is unable to communicate with the Agent, Spinnaker attempts to reconnect during a defined grace period. If Spinnaker still can’t communicate with the Agent after the grace period has expired, the Agent’s cluster is removed from Spinnaker.
Communication with Clouddriver
The Armory Agent does outbound calls only, except for a local health check, over a single gPRC connection to Clouddriver. The connection can be over TLS or mTLS. You can terminate TLS:
- On Clouddriver: in the case of running the Agent in Spinnaker Service mode or if declaring
spin-clouddriver-grpcas a network load balancer.
- On a gRPC proxy that directs request to the
Spinnaker will use the bidirectional communication channel to receive changes from Kubernetes accounts as well as send operations to the Agent.
Information sent by the Agent
The Agent sends the following information about the cluster it is watching back to Spinnaker:
- Account properties as configured in
- Kubernetes API server host, certificate fingerprint, version.
- All the Kubernetes objects it is configured to watch and has permissions to access. You can ignore certain Kubernetes kinds (
kubernetes.accounts.omitKinds) or configure specific kinds to watch (
The Agent always scrubs data from
Secretin memory before it is sent and even before that data makes it onto the Agent’s memory heap.
Since the Armory Agent does outbound calls only, you can have agents running on-premises or in public clouds such as AWS, GCP, Azure, Oracle, or Alibaba.
What Spinnaker can do in the target cluster is limited by what it is running as:
serviceAccountin Agent mode
kubeconfigsetup for infrastructure or Spinnaker service mode
Communications are secured with TLS and optionally mTLS.
Furthermore, in Agent mode, Spinnaker never gets credentials and account registration is dynamic.
Each Agent can scale to 100s of Kubernetes clusters. The more types of Kubernetes objects the Agent has to watch, the more memory it uses. Memory usage is bursty. You can control burst with
budget. See Agent options) for configuration information.
Scaling the Agent can mean:
- Scaling the Kubernetes
Deploymentit is part of.
- Sharding Kubernetes clusters into groups that can in turn be scaled as described in Infrastructure mode above.
You can also mix deployment strategies if you have complex Kubernetes infrastructure and permissions:
- Run as a Spinnaker service
- Run in target clusters
- Run next to traditional Spinnaker Kubernetes accounts
How to configure the Agent
How to configure the Agent plugin for Clouddriver
Monitor using Prometheus
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.