> Kubernetes Configmap and Secrets in Detail:

Theory:

• while performing application deployments on k8s cluster, sometimes we need to change the application configuration file depending on environments like dev, QA, stage or Prod.
• changing this application configuration file means we need to change source code, commit the change, creating a new image and then go through the complete deployment process
• hence these configurations should be decoupled from image content in order to keep containerised application portable
• this is where kubernetes configmap comes handy. It allows us to handle configuration files much more efficiently.
• configmaps are useful for storing and sharing non-sensitive , unencrypted configuration information use secrets otherwise.
• configmap can be used to store fine-grained information like individual properties or entire configfiles
• configmap are not intended to act as a replacement for a properties file

• configmap can be accessed in following ways -
  1. As environment variables
  2. as volumes in the pod
• kubectl create configmap<mapname> --from-file=<file_to_read>

SECRETS:

• you don’t want sensitive information such as a database password or an API key kept around in clear text.

• secrets provide you with a mechanism to use such information in a safe and reliable way with the following properties:

  • secrets are namespaced objects, that is exist in the context of a namespace
  • you can access them via a volume or an environment variable from a container running in a pod.
  • the secret data on nodes is stored in tmpfs volumes (tmpfs is a file system which keeps all files in virtual memory. everything in tmpfs is temporary in the sense that no files will be created on your hard drive
  • a per-secret size limit of 1MB exist
  • the api server stores secrets plaintext in etcd

  Secrets can be created:

  1. from a text file
  2. from a yaml file