Container environment variables (for example, DB_HOST=db.example.com) are configuration parameters dynamically transferred when a container is running. They allow you to flexibly adjust application behaviors and settings without rebuilding the image. They provide:
You can modify environment variables even after workloads are deployed, increasing flexibility in workload configuration. Configuring environment variables on CCE has the same function as specifying ENV in a Dockerfile. For more information, see Defining Environment Variables for a Container.
Before using a ConfigMap or secret as an environment variable, ensure that the ConfigMap and secret have been created in the cluster. For details about how to create a ConfigMap and secret, see Creating a ConfigMap and Creating a Secret.
Figure 1 Configuring environment variables

Parameter | Description |
|---|---|
Type | Environment variable type. The options are as follows:
|
Variable Name | Name of the environment variable set in the container. |
Variable Value/Reference | The value of an environment variable or the value of an environment variable obtained from other sources. |
Assume that a ConfigMap and a secret are already available in the cluster. For details about how to create them, see Creating a ConfigMap and Creating a Secret.
kubectl get configmap configmap-example -oyaml
Information similar to the following is displayed:
apiVersion: v1data:configmap_key: configmap_valuekind: ConfigMap...
kubectl get secret secret-example -oyaml
Information similar to the following is displayed:
apiVersion: v1data:secret_key: c2VjcmV0X3ZhbHVl # c2VjcmV0X3ZhbHVl is the value of secret_value in Base64 mode.kind: Secret...
vi nginx-deployment.yaml
Configure environment variables in the workload YAML file. The following is an example:
apiVersion: apps/v1kind: Deploymentmetadata:name: env-examplenamespace: defaultspec:replicas: 1selector:matchLabels:app: env-exampletemplate:metadata:labels:app: env-examplespec:containers:- name: container-1image: nginx:alpineimagePullPolicy: Alwaysresources:requests:cpu: 250mmemory: 512Milimits:cpu: 250mmemory: 512Mienv:- name: key # Define the environment variable name and value.value: value- name: key1 # Import the value of a key in the ConfigMap as the value of an environment variable.valueFrom:configMapKeyRef:name: configmap-examplekey: configmap_key- name: key2 # Import the value of a key in the secret as the value of an environment variable.valueFrom:secretKeyRef:name: secret-examplekey: secret_key- name: key3 # Use the field defined by the pod as the value of an environment variable.valueFrom:fieldRef:apiVersion: v1fieldPath: metadata.name- name: key4 # Use the value of the resource request or limit defined in the container as the value of an environment variable.valueFrom:resourceFieldRef:containerName: container1resource: limits.cpudivisor: 1envFrom:- configMapRef: # Import all key values in a ConfigMap as environment variables.name: configmap-example- secretRef: # Import all key values in a secret as environment variables.name: secret-exampleimagePullSecrets:- name: default-secret
kubectl create -f nginx-deployment.yaml
If information similar to the following is displayed, the workload is being created:
deployment.apps/env-example created
kubectl get pod
Information similar to the following is displayed:
NAME READY STATUS RESTARTS AGEenv-example-695b759569-lx9jp 1/1 Running 0 17m
kubectl exec env-example-695b759569-lx9jp -- printenv
If information similar to the following is displayed, the environment variables are configured successfully:
/ # envkey=value # Custom environment variablekey1=configmap_value # Added from a ConfigMap keykey2=secret_value # Added from a secret keykey3=env-example-695b759569-lx9jp # metadata.name defined by the podkey4=1 # limits.cpu defined by container1. The value is rounded up, in unit of cores.configmap_key=configmap_value # Added from a ConfigMap. The key value in the original ConfigMap key is imported.secret_key=secret_value # Added from a secret. The key value in the original secret is imported.