Kubernetes provides many ways to configure pods and containers.
- Environment variables
- Config maps
- Secrets
- Security context
- Resource requirements
- Service accounts
ConfigMaps
Kubernetes manages application configurations in the form of ConfigMaps. ConfigMaps store configuration data as key/value pairs and provide them to containers.
ConfigMaps can be accessed from a pod using:
- Environment variables (as key/value pairs)
- ConfigMap Volume (as files)
Creating ConfigMaps
- Creating a ConfigMap from literals:
kubectl create configmap <name> --from-literal=<key>=<value>
kubectl create configmap my-config-map \
--from-literal=APP-TYPE=web \
-–from-literal=APP-MODE=dev
kubectl get cm
kubectl describe cm my-config-map
kubectl get cm my-config-map -o yaml > my-config-map.yaml
- Creating a ConfigMap using the definition file:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config-map
data:
key1: value1
APP-TYPE: web
APP-MODE: dev
- Creating a ConfigMap from a config file: It will create an only 1 entry.
# key: file name, value: the list of key/value pairs
kubectl create cm my-config-map --from-file=my-config.config
# my-config.config
key1=value1
key2=value2
# matching yaml
data:
my-secret.config:
- key1=value1
key2=value2
- Creating a ConfigMap from a map file: It will create key/value pairs.
# file name is not a key. key: key, value: value
kubectl create cm my-config-map --from-env-file=my-config.env
# my-config.env
key1=value1
key2=value2
# matching yaml
data:
key1: value1
key2: value2
- Checking ConfigMaps:
kubectl get cm
kubectl describe cm my-config-map
kubectl delete cm my-config-map
Using Environment Variables with ConfigMaps
You can access the configuration values as environment variables using the “configMapRef” and “configMapKeyRef“
- Configure all key-value pairs:
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: my-container
image: busybox
command: ['echo']
args: ['$(APP-TYPE)']
envFrom:
- configMapRef:
name: my-config-map
- Configure a single value:
spec:
containers:
- name: my-container
image: busybox
command: ['echo']
args: ['$(APP-TYPE)']
env:
- name: APP-TYPE
valueFrom:
configMapKeyRef:
name: my-config-map
key: APP-TYPE
Mounting as a volume with ConfigMaps
- Each ConfigMap key becomes a file in the volume.
spec:
containers:
- name: my-container
image: busybox
command: ['echo']
args: ['$(APP-TYPE)']
volumeMounts:
- mountPath: /etc/config
name: config-volume
volumes:
- name: config-volume
configMap:
name: my-config-map
restartPolicy: Never
SecurityContext
The “SecurityContext” is the part of pod spec that defines privilege and access control settings for a pod.
- The SecurityContext configurations can be applied at either the pod or container level.
- It can define special operating system level permissions such as who can run the pod.
- runAsUser
- runAsGroup
- fsGroup
- The SecurityContext can be set in a container level or a pod level.
- The container setting will override the pod setting.
spec:
securityContext:
runAsUser: 2000
fsGroup: 4000
containers:
- name: my-container
image: busybox
securityContext:
runAsUser: 3000
allowPrivilegeEscalation: false
- You can grant certain privileges to a process without granting all the privileges of the root user.
- Include the capabilities field in the SecurityContext section of the Container manifest.
spec:
containers:
- name: my-container
image: busybox
securityContext:
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Container Resource Requirements
In a pod spec, you can specify the resources requirements of a container, which are defined in terms of resource requests and limits.
- Container Memory and CPU requirements
spec:
containers:
- name: myapp-container
image: busybox
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Resource Quotas
- A resource quota provides constraints that limit aggregate resource consumption per namespace.
kubectl create quota myrq \
--hard=cpu=1,memory=1G,pods=2
apiVersion: v1
kind: ResourceQuota
metadata:
name: myrq
spec:
hard:
cpu: "1"
memory: 1G
pods: "2"
kubectl get quota
kubectl describe quota myrq
Service Accounts
You can use a specialized ServiceAccounts with restricted permissions to allow containers to access the Kubernetes API.
kubectl create serviceaccount <account-name>
kubectl get serviceaccounts
kubectl get sa
# get details and a token
kubectl describe sa <account-name>
kubectl describe sa default
# check the token
Kubectl descrtibe secret <token-name>
- Specify a “SeviceAccountName” in the pod spec.
spec:
serviceAccountName: <account-name>
Scriptorium 