General

​

Overview

Refer to the Workload concepts page.

​

Create a Workload

Refer to the Create a Workload guide for additional details.

​

Access Report

Displays the permissions granted to principals for the workload.

​

Identity

Refer to the identities page for additional details.

​

Connect

A specific replica of a workload can be connected to (similar to exec) from either the console or the CLI. This can be used for troubleshooting any issues with the replica.

To connect using the console, click the Connect link from a workload. Select the location, container, replica, and command. Click Connect to execute the command. By default, the bash shell will be executed.

To connect using the CLI, review the workload connect subcommand.

​

Debug

In order to see detailed routing for the global georouted endpoint of a workload, debug values can be included within the response headers of a workload’s endpoint request.

The values will only be returned when:

1. debug is active and the header x-cpln-debug: true is in the request.
2. The global or canonical endpoint is being requested.

Using the console, debug can be activated by:

• Clicking Options.
• Clicking the Debug switch to on.
• Clicking Save.

After the workload redeploys, the response from the workload’s endpoint will contain the following headers if the header x-cpln-debug: true is in the request:

• x-cpln-location: Location of the responding replica.
• x-cpln-replica: Name of the responding replica.

​

Endpoints

​

Canonical Endpoint (global)

This URL is globally load-balanced and TLS terminated. This can be used for testing if there is an issue with the custom domain that is associated with the GVC.

​

Location Specific Endpoint

Within each deployment, a location specific URL is available that can be used for testing how your app is responding from a specific location of a GVC.

​

Custom Domain Endpoints

Additional globally load-balanced endpoints will show in the workload status for each domain route that is configured to use this workload.

​

Internal Mutual-TLS Endpoint

Format: $workloadName.$gvcName.cpln.local:$port

Each workload can be allowed to receive requests from other workloads in the same Org internally using the provided internal endpoint. Access to this endpoint is controlled by the internal firewall settings.

​

Inter-Container Communication

Containers deployed within the same workload can communicate with each other using their names and assigned ports. This setup facilitates direct networking between containers.

• Container Identification - Each container is uniquely identified by its name.
• Port Allocation - Containers are assigned specific ports for network communication.

​

Example Scenario

• Imagine two containers within the same workload: foo and bar.
• Container foo is running on port 4020.
• Container bar is running on port 4030.

foo can access bar using the URL http://bar:4030. This URL combines the name of the destination container bar and its assigned port 4030, enabling direct communication between the two containers.

This method ensures efficient and organized networking within a multi-container workload environment.

​

Built-in Variables

Each workload has the following built-in environment variables:

​

Logs

Workload logs are consolidated from all the deployed locations and can be viewed using the UI or CLI.

Using the UI, the logs page will be prefilled with the LogQL query for the workload and GVC name.

  {gvc="test-gvc", workload="test-workload"}

Logs can be further filtered by:

• Date
• Location
• Container

Grafana can be used to view the logs by clicking the Explore on Grafana link within the console.

Refer to the logs page for additional details.

​

Rollout Options

Settings to control the rollout process between versions.

spec:
  rolloutOptions:
    minReadySeconds: 0
    maxUnavailableReplicas: 1
    maxSurgeReplicas: 100%
    scalingPolicy: OrderedReady

​

minReadySeconds

The minimum number of seconds that a workload replica must be running before the rollout progresses.

​

maxUnavailableReplicas

The maximum number or percentage of replicas that can be unavailable during a rollout or during regular rescheduling of workloads.

​

maxSurgeReplicas

The maximum number or percentage of new replicas that can added during a rollout for each batch.

Example: If there are 4 running replicas and maxSurgeReplicas is set to 50%, then during each rollout 2 replicas will be added at the new version. Once they are healthy as determined by the ReadinessProbe, the rollout will continue, -2 old replicas, +2 new replicas, -2 old replicas.

In cases where a short rollout cutover is needed, a maxSurgeReplicas setting of 100% is recommended.

​

scalingPolicy

The strategies used to update applications and services deployed. Valid values: OrderedReady (Updates workloads in a rolling fashion, taking down old ones and bringing up new ones incrementally, ensuring that the service remains available during the update.), Parallel (Causes all pods affected by a scaling operation to be created or destroyed simultaneously. This does not affect update operations.). Default: OrderedReady.

​

Default Ephemeral Storage

Each workload replica receives at least 1GB of local ephemeral solid state drive (SSD) storage. Workloads that request more than 1 core of CPU receive 1GB of storage for each core. For example, a workload that requests 1500 millicore of CPU can consume up to 1.5GB of ephemeral storage.

If the replica uses more than its allotted ephemeral storage, it will be replaced with a new replica.

​

Suspend

Each workload can be suspended which immediately stops the workload from serving traffic. This is the same as setting the min/max scale to 0. When the workload is unsuspended, it will resume serving traffic.

To temporarily deactivate a workload choose Stop from the Actions menu.

spec:
  defaultOptions:
    suspend: true

The workload will stop running and will not serve any traffic.

To reactivate the workload, choose Start from the actions menu.

spec:
  defaultOptions:
    suspend: false

​

Timeout

The maximum request duration in seconds before Control Plane will timeout. This timeout amount can be reached when Control Plane is waiting for the workload to respond or when waiting for a new workload to become available when using Autoscaling.

The minimum value is 1 second and the maximum value is 600 seconds.

​

Metering and Billing

The CPU, memory and egress used for mounted object stores are billed to the workload. To review the costs of mounting an object store, query the container named cpln-mounter for the workload within the metrics page.

​

Workload Health

• Possible values:
  • Loading
  • Healthy
  • Unhealthy
  • Deleting
  • Unknown

​

CLI

To view the CLI documentation for Workloads, click here.