ConfigMaps¶
Der ConfigMaps-Helper erstellt Kubernetes ConfigMaps für Anwendungskonfiguration.
Übersicht¶
ConfigMaps speichern nicht-sensible Konfigurationsdaten als Key-Value-Paare oder als Dateien. Sie sind ideal für:
- Konfigurationsdateien (YAML, JSON, INI, etc.)
- Umgebungsvariablen
- Kommandozeilen-Argumente
- Feature-Flags
Basis-Konfiguration¶
configs:
- name: app-config
namespace: production
values:
config.yaml: |
server:
host: 0.0.0.0
port: 8080
Mehrere Keys¶
Eine ConfigMap kann mehrere Keys (Dateien) enthalten:
configs:
- name: app-config
namespace: production
values:
config.yaml: |
server:
host: 0.0.0.0
port: 8080
database:
host: postgres
port: 5432
logging.yaml: |
level: info
format: json
features.json: |
{
"newUI": true,
"darkMode": false
}
Key-Value Paare¶
Für einfache Key-Value-Konfigurationen:
configs:
- name: app-env
namespace: production
values:
APP_ENV: production
LOG_LEVEL: info
FEATURE_FLAG_X: "true"
MAX_CONNECTIONS: "100"
dontOverrideOnUpdate¶
Mit dontOverrideOnUpdate: true bleiben Änderungen bei helm upgrade erhalten:
configs:
# Standard: Wird bei jedem Upgrade überschrieben
- name: app-config
namespace: production
dontOverrideOnUpdate: false
values:
config.yaml: |
server:
port: 8080
# Benutzer-Änderungen bleiben erhalten
- name: user-settings
namespace: production
dontOverrideOnUpdate: true
values:
settings.yaml: |
theme: light
language: de
Wann dontOverrideOnUpdate verwenden?
false(Standard): Für Konfigurationen, die mit dem Code versioniert sindtrue: Für Konfigurationen, die Benutzer zur Laufzeit ändern können
Mehrere ConfigMaps¶
configs:
# Haupt-Konfiguration
- name: api-config
namespace: production
values:
config.yaml: |
server:
port: 8080
# Nginx Konfiguration
- name: nginx-config
namespace: production
values:
nginx.conf: |
server {
listen 80;
location / {
proxy_pass http://localhost:8080;
}
}
# Prometheus Konfiguration
- name: prometheus-config
namespace: monitoring
values:
prometheus.yml: |
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'api'
static_configs:
- targets: ['api:8080']
Verwendung in Containern¶
Als Volume mounten¶
configs:
- name: app-config
namespace: production
values:
config.yaml: |
server:
port: 8080
chart:
container:
image: myapp:latest
volumeMounts:
- name: config
mountPath: /etc/app
deploymentVolume:
volumes:
- name: config
configMap:
name: app-config
Einzelne Datei mounten¶
chart:
container:
volumeMounts:
- name: config
mountPath: /etc/app/config.yaml
subPath: config.yaml
deploymentVolume:
volumes:
- name: config
configMap:
name: app-config
Als Umgebungsvariablen¶
configs:
- name: app-env
namespace: production
values:
LOG_LEVEL: info
MAX_CONNECTIONS: "100"
chart:
container:
envFrom:
- configMapRef:
name: app-env
Vollständiges Beispiel¶
# Chart.yaml
apiVersion: v2
name: my-app
version: 1.0.0
dependencies:
- name: ohmyhelm
alias: app
repository: https://gitlab.com/ayedocloudsolutions/ohmyhelm
version: 1.13.0
# values.yaml
app:
# ConfigMaps
configs:
- name: api-config
namespace: production
values:
config.yaml: |
server:
host: 0.0.0.0
port: 8080
timeout: 30s
database:
host: {{ .Values.dbHost }}
port: 5432
name: myapp
cache:
host: redis
port: 6379
ttl: 3600
- name: nginx-config
namespace: production
values:
default.conf: |
upstream backend {
server localhost:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
# Deployment
chart:
enabled: true
fullnameOverride: "my-api"
container:
image: myapp/api:latest
ports:
- name: http
containerPort: 8080
volumeMounts:
- name: config
mountPath: /etc/app
sidecar:
enabled: true
image: nginx:alpine
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx/conf.d
deploymentVolume:
volumes:
- name: config
configMap:
name: api-config
- name: nginx-config
configMap:
name: nginx-config
Helm Templating in ConfigMaps¶
Sie können Helm-Templates in ConfigMaps verwenden:
configs:
- name: app-config
namespace: production
values:
config.yaml: |
environment: {{ .Values.environment }}
replicas: {{ .Values.replicaCount }}
features:
{{- range .Values.features }}
- {{ . }}
{{- end }}
Best Practices¶
- Trennung von Konfiguration und Code - ConfigMaps ermöglichen Konfigurationsänderungen ohne Rebuild
- Versionierung - Fügen Sie Versionierung in ConfigMap-Namen für Rollbacks hinzu
- Größenlimit beachten - ConfigMaps sind auf 1 MiB begrenzt
- Keine Secrets - Verwenden Sie ConfigMaps nur für nicht-sensible Daten
- Immutable ConfigMaps - Für Production können Sie
immutable: truesetzen
Troubleshooting¶
ConfigMap prüfen¶
# ConfigMap anzeigen
kubectl get configmap app-config -n production -o yaml
# Einzelnen Key ausgeben
kubectl get configmap app-config -n production -o jsonpath='{.data.config\.yaml}'
# Im Pod prüfen
kubectl exec -it <pod> -n production -- cat /etc/app/config.yaml
Änderungen nicht übernommen¶
Pods laden ConfigMaps nur beim Start. Nach Änderungen: