The goal of this tutorial is to provide best practices for Kubernetes configuration management. Kubernetes has become one of the most widely used platforms for managing containerized applications. With the right configuration management practices, you can effectively and securely manage your applications on Kubernetes.
By the end of this tutorial, you will be able to:
This tutorial assumes basic knowledge of Kubernetes and its core components. Familiarity with YAML and command line interface would be beneficial.
Managing configurations in Kubernetes involves creating and managing resources such as ConfigMaps and Secrets.
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. They can be used to store fine-grained information like individual properties or coarse-grained information like entire configuration files or JSON blobs.
Kubernetes Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Using Secrets, you can manage sensitive information in a centralized manner without exposing it in your stack configuration.
Use namespaces: Namespaces allow you to segregate resources created by different teams or projects. This avoids conflicts in resource names and provides scope for resource management policies.
Use labels and annotations: Labels are key/value pairs that can be attached to Kubernetes objects and can be used for filtering and grouping. Annotations are also key/value pairs that can be used to attach arbitrary non-identifying metadata.
Limit access to Secrets: Use Role-Based Access Control (RBAC) to limit who can get and set certain Secrets.
Don't hard-code configurations: Avoid hard-coding configurations in the application. Instead, use ConfigMaps and Secrets.
Update configurations without downtime: Kubernetes allows you to update configurations without restarting the pods or containers.
The following code creates a ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: game-demo
data:
# property-like keys; each key maps to a simple value
player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
In this code:
apiVersion
specifies the Kubernetes API version.kind
specifies the type of resource to create. In this case, a ConfigMap.metadata
specifies data that helps uniquely identify the ConfigMap, like a name
.data
is the actual data contained in the ConfigMap.The following code creates a Secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: dmFsdWU=
In this code:
apiVersion
specifies the Kubernetes API version.kind
specifies the type of resource to create. In this case, a Secret.metadata
specifies data that helps uniquely identify the Secret, like a name
.type
specifies the type of Secret. Most Secrets are Opaque
.data
is the actual data contained in the Secret. It's a map of strings converted to base64.In this tutorial, we have learned about Kubernetes configuration management, including ConfigMaps and Secrets, as well as best practices for managing configurations.
To learn more about Kubernetes, consider exploring these additional resources:
Create a ConfigMap: Create a ConfigMap named app-config
that stores database_url
and api_key
.
Create a Secret: Create a Secret named app-secret
that stores database_password
.
Access ConfigMap and Secret from a Pod: Create a Pod that uses the ConfigMap and Secret created in the previous exercises.
Solutions
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
database_url: "jdbc:mysql://localhost:3306/mydb"
api_key: "123456"
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
data:
database_password: cGFzc3dvcmQ=
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: myimage
env:
- name: DATABASE_URL
valueFrom:
configMapKeyRef:
name: app-config
key: database_url
- name: API_KEY
valueFrom:
configMapKeyRef:
name: app-config
key: api_key
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: app-secret
key: database_password
In this Pod definition, we are setting environment variables from values in the ConfigMap and Secret. To further practice, try accessing ConfigMap and Secret values from a volume.