System Updates and Helm Upgrades
Relevant source files
The following files were used as context for generating this wiki page:
The swimctl project utilizes a Kubernetes-based architecture (specifically k3s) to manage swimming pool automation. System updates and upgrades are handled through a combination of manual configuration of the Raspberry Pi host environment, the application of static Kubernetes manifests, and Helm-based lifecycle management for application components like Node-RED.
Sources: README.md:1-4, values.yml:1-5
System Infrastructure and Host Preparation
Before updates or upgrades can occur within the Kubernetes cluster, the underlying Raspberry Pi host must be correctly configured. This involves preparing the kernel features (cgroups) and enabling hardware interfaces like I2C, which are critical for the smarter-device-manager to expose hardware to the pods.
Sources: README.md:10-25, smarter-device-manager.yaml:1-10
Host Configuration Requirements
| Requirement | Command / Configuration | Purpose |
|---|---|---|
| cgroups | cgroup_memory=1 cgroup_enable=memory | Enables memory management required by k3s |
| I2C | sudo raspi-config nonint do_i2c 0 | Enables I2C interface for hardware sensors |
| Namespace | device-manager | Dedicated namespace for hardware management |
Sources: README.md:13-25, 00-namespaces.yaml:4-7
Deployment and Upgrade Workflows
The system follows a tiered update approach. Core infrastructure is managed via kubectl apply, while the primary application logic is managed via Helm.
Helm Upgrade Process
The swimctl system uses the node-red chart from the Schwarz IT OCI registry. Upgrades are performed by pointing the Helm client to the values.yml file, which contains environment-specific configurations and hardware resource requests.
helm --kube-context "${hostname}" upgrade node-red \
oci://ghcr.io/schwarzit/charts/node-red \
--values values.yml
Sources: README.md:61-62, values.yml:1-10
Deployment Strategy
The main application deployment uses a Recreate strategy. This ensures that when an upgrade is triggered, old pods are terminated before new ones are started, preventing resource conflicts with the I2C hardware devices which are limited to a single consumer.
Sources: values.yml:25, external-mdns.yaml:48-50
Infrastructure Components Architecture
The following diagram illustrates the relationship between the host, the device manager, and the Node-RED application during the update and execution lifecycle.
The diagram shows how hardware interfaces enabled on the host are passed through to the Node-RED application via the device manager.
Sources: smarter-device-manager.yaml:10-60, values.yml:7-15, configMaps.yaml:6-10
Configuration Management and Hooks
System updates are not limited to container images; they also encompass flow updates and configuration changes stored in ConfigMaps.
Dynamic Flow Updates
The system implements a Git-based flow management system. During the initialization of the Node-RED pod, an initContainer clones a specific version of the flows. A post-commit hook is automatically configured to trigger a GitHub Action when changes are made within the environment.
Sources: values.yml:85-115
ConfigMap Definitions
| ConfigMap Name | Description | Key Data |
|---|---|---|
smarter-device-manager | Regulates I2C device access | devicematch: ^i2c-[0-9]+$ |
node-red-settings | Custom JavaScript settings for Node-RED | settings.js |
node-red-projects-settings | Project-specific metadata | .config.projects.json |
Sources: configMaps.yaml:4-46
Network and Service Discovery Updates
Updates to the networking layer are handled by the external-mdns service, which facilitates local service discovery (mDNS).
The external-mdns deployment watches for changes in Ingress and Service resources and broadcasts these to the local network using the host network interface.
Sources: external-mdns.yaml:15-25, external-mdns.yaml:66-70
Conclusion
The swimctl update mechanism is a multi-layered process that ensures host-level hardware availability while providing a standard Helm-based interface for application lifecycle management. By utilizing the Recreate strategy and specialized device managers, the system maintains reliable access to physical sensors across software iterations.