Configuring the Defaults ConfigMap

The config-defaults ConfigMap, known as the Defaults ConfigMap, contains settings that determine how Knative sets default values for resources.

This ConfigMap is located in the knative-serving namespace.

You can view the current config-defaults ConfigMap by running the following command:

  1. kubectl get configmap -n knative-serving config-defaults -oyaml

Example config-defaults ConfigMap

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-timeout-seconds: "300"
  8. max-revision-timeout-seconds: "600"
  9. revision-cpu-request: "400m"
  10. revision-memory-request: "100M"
  11. revision-ephemeral-storage-request: "500M"
  12. revision-cpu-limit: "1000m"
  13. revision-memory-limit: "200M"
  14. revision-ephemeral-storage-limit: "750M"
  15. container-name-template: "user-container"
  16. container-concurrency: "0"
  17. container-concurrency-max-limit: "1000"
  18. allow-container-concurrency-zero: "true"
  19. enable-service-links: "false"

See below for a description of each property.

Properties

Revision timeout seconds

The revision timeout value determines the default number of seconds to use for the revision’s per-request timeout if none is specified.

  • Global key: revision-timeout-seconds
  • Per-revision annotation key: timeout
  • Possible values: integer
  • Default: "300" (5 minutes)

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-timeout-seconds: "300"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. timeout: 300
  10. containers:
  11. - image: gcr.io/knative-samples/helloworld-go

Max revision timeout seconds

The max-revision-timeout-seconds value determines the maximum number of seconds that can be used for revision-timeout-seconds. This value must be greater than or equal to revision-timeout-seconds. If omitted, the system default is used (600 seconds).

If this value is increased, the activator’s terminationGraceTimeSeconds should also be increased to prevent in-flight requests from being disrupted.

  • Global key: max-revision-timeout-seconds
  • Per-revision annotation key: N/A
  • Possible values: integer
  • Default: "600" (10 minutes)

Example:

Global (ConfigMap)

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. max-revision-timeout-seconds: "600"

Revision CPU request

The revision-cpu-request value determines the CPU allocation assigned to revisions by default. If this value is omitted, the system default is used. This key is not enabled by default for Knative.

  • Global key: revision-cpu-request
  • Per-revision annotation key: cpu
  • Possible values: integer
  • Default: "400m" (0.4 of a CPU, or 400 milli-CPU)

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-cpu-request: "400m"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - image: gcr.io/knative-samples/helloworld-go
  11. resources:
  12. requests:
  13. cpu: "400m"

Revision memory request

The revision-memory-request value determines the memory allocation assigned to revisions by default. If this value is omitted, the system default is used. This key is not enabled by default for Knative.

  • Global key: revision-memory-request
  • Per-revision annotation key: memory
  • Possible values: integer
  • Default: "100M" (100 megabytes of memory)

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-memory-request: "100M"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - image: gcr.io/knative-samples/helloworld-go
  11. resources:
  12. requests:
  13. memory: "100M"

Revision Ephemeral Storage Request

The revision-ephemeral-storage-request value determines the ephemeral storage allocation assigned to revisions by default. If this value is omitted, the system default is used. This key is not enabled by default for Knative.

  • Global key: revision-ephemeral-storage-request
  • Per-revision annotation key: ephemeral-storage
  • Possible values: integer
  • Default: "500M" (500 megabytes of storage)

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-ephemeral-storage-request: "500M"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - image: gcr.io/knative-samples/helloworld-go
  11. resources:
  12. requests:
  13. ephemeral-storage: "500M"

Revision CPU limit

The revision-cpu-limit value determines the default CPU allocation limit for revisions. If this value is omitted, the system default is used. This key is not enabled by default for Knative.

  • Global key: revision-cpu-limit
  • Per-revision annotation key: cpu
  • Possible values: integer
  • Default: "1000m" (1 CPU, or 1000 milli-CPU)

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-cpu-limit: "1000m"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - image: gcr.io/knative-samples/helloworld-go
  11. resources:
  12. requests:
  13. cpu: "1000m"

