Workloads

Workloads are the primary deployment unit in Control Plane. Covers container configuration, autoscaling, Capacity AI, logging, and the four workload types.

Overview

A workload represents a backend application such as a microservice. It is comprised of one or multiple containers. Containers within a workload communicate freely on localhost.

Workloads run in Control Plane’s AWS, Azure, GCP accounts, or in your own Custom Location (BYOK), where cloud providers and regions are determined by the GVC definition. Your workload may run in a single region of one cloud, or across many regions of all the three clouds – depending up to the GVC definition. Requests are routed to the nearest healthy location.

Workloads are managed using a common interface, regardless of cloud providers. Workload log data are consolidated for easy retrieval and analysis. This means that a workload can run across AWS, Azure and GCP, yet its log – across instances and providers is accessed using a single API/CLI/UI/Grafana operation.

Reference

For detailed workload configuration options see the Workload Reference.

Features

• Auto Scaling
• DNS geo-routing
• Capacity AI - Intelligent resource management
• Load balancing
• Location specific override of scaling and resource management
• Logging
• Probes
• Alerts

Auto Scaling

Workload replicas are automatically scaled up and down based on the selected scaling strategy.

Selectable Scaling Strategies:

• Disabled
• CPU Utilization
• Memory Utilization
• Concurrent Requests Quantity
• Requests Per Second
• Request Latency

See Autoscaling for more information.

The minimum and maximum number of replicas that can be deployed are configurable. Scale to zero is available for Serverless workloads using the rps or concurrency scaling strategies, and for Standard and Stateful workloads when using KEDA. When there is no traffic, the workload can scale down to 0 and scale up immediately to fulfill new requests.

Capacity AI is not available if CPU Utilization is selected because dynamic allocation of CPU resources cannot be accomplished while scaling replicas based on the usage of its CPU. See Capacity AI Restrictions for the full list.

Capacity AI

A workload can leverage intelligent allocation of its container’s resources (CPU and Memory) by using Capacity AI.

Capacity AI uses historical usage analysis to adjust these resources up to a configured maximum.

This approach can substantially reduce costs; however, it may result in temporary performance issues during sudden spikes in usage.

Before enabling capacity AI on your workload, review the Capacity AI reference page

Location Override

By default, both Capacity AI and Auto Scaling settings are applied to all deployments at each location enabled in the GVC. However, these settings can be customized per location to enhance performance for specific audiences.

This allows for granular control over how your workload scales in specific locations. For instance, if the majority of your users are in Europe, you can set the European locations to a higher level than the rest of the world.

Setting local options ensures that your target users are served quickly and helps reduce costs for unused resources.

Probes

Probes are a Kubernetes feature that are used to monitor the health of an application running in a container.

Each container can have a:

• Readiness Probe

  • An endpoint is configured to allow queries, enabling you to check if the workload is available and ready to receive requests.

• Liveness Probe

  • An endpoint is configured to allow queries, enabling you to check if the workload is healthy or needs to be restarted.

Alerts

Using Grafana, you can create alerts on any of the standard metrics exposed by Control Plane, or on your custom metrics. To access Grafana, navigate to one of your orgs in the Control Plane console and click the “Metrics” link.

You have full access to Grafana alerting capabilities. For more information, see the the Grafana documentation

Reference

Visit the workload reference page for additional information.

Inter-Workload Networking

Workloads are reachable by other workloads at <workload-name>.<gvc-name>.cpln.local, but inter-workload traffic is denied by default. Each receiving workload must opt in by setting firewallConfig.internal.inboundAllowType to one of:

• same-gvc — allow workloads in the same GVC.
• same-org — allow workloads anywhere in the same org.
• workload-list — allow specific workloads listed in inboundAllowWorkload (can span GVCs).

The default is none, which blocks all inter-workload traffic.

Types

• Serverless:
  • Workloads that scale to zero when they aren’t receiving requests.
• Standard:
  • Workloads that serve network traffic on multiple ports, but do not scale to zero.
• Cron:
  • Workloads that run on a schedule, and do not serve network traffic.
• Stateful:
  • Similar to a standard workload, stateful workloads have stable replica identities and hostnames, and can mount a volume set for persistent storage.