Managing GraphOS Router Resources in Kubernetes

Recommendations and considerations for application pods

Self-hosting the GraphOS Router is limited to GraphOS Enterprise plans. Other plan types use managed cloud routing with GraphOS. Check out the pricing page to learn more.

Determining the correct resource requests and limits for your application pods in a Kubernetes system is not an exact science. Your specific needs depend on many factors, including:

  • The cardinality of unique operation shapes

  • The latency of underlying subgraphs and data sources

  • The size of responses

  • The complexity of query plans

Our general recommendation for Kubernetes is to start with these requests and limits:

YAML
1resources:
2  requests:
3    memory: '1G'
4    cpu: '1000m'
5  limits:
6    memory: '2G'
7    # no CPU limit to avoid throttling
tip
The router resource estimator is a helpful tool for getting a starting baseline for what resources you may need in production based on your expected traffic.

When using Horizontal pod autoscaling, we recommend targeting 90% utilization:

YAML
1metrics:
2  - type: Resource
3    resource:
4      name: cpu
5      target:
6        type: Utilization
7        averageUtilization: 90
8  - type: Resource
9    resource:
10      name: memory
11      target:
12        type: Utilization
13        averageUtilization: 90

The GraphOS Router starts up quickly, but when connected to GraphOS the router has to fetch the supergraph schema from Apollo Uplink before it can start serving traffic. We recommend measuring your router's startup time and lowering the averageUtilization if your startup time is longer due to Uplink latency or the size of your supergraph schema.
Feedback

Edit on GitHub

Forums