Revision memory limit

The revision-memory-limit value determines the default memory allocation limit for revisions. If this value is omitted, the system default is used. This key is not enabled by default for Knative.

  • Global key: revision-memory-limit
  • Per-revision annotation key: memory
  • Possible values: integer
  • Default: "200M" (200 megabytes of memory)

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-memory-limit: "200M"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - image: gcr.io/knative-samples/helloworld-go
  11. resources:
  12. requests:
  13. memory: "200M"

Revision Ephemeral Storage Limit

The revision-ephemeral-storage-limit value determines the default ephemeral storage limit allocated to revisions. If this value is omitted, the system default is used. This key is not enabled by default for Knative.

  • Global key: revision-ephemeral-storage-limit
  • Per-revision annotation key: ephemeral-storage
  • Possible values: integer
  • Default: "750M" (750 megabytes of storage)

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. revision-ephemeral-storage-limit: "750M"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - image: gcr.io/knative-samples/helloworld-go
  11. resources:
  12. requests:
  13. ephemeral-storage: "750M"

Container name template

The container-name-template value provides a template for the default container name if no container name is specified. This field supports Go templating and is supplied by the ObjectMeta of the enclosing Service or Configuration, so values such as {{.Name}} are also valid.

  • Global key: container-name-template
  • Per-revision annotation key: name
  • Possible values: string
  • Default: "user-container"

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. container-name-template: "user-container"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - name: user-container
  11. image: gcr.io/knative-samples/helloworld-go

Container concurrency

The container-concurrency value specifies the maximum number of requests the container can handle at once. Requests above this threshold are queued. Setting a value of zero disables this throttling and lets through as many requests as the pod receives.

  • Global key: container-concurrency
  • Per-revision spec key: containerConcurrency
  • Possible values: integer
  • Default: "0"

Example:

Global (ConfigMap)Per Revision

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. container-concurrency: "0"
  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4. name: helloworld-go
  5. namespace: default
  6. spec:
  7. template:
  8. spec:
  9. containerConcurrency: 0

Container concurrency max limit

The container-concurrency-max-limit setting disables arbitrary large concurrency values, or autoscaling targets, for individual revisions. The container-concurrency default setting must be at or below this value. The value of the container-concurrency-max-limit setting must be greater than 1.

Note

Even with this set, a user can choose a containerConcurrency value of zero (unbounded), unless allow-container-concurrency-zero is set to "false".

  • Global key: container-concurrency-max-limit
  • Per-revision annotation key: N/A
  • Possible values: integer
  • Default: "1000"

Example:

Global (ConfigMap)Global (Operator)

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. container-concurrency-max-limit: "1000"
  1. apiVersion: operator.knative.dev/v1beta1
  2. kind: KnativeServing
  3. metadata:
  4. name: knative-serving
  5. namespace: knative-serving
  6. spec:
  7. config:
  8. defaults:
  9. container-concurrency-max-limit: "1000"

Allow container concurrency zero

The allow-container-concurrency-zero value determines whether users can specify 0 (unbounded) for containerConcurrency.

  • Global key: allow-container-concurrency-zero
  • Per-revision annotation key: N/A
  • Possible values: boolean
  • Default: "true"

Example:

Global (ConfigMap)

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. allow-container-concurrency-zero: "true"

The enable-service-links value specifies the default value used for the enableServiceLinks field of the PodSpec when it is omitted by the user. See the Kubernetes documentation about the enableServiceLinks feature.

This is a tri-state flag with possible values of (true|false|default).

In environments with large number of Services, it is suggested to set this value to false. See serving#8498.

  • Global key: enable-service-links
  • Per-revision annotation key: N/A
  • Possible values: true|false|default
  • Default: "false"

Example:

Global (ConfigMap)

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: config-defaults
  5. namespace: knative-serving
  6. data:
  7. enable-service-links: "false"