Container Resources

Cycle offers flexible management of CPU and RAM resources for containers, allowing users to define resource allocation policies that work seamlessly across different servers, data centers, and cloud providers.

Reserves vs Limits

Cycle distinguishes between reserves and limits when discussing resources.

• Reserves are resources that have been set aside and taken out of the total pool available on the server or within the cluster.
• Limits are the maximum of a resource that an instance CAN consume, but doesn't necessarily have those resources set aside.

Servers and clusters have a maximum amount of resources (CPU shares, RAM) that each instance deployed counts toward. When the usage for a server is maxed out, instances will no longer be deployed to that server by the platform. When a cluster is maxed out, no more instances can be deployed to the cluster, and an error will occur.

CPU Resource Management

Cycle manages CPU resources using a system of CPU shares, where every physical or virtual CPU core is valued at 10 shares. This allows for a granular allocation of CPU resources to individual containers, helping balance workloads effectively across the infrastructure.

Server and Cluster Reserves

Each container instance on Cycle counts as 2 CPU shares, unless otherwise specified in the container's resource configuration. These shares contribute to the total resource consumption of the server and cluster in which the container is deployed.

Overcommitting CPU Resources

Cycle supports CPU overcommitting, allowing users to allocate more CPU shares than otherwise possible. When overcommitting, the system acts as though there are more CPU cores than physically exist. For example, setting a 2x overcommit ratio would make Cycle pretend there are 2x as many CPU cores available in the cluster, thus increasing the number of shares that can be assigned.

See also: server overcommitting

Max CPU Usage for a Container Instance

The platform determines the maximum allowable CPU usage using several conditions based on the container's configuration and deployment strategy.

Cycle uses the following rules to calculate CPU max usage:

1. Default CPU Allocation

• If no specific CPU limits are configured for a container instance, and no special deployment strategy is set:
  • The platform defaults to allocating 1 CPU core.
  • If the container is deployed on a system with more than 2 cores, the maximum CPU limit is set to 50% of the available CPU cores. For example, if there are 4 cores, the instance can use up to 2 cores.

2. Unlimited CPU Usage

• If the limit for CPU shares is set to 0, the instance has unlimited CPU usage.

3. High Availability or Manual Strategy

• If the deployment strategy is set to High Availability or Manual
  • The instance is assigned a default maximum of 2 CPU cores
  • If the server has more than 4 cores, the instance can use up to 50% of the available cores.

CPU Pinning

Cycle supports pinning instances to specific cores or ranges of cores.

• Single Core: 1
• Range of Cores: 1-4

In a mixed-infrastructure cluster, where servers may have different numbers of cores, it may be desired to set a range that includes the range of cores available on the specific server the instance is deployed to. In that case, the syntax 2-x is used, which would exclude core 1, but include all other cores on the system.

RAM Resource Management

RAM resource management is straight forward when compared to CPU. RAM resource management supports limits and reserves as specified in kilobytes(kb), megabytes(MB), gigabytes(GB) and so on.

Manage Container Resources on cycle

See our dedicated, interface-specific documentation for configuring container resources:

• Portal
• API