Applying Core Kubernetes Manifests
Relevant source files
The following files were used as context for generating this wiki page:
Applying core Kubernetes manifests in the swimctl project establishes the foundational infrastructure required for swimming pool automation. This process involves setting up namespaces, configuring hardware device access (specifically I2C), and deploying networking utilities like mDNS to ensure the controller is discoverable and functional within a local network environment.
The deployment relies on a combination of static manifests applied via kubectl and dynamic configuration managed through Helm. These manifests ensure that the Raspberry Pi hardware is correctly mapped into the Kubernetes cluster, allowing the automation logic to interact with physical sensors and controllers.
Sources: README.md:38-40, 00-namespaces.yaml
Infrastructure and Namespace Configuration
The project utilizes specific namespaces to isolate management components from application logic. The device-manager namespace is explicitly created to house hardware-related services, while other components may reside in kube-system or the default namespace.
The diagram above illustrates the distribution of core components across Kubernetes namespaces.
Sources: 00-namespaces.yaml:1-6, external-mdns.yaml:1-5, smarter-device-manager.yaml:1-6
Hardware Device Management
Hardware interaction is facilitated by the smarter-device-manager, which is deployed as a DaemonSet. This component is responsible for exposing I2C interfaces from the host Raspberry Pi to the Kubernetes pods.
Device Configuration
The manager uses a ConfigMap to define which host devices should be exposed. It specifically targets I2C buses using regex patterns.
| Component | Resource | Configuration |
|---|---|---|
| Device Match | ConfigMap | ^i2c-[0-9]+$ |
| Resource Name | values.yml | smarter-devices/i2c-1, i2c-20, i2c-21 |
| Max Devices | ConfigMap | 1 per match |
Sources: configMaps.yaml:1-9, values.yml:10-20
Smarter Device Manager Deployment
The DaemonSet runs with elevated privileges to access /dev and /sys on the host, ensuring that physical hardware is accessible to the containerized environment.
This diagram shows how the Smarter Device Manager mounts host directories to manage hardware devices.
Sources: smarter-device-manager.yaml:45-66
Network Discovery via External mDNS
To provide local network accessibility without static IP management, the project deploys external-mdns. This service watches Kubernetes Ingresses and Services to broadcast their presence on the local network.
RBAC and Permissions
The external-mdns service requires a specific ServiceAccount and ClusterRole to monitor network resources across the cluster.
| Role | API Groups | Resources | Verbs |
|---|---|---|---|
| external-mdns | "" (Core) | services | list, watch |
| external-mdns | networking.k8s.io | ingresses | list, watch |
Sources: external-mdns.yaml:7-25
Deployment Logic
The deployment uses hostNetwork: true to participate directly in the host's network stack, allowing mDNS packets to be broadcasted to the local subnet. It is configured to use both ingress and service as sources for discovery.
Sources: external-mdns.yaml:42-63
Application Configuration and Flows
The core automation logic (Node-RED) is configured through several ConfigMaps that manage settings and project metadata.
Project Settings and Initialization
The system is configured to use "projects" in Node-RED, specifically the swimctl-flows project. An init container is used to clone these flows from a GitHub repository during startup.
The sequence above describes the initialization flow where the automation logic is pulled from version control.
Sources: values.yml:108-144, configMaps.yaml:28-39
Environment and Secrets
Application pods consume configuration through environment variables, many of which are sourced from a Kubernetes secret named swimctl.
- NODE_RED_ENABLE_PROJECTS: Set to
trueto enable version control features. - GITHUB_TOKEN_FLOWS: Sourced from
swimctlsecret (gh_token). - MQTT_PASSWORD: Sourced from
swimctlsecret (mqtt_password).
Sources: values.yml:40-75, README.md:27-33
Summary of Core Manifests
Applying these manifests transforms a standard k3s installation on a Raspberry Pi into a specialized hardware controller. By combining namespace isolation, hardware device mapping via smarter-device-manager, and local network discovery via external-mdns, the project establishes a robust platform for the Node-RED automation flows.
Sources: README.md:38-40, 00-namespaces.yaml