Kubernetes ConfigMaps
Relevant source files
The following files were used as context for generating this wiki page:
ConfigMaps in the swimctl project serve as the primary mechanism for decoupling configuration artifacts from container images. They provide essential runtime settings for the swimming pool automation controller, specifically targeting the hardware interface via smarter-device-manager and the application logic residing in Node-RED.
By utilizing ConfigMaps, the system manages hardware device matching rules, JavaScript-based application settings, and project metadata without requiring rebuilds of the underlying Docker images. These configurations are injected into pods as either environment variables or mounted files, depending on the service requirements.
Sources: configMaps.yaml, values.yml
Device Management Configuration
The project utilizes a specific ConfigMap to manage hardware access on the Raspberry Pi host. The smarter-device-manager ConfigMap contains a YAML configuration that defines how I2C devices are identified and exposed to the Kubernetes cluster.
Smarter Device Manager Logic
The configuration uses regular expressions to match device nodes in the host's /dev directory. This allows the system to specifically isolate I2C buses used for pool sensors or actuators.
The diagram shows how the ConfigMap provides the matching logic for the device manager to expose host hardware as Kubernetes resources.
Sources: configMaps.yaml:1-8, smarter-device-manager.yaml:61-63
| ConfigMap Name | Data Key | Description |
|---|---|---|
smarter-device-manager | conf.yaml | Contains devicematch regex (e.g., ^i2c-[0-9]+$) and nummaxdevices. |
| Sources: configMaps.yaml:4-8 |
Node-RED Application Settings
Node-RED configuration is split across two distinct ConfigMaps to handle environment-specific overrides and project-level metadata.
System Settings (node-red-settings)
This ConfigMap stores a settings.js file. It implements a merge pattern where it requires the default settings from the Node-RED installation directory and merges them with custom settings, such as the activeProject.
- Logic: It utilizes
process.env.NODE_RED_ACTIVE_PROJECTto dynamically set the active project within the JavaScript object. - Source:
configMaps.yaml:14-25
Project Metadata (node-red-projects-settings)
This ConfigMap provides a JSON structure defined in .config.projects.json. It specifies the project name swimctl-flows and disables credential secrets for that specific project.
Sources: configMaps.yaml:31-41
ConfigMap Integration and Deployment
ConfigMaps are integrated into the deployment via values.yml and the standard Kubernetes manifest application process.
Mounting Mechanisms
The system employs two primary methods for utilizing ConfigMap data:
- Volume Mounts: Entire files are mounted into the container filesystem. For example,
.config.projects.jsonis mounted to/data/.config.projects.json. - Helm Chart References: The
settings.configMapNamevalue invalues.ymlpoints the Helm chart to thenode-red-settingsConfigMap.
This diagram illustrates how different ConfigMaps are consumed by the Node-RED pod through references and direct volume mounts.
Sources: values.yml:104-118
Deployment Strategy
When configurations are updated, the project uses a Recreate deployment strategy. This ensures that the old pods are terminated before new ones start, which is critical when dealing with exclusive hardware access (like I2C) defined in the values.yml resources section.
Sources: values.yml:45, values.yml:7-13
Summary of ConfigMap Usage
| Name | Namespace | Targeted Component | Primary Content |
|---|---|---|---|
smarter-device-manager | device-manager | Smarter Device Manager | Hardware regex matching for I2C |
node-red-settings | Default | Node-RED | settings.js (JS logic) |
node-red-projects-settings | Default | Node-RED | .config.projects.json (JSON metadata) |
| Sources: configMaps.yaml, 00-namespaces.yaml |
In summary, the swimctl project uses ConfigMaps to bridge the gap between static container images and the specific hardware/software environment of a Raspberry Pi-based pool controller, ensuring modularity and ease of update.