You can use this document to learn basic edge compute concepts, particularly for workloads.
Review common terms
A stack is a container of one or more StackPath services, such as CDN, WAF, DNS, and more.
Everything in a stack shares the same:
StackPath utilizes the concept of stacks to simplify the management of multiple sites, based on technical requirements, as well as to help with track billing.
A workload is a container or virtual machine image that is deployed to one or many locations.
A workload defines the specifications of its instances, including where to run.
A workload can be updated at any time to change specifications or targets.
An instance is a grouping of cores, memory, and storage that determines the workload performance.
An instance can deploy as a virtual machine or container.
A virtual machine is a full software emulation of a physical computer that can perform all operating system tasks.
Each virtual machine runs a full operating system and is allocated with virtualized system hardware.
A container packages application code, dependencies, and configurations into a single object that can be deployed in any environment.
Containers are created from container images.
|Geometry||Geometry refers to the cores and memory that make up an instance.|
A slug is a workload identifier that is:
|Spec||A workload's spec describes what you want to run in the workload's instances.|
|Virtual Private Cloud (VPC)||A VPC is a secure, logical network group defined by an IP address's Classless Inter Domain Range (CIDR).|
|Anycast IP address||An Anycast IP address is an IP address shared by more than one workload, which allows users to connect from different locations.|
A sidecar container is an additional container added to the main container in an instance.
Root disk is ephemeral storage used to power a virtual machine's operating system or a container's storage needs.
A workload defines:
- The compute instances to run
- The location to run instances
- The number of instances
When you create a workload, the Edge Compute platform will continuously work to ensure instances are running as specified.
The software inside of an instance will vary by use case; some instances may run HTTP servers or may run distributed databases, or proprietary network optimization platforms.
Based on your workload's specification, you can create one or more instances.
In general, an instance is an allocation of the following resources:
|CPU cores||Not applicable|
|Disk space||Not applicable|
There are 2 types of instance runtimes, containers and virtual machines.
When you define a workload, you must select a single runtime.
A single virtual machine runs an operating system distribution based on your specifications, such as CentOS, Ubuntu, or Debian.
A virtual machine will have a full set of OS processes running, which will include an SSH server.
When you create a virtual machine, you must provide an image that contains the desired operating system.
One or more containers can run within an instance, share the same IP addresses, and can communicate with each other over the network via locahost.
Review the following settings that are specific to a container:
Virtual machine settings
A single virtual machine can run within an instance.
Review the following settings that are specific to a virtual machine:
Settings for containers and virtual machines
Review the following settings for both containers and virtual machines:
|Containers and virtual machines||Named ports||
To leverage SRV queries in the DNS Discovery feature, ports must be defined to provide a name to be used in the SRV query.
Each port will define the network port number which it will listen on, and the protocol for which it will answer (TCP or UDP).
|Containers and virtual machines||Probes||
|Containers and virtual machines||Resources||
|Containers and virtual machines||Volume Mounts||
|Containers and virtual machines||Volume Claim Templates||
Each workload has a slug.
A slug is a workload identifier that is:
- Human readable
The workload slug is used in combination with the stack's slug, the target's name, and other information to compose an instance's name.
When you create a workload, if a slug is not provided, then a slug will be generated based on the workload's name.
If you specify a slug, then the slug must be a valid DNS 1123 label. In other words, a slug must:
- Be between 1 and 63 characters long
Contain lower-case letters or dashes ( - )
- Start and end with an alphanumeric character
- Match the following format:
A workload can be provided with annotations and labels in the form of string key/values. Both can contain arbitrary values that may or may not influence the instances created in the workload.
Annotations allow you to bypass a specification field and influence a workload's behavior.
Review the following table of current annotations:
Labels allow you to identify your instances, which can be useful when used with network policy instance selectors.
All instances are attached to one or more networks via network interfaces. Each stack will have a default network with a root subnet of 10.128.0.0/9, from which instance IPs will be allocated.
Each instance on a network can communicate with peers on the same network, regardless of the location of the peer; however, instances cannot communicate with instances on other networks.
By default, the internet will not be able to reach any instance's external IP address; however, you can create network policies to allow access.
An instance can have one or more network interfaces, each attached to a network. Each network interface will be seen as a discrete interface within the instance, and will have an IP address allocated to it for the attached network. Only the first network interface will have an external unicast IP address allocated to it.
Network interfaces cannot be changed after the creation of a workload.
If no network interface is provided during the creation of a workload, a single network interface will be added and attached to the
default network within the stack the workload is being created in.
A target is used to express where deployments should exist, and how many instances should be within each deployment.
A workload can have one or more target definitions.
You can use multiple targets to organize instances regionally.
- For example, you can create and define a target named eu to only deploy to cities in the European Union. Similarly, you can create and define a target named na to only deploy to cities in North America.
- There are no advantages or disadvantages to creating a single workload with multiple targets or creating multiple workloads.
A target's name must be unique within the workload and be a valid DNS 1123 label; the name is used along with the workload slug and cityCode to generate an instance's name, which is then used in DNS Discovery.
- To learn more, see Edge Compute DNS Discovery.
A target's deployment settings define the following configurations:
Selectors are filters that let the platform know where a workload's instances should exist by defining constraints on label values.
For locations where workload instances can run, the platform exposes a cityCode label that can be used in a deployment's selector by specifying that the label value should contain certain strings, such as DFW, LHR, HKG, or any cityCode value returned by the Locations API call.
Workload deployments can be configured to automatically add and remove instances when the observed values of a metric exceed or fall under a specified threshold.
Currently, the only metric available is cpu.
The deployment scope indicates number of instances (minimum / maximum) that should be in the deployment.
Additionally, the deployment scope influences where individual deployments should be created by specifying the name of a label that exists on locations capable of deploying compute.
For each location matched by the deployment selectors, a unique list of the specified label's values is recorded. For each unique value of the label, a deployment will be created and instances will be created on any location with that value.
Currently, the only valid label for a deployment scope is cityCode.
Updating a workload
When settings for a workload adjust configurations for an instance, the platform will apply the changes for each deployment independently.
Within each deployment, the last instance by ordinal will be updated first, with the remaining instances updated in descending order as updates complete.