Managing Service Resources

Working with defaults and overrides for resources

Your default or environment specific configuration always include a default resources section. This stanza consists of resource default s for:

  • cpu : limits and resources (required)

  • memory : limits and resources (required)

  • replicas (required)

  • storage : type and size

These values are directly related to Kubernetes definitions of resources. You can read more about resources here.

resources:
cpu:
limits: 2000m
requests: 100m
memory:
limits: 16Gi
requests: 100Mi
replicas: 1
storage:
size: 9Gi
type: aws-efs

Exampe of default resources stanza

Overriding Resources

You can override services in two different sections of your Default Environment Configuration: in the services section and/or in a particular environment template.

resources:
cpu:
limits: 1000m
requests: 100m
memory:
limits: 2Gi
requests: 100Mi
replicas: 1

Defaults for this example

In this example we will want to do three things:

  • Add extra memory for our frontend service for all environments

  • Have two backend replicas for all environments

  • In our production environment we want 5 backend replicas and 10 frontend replicas

Add extra memory for our frontend service in all environments

services:
- name: frontend
image: releaseapp/spacedust/frontend
command:
- "./start.sh"
registry: local
ports:
- type: node_port
target_port: '4000'
port: '4000'
memory:
limits: 4Gi
requests: 500Mi
static: true
build_command: GENERATE_SOURCEMAP=false yarn build
build_base: frontend
build_output_directory: build/

Memory limits to 4Gi and requests to 500Mi

Now every environment will have 4Gi memory limit and a 500Mi request for each frontend instance, while every other service instance will have a 2Gi memory limit and 100Mi request value.

Always deploy 2 backend replicas as default

In order to make sure we always have 2 backend replicas no matter which kind of environment we are deploying, we will need to override the replicas for the backend service in our default environment config.

services
- name: backend
image: releaseapp/spacedust/backend
command:
- "./run-spacedust.sh"
registry: local
depends_on:
- postgres
- redis
ports:
- type: node_port
target_port: '3000'
port: '3000'
replicas: 2

Always deploy 2 instances of the backend service

Once we override replicas under the service definition for backend, every environment we deploy based on our default environment configuration will always deploy two instances of the backend service, while only deploying one instance of each other service.

Make sure production always has 5 backend and 10 frontend instances

So, now we have our default overrides the way we want we need to modify production because it serves a lot more traffic then any ephemeral or staging environment. In order to do this we need to create our 'production' space, then modify the environment specific configuration.

services:
- name: frontend
image: releaseapp/spacedust/frontend
command:
- "./start.sh"
registry: local
ports:
- type: node_port
target_port: '4000'
port: '4000'
replicas: 10
memory:
limits: 4Gi
requests: 500Mi
static: true
build_command: GENERATE_SOURCEMAP=false yarn build
build_base: frontend
build_output_directory: build/
- name: backend
image: releaseapp/spacedust/backend
command:
- "./run-spacedust.sh"
registry: local
depends_on:
- postgres
- redis
ports:
- type: node_port
target_port: '3000'
port: '3000'
replicas: 5

Set replicas for fronted and backend to 10 and 5 respectively

Once the replicas are overridden for the environment specific configuration you can then deploy that configuration and your 'production' environment will have the 5 backend instances and 10 frontend instances running in the cluster. All of the rest of your environments will not be affected by these changes, because they are specific to your 'production' environment.