[Kubernetes] Configurations

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>    


Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s