Skip to content

Agents

The repo agent is a service you deploy and operate in your local network or VPC so that the Controller can securely connect to your your artifact repositories.


Requirements

The agent itself is a container and can be quickly deployed on a small, managed Kubernetes cluster that is operating in your local network/VPC with network access to your private repository. This cluster can be a single node, converged cluster with minimal resource requirements.

Also, a dedicated cluster is "mandatory". The agents can be deployed to the same cluster where the workloads will operate.


Install Agent

  • Login to the Console and navigate to your Project
  • Click on Integrations and Select Agents
  • Click on New Agent
  • Provide a "friendly name" and select a "cluster" from the dropdown
  • Click on Create

Create New Agent

Behind the scenes, the controller will automatically deploy the "agent" pod to the designated cluster. In a few seconds, the agent health will transition from "UNHEALTHY" to "HEALTHY".

New Agent Status

Optionally, you can also verify successful deployment and status of the agents on the target using the integrated Zero Trust KubeCTL terminal. Look for the pod with the name "cd-agent-xxxxxx" in the "rafay-system" namespace.

kubectl get po -n rafay-infra

In the example below, we can see that the agent was recently created and is healthy (running).

Agent Status via KubeCTL


View Agents

Users can view the list of agents, the cluster they are operational on, their current health etc right from the Console.

  • In your Org, navigate to your Project
  • Click on Integrations and Select Agents

View All Agents


Use Agents

Agents are used by configured repositories so that the Controller can access artifacts in these private repositories.


Delete Agent

Existing agents (healthy or unhealthy) can be deleted anytime. Note that this is a destruction action.

  • Navigate to Integrations -> Agents
  • Click on Delete, Confirm Yes when prompted

This will automatically remove the agent resources on the cluster where it was operational.


Multiple Agents

There are no limits or licensing implications to the number of agents that customers can deploy and operate. It is strongly recommended that customers use multiple agents especially for production deployments. Running multiple agents provided the following benefits:

Scalability

A single agent can become bottle necked due to multiple, concurrent requests.

Better Performance

With multiple agents, the controller automatically "round robins" requests ensuring that requests are spread across the agents.

Availability

There is not a single point of failure and the remaining agents seamlessly pick up the work in case an agent fails.