Component Sizing

Use Halyard to size your Spinnaker services to meet your usage requirements.

Custom sizing can be specified for each Spinnaker component within the Halyard configuration. You can either add these sizes to the Halyard config manually, or use any of the Halyard component sizing commands . This feature is currently only supported for distributed deployments using Kubernetes (hal config deploy edit --type distributed --account-name my-k8s-cluster).

Kubernetes

The following Kubernetes settings can be tweaked within custom sizing.

CPU & Memory requests/limits

Container requests and limits for cpu and memory can be specified in the deploymentEnvironment.customSizing section of the halconfig file.

There are two ways to specify requests and limits

  • (Recommended) By supplying the container name, e.g. echo:, followed by the container requests and limits.

    This sets resource configuration for the echo container in spin-echo service’s pod only, not any sidecars (e.g. the monitoring daemon).

  • By supplying the service name, e.g. spin-clouddriver:, followed by the container requests and limits.

    This sets the resource configuration for the clouddriver container as well as any sidecar containers in the spin-clouddriver service.

Here is an example of this configuration:

  1. deploymentEnvironment:
  2.   customSizing:
  3.     # This applies sizings to only the echo container and not to any sidecar 
  4.     # containers running with echo. (Use spin-<service> to include sidecars)
  5.     echo:
  6.       limits:
  7.         cpu: 250m
  8.         memory: 512Mi
  9.       requests:
  10.         cpu: 100m
  11.         memory: 128Mi
  12.     # This applies sizings to the clouddriver container as well as any sidecar 
  13.     # containers running with clouddriver. (Use without spin- to only include the clouddriver container)
  14.     spin-clouddriver:
  15.       limits:
  16.         cpu: 1000m
  17.         memory: 1Gi
  18.       requests:
  19.         cpu: 250m
  20.         memory: 512Mi

Limits and requests follow the Kubernetes conventions documented here .

Updating JAVA_OPTS

All JVM-based services have the following JAVA_OPTS set:

  1. JAVA_OPTS=-XX:MaxRAMPercentage=50.0

This sets the JVM’s heap size to half the memory allocated per container. This can be overriden by specifying your own JAVA_OPTS using the env key in service-settings .

As a starting point, the -Xms can be set to 80%-90% of the requests memory allotment and -Xmx can be set to 80-90% of the limits memory allotment. For the clouddriver example above, the env key is as follows:

  1. env:
  2.    JAVA_OPTS: "-Xms410m -Xmx819m"

Recommendations

It is not recommended that limits and requests be applied to the bootstrapping pods. These pods can be scaled down to 0 once hal deploy apply has been completed. They will be relaunched the next time a hal deploy apply is executed.

Optimal sizings for your components will depend upon your environment, but in general clouddriver and orca will need to be larger than the rest of the components, additionally echo may also need to be larger if using event hooks.

Replicas

The number of desired replicas for a component can be specified within customSizing like so:

  1. customSizing:
  2.   spin-[component name]:
  3.     replicas: 2

If the number of replicas isn’t specified for a component halyard will deploy said component with the same number of replicas it had during the previous deployment. On the initial deployment of spinnaker all pods will default to 1 replica if nothing is specified within customSizing.

Important: To avoid duplicate triggering, echo and igor must each be deployed with exactly one pod.

Last modified May 4, 2021: rest of migration (700781a)