CKAD Exam Preparation 3/4 - Configuration and Volumes
This part summarizes Configuration and Volumes as key primitives of the CKAD Exam Curriculum. To learn more about the CKAD Exam please read this overview.
About this Series
During this blog series I summarize the main “study hooks” in order to be successful with your exam, as I was. The series is composed by the following articles:
- Part 1. Cross-Cutting Aspects
- Part 2. Pods and Jobs.
- Part 3. Configuration and Volumes.
- Part 4. Deployments, Services and Networking.
All the examples have been developed using minikube on macOS Catalina with VirtualBox.
🖇️ Configuration Primitives
For running a Pod with a certain set of environment variables (env var) the easiest way is with
--env parameter is needed per env var set.
An environment can be also be populated with variables coming from Config Maps or Secrets.
The simplest way to create a Config Map is with the
--literal command line option:
--literal parameter is needed per name/value pair.
A Config Map can also be created from a properties or environment var file:
A Config Map can also be created to include all the contents of a file:
The above command will create a Config Map with just one name/value pair (named
myconfig.json) which value will be the content of the
📌 The difference between
📌 Use Secrets for sensitive configurations, TLS, private keys, certificates, etc.
📌 Secrets are stored encrypted but finally exposed to trusted containers in plain mode.
The simplest way to create a generic Secret is with the
--literal command line option:
--literal parameter is needed per Secret’s name/value pair.
Assuming your K8s implementation encrypts Secrets using base64 (please do not do that in production) you can obtain a Secret’s value in plain mode as follows:
📌 You can create Secrets from env files and with file or folder content.
📌 Service Account tokens are also stored as Secrets
Pod Configuration through env vars
How to use a Config Map with direct mapping to env variables:
📌 An env var will be created for each ConfigMap’s name/value pair.
📌 The same can be done with Secrets using
secretRef instead of
optional: false to ensure you are using an already
existent/right Config Map or Secret.
ConfigMap’s or Secret’s name/value pairs can also be mapped to custom env vars. In the example below the
SECRET567 is mapped to the name/value pair
pwd of the Secret
📌 The same can be done with Config Map using
Pod configuration through Volumes
A Volume can be easily declared to reference a Config Map or a Secret. Then, such volume can be mounted to a folder by containers. Such folder will contain a file per name/value pair. The name of the file will correspond to the key name and the content of the file will be the key value.
📌 The same can be done with Secret using
It is also possible to map specific name/value pairs of a Secret or Config Map to a path. See below
emptyDir allows to create a transient Volume for a Pod.
📌 Transient Volumes share a Pod’s lifetime.
How to create a Persistent Volume (PV)
📌 PVs are cluster resources and have a lifecycle independent of any individual Pod that uses the PV.
📌 The reclaim policy for a PV tells the cluster what to do with the Volume after it has been released of its claim:
Persistent Volume Claims
A Persistent Volume Claim (PVC) is a request for storage by a user. PVCs consume PV resources. Claims can request specific size and access modes.
We can observe that our initial PV
mypv-tutorial it is now bound to our PVC
📌 The binding between a PV and a PVC happens provided there is a match with capacity, storage class and selector.
📌 There are storage classes marked as dynamically provisioned. In those cases PVs can be created dynamically to meet the demands of a PVC.