Skip to main content

​
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 AWS, Azure, and GCP accounts, or in your own BYOK location. The GVC determines which providers and locations are available. A workload can run in one location or across multiple providers and regions, depending on the GVC and workload placement settings. Workloads are managed using a common interface, regardless of cloud providers. Workload logs are consolidated across replicas, locations, and providers, and can be accessed through the API, CLI, Console, or Grafana.

​
Features

​
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 the scale-to-zero condition is met, 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 between configured minimum and maximum values. 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-specific 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 location-specific options ensures that your target users are served quickly and helps reduce costs for unused resources.

​
Probes

A probe is a Kubernetes feature that is 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 Grafana documentation.

​
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 serve network traffic on multiple ports and can scale to zero only when using KEDA.
  • 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.
  • VM:
    • Run a full virtual machine — its own guest OS and kernel — as a workload, inside the same service mesh, identity, networking, and observability as containers.

​
Reference

See the workload reference page for additional information.