Day 35: Mastering ConfigMaps and Secrets in Kubernetes

Welcome back to our journey of mastering Kubernetes! In the previous article, we delved into the concepts of Namespaces and Services, crucial components that enable better organization and communication within Kubernetes clusters. Today, we are going to explore another essential aspect of managing applications in Kubernetes — ConfigMaps and Secrets.

What are Secrets?

According to kubernetes.io, a Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key.

Secrets are used to store sensitive information such as passwords, API keys, and TLS certificates. Secrets provide a secure way to store and manage this confidential data within a cluster. They are similar to ConfigMaps but are specifically designed to handle sensitive information.

There are three main ways for a Pod to use a Secret:

• As files in a volume mounted on one or more of its containers.
• As container environment variable.
• By the kubelet when pulling images for the Pod.

What are ConfigMaps in k8s

According to kubernetes.io, a ConfigMap is an API object used to store non-confidential data in key-value pairs.

ConfigMaps are used to store configuration data that can be consumed by pods or other Kubernetes resources.

ConfigMaps are typically used to store non-sensitive configuration data such as environment variables, command-line arguments, or configuration files. This data can be accessed by pods as environment variables or mounted as files.

A ConfigMap is not designed to hold large chunks of data. The data stored in a ConfigMap cannot exceed 1 MiB.

There are four different ways that you can use a ConfigMap to configure a container inside a Pod:

1. Inside a container command and args
2. Environment variables for a container
3. Add a file in read-only volume, for the application to read
4. Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap.

Difference between ConfigMaps and Secrets in Kubernetes

Today’s task

Task 1) Create a ConfigMap for your Deployment

Let’s create a mysql-config.yml file.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
  labels:
    app: django-todo-app
  namespace: deploy1
data:
  MYSQL_DB: "database_todo"

This YAML file creates a ConfigMap object that stores a single configuration setting, MYSQL_DBwith the value "database_todo". This ConfigMap can be used by a pod in the deploy1 namespace to access this configuration setting as an environment variable or a file in a mounted volume.

kubectl apply -f configmap.yaml

To verify the ConfigMap creation, use the following command:

kubectl get configmap -n <namespace>

Here , The ConfigMap is created successfully.

Task 2) Create a Secret for your Deployment

Create a mysql-secret.yml file

apiVersion: v1
kind: Secret
metadata:   
  name: my-secret
  namespace: deploy1
type: Opaque
data:
  password: YWRtaW5AMTIz

What’s the type: Opaque mentioned here in the above code block?

In Kubernetes, type: Opaque is the default type for a Secret object.It means that the contents of the Secret are unstructured and can contain arbitrary key-value pairs.

Opaque Secrets are used to store arbitrary user-defined data, such as passwords, OAuth tokens, and ssh keys.

Other types of Secrets include: Service accounts token secrets (store a token that references a service account.), Docker registry secrets (store credentials for accessing a Docker registry), and TLS secrets (store TLS certificates and keys).

Let’s apply the secret to deployment.

kubectl apply -f mysql-secret.yml -n <namespace>

We can verify the creation of secrets using:

kubectl get secrets -n <namespace>

Update the sqldeployment.yaml with the secrets and config map.

apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: mysql-configuration
   labels:
     app: mysql
   namespace: deploy1 
 spec:
   replicas: 2
   selector:
     matchLabels:
       app: mysql
   template:
     metadata:
       labels:
         app: mysql
     spec:
       containers:
       - name: mysql-container
         image: mysql:8
         ports:
         - containerPort: 3306
         env:
         - name: MYSQL_ROOT_PASSWORD
           valueFrom:
             secretKeyRef:
               name: my-secret
               key: password
         - name: MYSQL_DATABASE
           valueFrom:
             configMapKeyRef:
               name: my-configmap
               key: MYSQL_DB

Let’s apply this to the cluster.

kubectl apply -f sqldeployment.yml -n deploy1

Let’s verify if the pods are running.

kubectl get pods -n <namespace>

Here, the pods are created.

But we need to use the MySQL service. For that, we will have to expose the k8s cluster to a port. I will create a sqlservice.yaml for that.

 apiVersion: v1
 kind: Service
 metadata:
   name: mysql-service-configuration
 spec:
   ports:
   - name: mysql
     port: 3306
   clusterIP: None
   selector:
     app: mysql

And apply to the cluster.

kubectl apply -f sqlservice.yml -n <namespace>

Verify if the pods are running.