AutoScale Configuration (Docker Agent Pool)
This section covers the AutoScale configuration for Pools of type "Docker Agent".
AutoScale Settings for Agent Pool
Note
Many of the settings below apply to the agents that are created during autoscaling. When changing these settings on an autoscale config they are not automatically applied to existing agents and they must be manually updated on existing agents that were created from that autoscale config.
- Configure the following settings in your Kasm deployment.
| Name | Description |
|---|---|
| Enabled | Whether to enable this config or not. |
| Name | Name for the AutoScale config . |
| AutoScale Type | The type of AutoScale confog this is, either a Docker Agent or a Server. |
| Pool | Which pool this AutoScale config is attached to. |
| Aggressive Scaling | When enabled, the system may take more expedient measures to provision raw compute resources for on-demand session requests. See Aggressive Scaling for more details. |
| Deployment Zone | Which zone this AutoScale config applies to. |
| Downscale Backoff (Seconds) | This setting prevents prevents the system from downscaling (deleting Agents) for this amount of time (in seconds) when needed. This is useful for preventing the system from thrashing up and down if the available resource hover around an interval that would typically trigger autoscaling. |
| Standby Cores | The number of standby cores that the system should try to keep "always available" at any given time in addition to any that is needed to satisfy the Staging Config requirements. If the number of available cores falls below this number, more Agents are created. If the number of available cores rises above this number, Agents are deleted as long as it wont result in the number of available cores falling below this number. A value of 0 indicates no additional standby compute is created. The AutoScaler will only provision enough compute according to the Staging Config requirements. |
| Standby GPUs | The number of standby GPUs that the system should try to keep "always available" at any given time in addition to any that is needed to satisfy the Staging Config requirements. If the number of available GPUs falls below this number, more Agents are created. If the number of available GPUs rises above this number, Agents are deleted as long as it wont result in the number of available GPUs falling below this number. A value of 0 indicates no additional standby compute is created. The AutoScaler will only provision enough compute according to the Staging Config requirements. |
| Standby Memory (GiB) | The amount of memory (in GiB) that the system should try to keep "always available" at any given time in addition to any that is needed to satisfy the Staging Config requirements. If the amount of available memory falls below this number, more Agents are created. If the amount of available memory rises above this number, Agents are deleted as long as it wont result in available amount falling below this number. A value of 0 indicates no additional standby compute is created. The AutoScaler will only provision enough compute according to the Staging Config requirements. |
| Agent Cores Override | When an Agent is created, the compute resource (e.g AWS EC2 / Digital Ocean Droplet) will have a set amount of CPU and Ram as defined by the cloud provider's instance type. This setting should typically be set to match the instance type but can be set to a preferred value. |
| Agent GPUs Override | When an Agent is created, the compute resource (e.g AWS EC2 / Digital Ocean Droplet) will have a set number of GPUs as defined by the cloud provider's instance type. This setting should typically be set to match the instance type but can be set to a higher number to allow oversubscribing. |
| Agent Memory Override (GiB) | When an Agent is created, the compute resource (e.g AWS EC2 / Digital Ocean Droplet) will have a set amount of CPU and Ram as defined by the cloud provider's instance type. This setting should typically be set to match the instance type but can be set to a preferred value. |
| Rotate Agent in (Days) | The number of days until Agents are Drained and replaced with new Agents. This sets the "Drain Time" of the agent when it is created. A value of "0" disables this function. Note: Existing agents will not be updated when this field is changed. To apply new rotation settings to existing agents, each existing agent must be manually updated. |
| Pre Warm Rotated Agent Replacements for (Minutes) | The number of minutes before the Agent's "Drain Time" that Kasm will begin provisioning a replacement Agent. This allows time for a replacement Agent to be installed before the old agent is rotated out. A value of "0" disables this function. |
| Register DNS | If enabled, the Agent's IP will be registered in DNS. |
| Base Domain Name | Define a base name for the automatic DNS registration for the Agent. The system will create a full name using <ID>.<Base Domain Name>. If the Base Domain Name is "agents.kasm.example.com", the full DNS name generated will be <ID>.agents.kasm.example.com (e.g 123abcd.agents.kasm.example.com). This Base Domain Name, must already be a registered DNS zone within the cloud provider's DNS system. |
- Click "Next" and you will now be prompted to enter your provider-specific details.
Pre-load Workspace Images on Agents
Pre-loading workspace images on your provisioned agents helps eliminate delays caused by image downloads after the VMs are brought online. Follow the Pre-load Workspace Images on Agents guide to learn how to fetch workspace images using the Kasm API and bake them into your VM templates for faster and more efficient autoscaling.
Provider Specific Settings
Kasm supports AutoScaling on a variety of providers. Each provider has unique configurations that must be set up correctly for optimal performance. Select your provider to learn more: