ConfigMap

1. Erstellen: kubectl create configmap my-config --from-literal=color=blue Oder per YAML:

   kind: ConfigMap
   data:
     app.properties: |
        color=blue
        mode=debug
   

2. Nutzen (als Env Var):

   env:
     - name: APP_COLOR
       valueFrom:
         configMapKeyRef:
           name: my-config
           key: color
   

3. Nutzen (als Datei / Volume): Du kannst die ganze ConfigMap als "virtuelles Laufwerk" mounten. Im Container taucht dann /etc/config/app.properties auf.

Praxisroutine

In der Praxis lernst du ConfigMap, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Hot Reloading (Live Updates)

Wenn du eine ConfigMap änderst (kubectl edit cm), passiert im Pod... erstmal nichts. Env Vars werden nur beim Start gelesen. Aber: Wenn du sie als Volume mountest, aktualisiert Kubernetes die Datei im Container automatisch (mit leichter Verzögerung, ca. 1-2 Minuten, Kubelet Sync Period). Moderne Apps nutzen "File Watcher" (z. B. Viper in Go oder Spring Cloud Config), um die Änderung zu bemerken und sich ohne Neustart neu zu konfigurieren. Für Legacy-Apps brauchst du einen "Reloader Sidecar" (z. B. Reloader), der den Pod neustartet, wenn sich der Config-Hash ändert.

2. Immutable ConfigMaps

Seit K8s 1.19 kannst du immutable: true setzen. Vorteil 1: Sicherheit (niemand pfuscht in der Prod-Config rum). Vorteil 2: Performance. Der Kubelet muss nicht mehr pollen ("Hat sich was geändert?"), was die Last auf dem API-Server massiv senkt.

3. Size Limits

Etcd ist keine Festplatte. ConfigMaps sind auf 1 MB limitiert. Du kannst keine riesigen XML-Dateien oder Binaries darin speichern. Dafür brauchst du echte Volumes (PVC) oder Init-Container, die Daten von S3 laden.

Symlink Magic bei Volume-Mounts

Wird eine ConfigMap als Datei gemountet (z. B. auf /etc/config/app.json), nutzt Kubernetes einen faszinierenden Trick, um Kubelet-CPU zu sparen. Kubernetes mountet nicht direkt die Datei. Stattdessen erstellt es Unterordner mit Timestamps (..data_2023_10_01_12_00) und pflegt Symlinks. Die gemountete Datei /etc/config/app.json ist lediglich ein Symlink auf den Ordner ..data, welcher wiederum ein Symlink auf den timestamp-Ordner ist. Aktualisierst du die ConfigMap im API-Server, tauscht das Kubelet asynchron den Symlink von ..data blitzschnell (atomic) auf den neuen Timestamp-Ordner aus. Prozesse, die die Datei offen per File-Descriptor halten, lesen weiter die alte Version, aber Prozesse, die neu zugreifen oder auf IN_CREATE Events (inotify) lauschen, erfassen den Tausch. Achtung: Dies funktioniert nicht bei subPath Mounts! Ein File, das per subPath gemountet wird, bricht die Symlink-Kette und wird nie aktualisiert (bis zum Pod-Neustart).

Generator-Patterns (Kustomize)

Das händische Erstellen von YAMLs für ConfigMaps ist lästig, besonders wegen des | (Block Scaler) für mehrzeilige Properties. Das Kubernetes-eigene Tool Kustomize (kubectl apply -k) behebt dies mit dem configMapGenerator. Du pflegst deine Konfiguration als stinknormale application.properties im Git. Kustomize liest beim Build diese Datei, packt sie in eine ConfigMap und – das ist der Trick – hängt einen Hash an den Namen an (z. B. my-config-v17ab12cd). In deinem Deployment ändert Kustomize dann auch das configMapKeyRef auf diesen gehashten Namen. Ändert sich die Property-Datei, entsteht beim nächsten Apply eine völlig neue ConfigMap und das Deployment ändert sein Template. Dies zwingt Kubernetes zu einem sauberen Rolling Restart der Pods mit der neuen Config, wodurch das "Reloader"-Problem elegant ohne Zusatzsoftware gelöst wird.

ConfigMap als Leader-Election Lock (Veraltet)

Früher (vor K8s 1.20) wurden ConfigMaps aus Mangel an Alternativen "missbraucht", um "Leases" (Verteilte Sperren) umzusetzen. Wenn 3 Pods eines Controllers versuchen, die Arbeit zu machen, dürfen sie sich nicht überschneiden. Der Controller erzeugte eine ConfigMap und nutzte die Etcd-Metadaten (resourceVersion) als atomares Lock. Wer zuerst schreibt, ist der "Leader", die anderen warten. Dies verursachte massiven Overhead im API Server. Heute nutzt man dafür eine spezialisierte Resource: das Lease Objekt (coordination.k8s.io).