Managing compute resources

When a Pod is created it may request CPU and RAM resources. This is the minimum amount required for the Pod to run. It may also specify the maximum resources that the containers are allowed to consume. Both Pod limits and requests can be set in the specification of any object managed by the operator (Elasticsearch, Kibana or the APM server). For more information on how this is used by Kubernetes, see Managing Compute Resources for Containers.

The resources can be customized in the podTemplate of an object.

Here is an example for Elasticsearch:

spec:
  nodes:
  - podTemplate:
      spec:
        containers:
        - name: elasticsearch
          env:
          - name: ES_JAVA_OPTS
            value: -Xms2048M -Xmx2048M
          resources:
            requests:
              memory: 2Gi
              cpu: 1
            limits:
              memory: 4Gi
              cpu: 2

This example also demonstrates how to set the JVM memory options accordingly, by using the ES_JAVA_OPTS environment variable.

The same applies for every custom resource type managed by the operator. Use this code to customize resource requests and limits for Kibana:

spec:
  podTemplate:
    spec:
      containers:
      - name: kibana
        resources:
          requests:
            memory: 1Gi
            cpu: 1
          limits:
            memory: 2Gi
            cpu: 2

Use this code to customize resource requests and limits on the APM server:

spec:
  podTemplate:
    spec:
      containers:
      - name: apm-server
        resources:
          requests:
            memory: 1Gi
            cpu: 1
          limits:
            memory: 2Gi
            cpu: 2

If there’s no resources set in the specification of an object, then no requests or limits are applied on the containers, with the notable exception of Elasticsearch. For Elasticsearch, if no memory request is set in the podTemplate spec, the operator applies a default memory request of 2Gi. This is because Elasticsearch must have a minimum amount of memory to perform correctly.

There can be conflicts if resources are managed with some LimitRanges at the namespace level and if a minimum memory constraint is imposed.

For example, you may want to apply a default request of 3Gi and enforce it as a minimum with a constraint:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-mem-per-container
spec:
  limits:
  - min:
      memory: "3Gi"
    defaultRequest:
      memory: "3Gi"
    type: Container

But if there is no resources declared in the specification, then the Pod can’t be created and the following event is generated:

default     0s          Warning   Unexpected              elasticsearch/elasticsearch-sample                                            Cannot create pod elasticsearch-sample-es-ldbgj48c7r: pods "elasticsearch-sample-es-ldbgj48c7r" is forbidden: minimum memory usage per Container is 3Gi, but request is 2Gi

To solve this situation, you can define an empty limits section in the specification:

spec:
  nodes:
  - podTemplate:
      spec:
        containers:
        - name: elasticsearch
          resources:
            # specify empty limits
            limits: {}

The default requests is not set by the operator and the Pod is created.