CKAD Labs

ConfigMaps and Persistent Volume

April
2020
 Agenda

Lab Demonstration about ConfigMap and Persistence Volume

2
Kubernetes YAML
kind: [Service/Pod/Deployment/Secret/ReplicationController]
apiVersion: [v1, apps/v1]
metadata:
name:
labels:
Basic Details on Kubernetes YAML file
spec:

3
 CLUSTER

ConfigMap ConfigMap
Key1: Value1
How to create and Use Config Map Key2: Value2

• ConfigMaps are Kubernetes Objects which could store

environment variables sets in from of Key and Value
• ConfigMaps are created from Literal, File and EnvFile.
• Any Deployment, POD or Container could use one, more POD
than one or all configKeys from a configMap
• The keys from configMap are added as environment variable
of the container or all the keys of the configMap could be
added to the environment of the container
POD.ENV
POD.ENV

4
SECRET
• Secrets are another form of Configs those are stored as encoded
values
• Secretes are used to store secret information such as password, token
and ssh-key
• Like ConfigMaps seccrets also could be created from Literals, File
Why and How to use Secrets and EnvFile
• Any POD, Deployment could use the secrets
apiVersion: v1 • Secretes could be consumed by containers as whole secret object or
kind: Pod selected keys from the secret
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD 5
valueFrom:
 Service Accounts
How to create and Use Service Account

• Service Accounts are used by applications to access the

APISever inside the pod
• There is a “default” ServiceAccount
• ServiceAccounts are owned by namespace

6
 Security Context apiVersion: v1
How to create and Use Security Context kind: Pod
metadata:
name: security-context-demo-2
spec:
• Security Contexts are privileges and access controls granted
securityContext:
to Pods and Containers
runAsUser: 1000
• The security context added at Pod level is overridden by
context added at container level containers:
• runAsUser – all processes run by specific user - name: sec-ctx-demo-2
image: gcr.io/google-samples/node-hello:1.0
• runAsGroup – all files and processes owned by group
securityContext:
• fsGroup – supplementary group
runAsUser: 2000
allowPrivilegeEscalation: false

7
 Resource Requirements
How to use Computing Resources

• Resource Requirements could be added optionally for POD

definitions
• Valid Resource Types are CPU and Memory and Hugepages
• CPU unit is core and Memory unit is Mi or Gi
• The Resource request and limit are specified at container
level of the POD definition
• Kubernetes takes decision to put the pod in best available
node based on request requirements

8
 Persistent Volumes
How to create and Use Persistent Volumes

• Persistent Volumes are a storage pool created and managed

by Kubernetes

pv-volume.yaml
• Persistent Volumes persists beyond the life cycle of a pod
• Persistent Volumes could be accessed across the cluster
• Persistent Volume support different type storages including
public cloud based storages
• The access to a Persistent Volume is managed in 3 modes -:
ReadWriteOnce, ReadWriteMany and ReadOnlyMany

9
 CLUSTER

Persistent Volume Claims

Mount
Mount
Volume
Volume
POD1
How to create and Use Persistent Volume
Claims
• Persistent Volume Claims are objects those bounds to
Persistent Volumes and mount to Pods so that the container Persistence Volume
Claim
could use the Persistence Volumes
• Persistent Volume Claims are bounded on to a Persistent
Volume based on the labels, access modes, volume modes,
Mount
storage class and Resource Mount
Volume
Volume

POD2

NODE
10
Persistence
Volume
THANK YOU!