Namespace Configuration
Relevant source files
The following files were used as context for generating this wiki page:
Namespace configuration in the swimctl project provides a structured logical separation of cluster resources, specifically focusing on hardware device management, system networking, and application logic. By utilizing Kubernetes namespaces, the project isolates the "Smarter Device Manager" infrastructure from core system services and the primary swimming pool automation controller.
This configuration ensures that specialized permissions, such as access to host I2C devices or cluster-wide service discovery via mDNS, are scoped appropriately to specific service accounts and deployments.
Core Namespaces
The project explicitly defines and utilizes several namespaces to organize its components.
| Namespace | Purpose | Primary Components |
|---|---|---|
device-manager | Hardware abstraction and device plugin management. | Smarter Device Manager DaemonSet, ConfigMaps. |
kube-system | Core cluster services and external networking integration. | external-mdns Deployment, RBAC roles. |
default | Main application logic (inferred from Helm/Kubectl defaults). | Node-RED automation, GitHub sync init containers. |
Sources: 00-namespaces.yaml:4-7, smarter-device-manager.yaml:6, external-mdns.yaml:6
Device Management Isolation
The device-manager namespace is dedicated to the Smarter Device Manager, which allows the Kubernetes cluster to interface with hardware on the Raspberry Pi. This namespace contains the smarter-device-manager ConfigMap that defines regex patterns for matching local devices, such as i2c buses.
The diagram above illustrates how the device-manager namespace encapsulates the configuration and management of host hardware devices.
Sources: configMaps.yaml:8-10, smarter-device-manager.yaml:70-73
Networking and System Namespaces
The kube-system namespace is leveraged for the external-mdns service, which facilitates service discovery across the local network using Multicast DNS.
External mDNS Configuration
The external-mdns component is deployed into kube-system to allow it to monitor resources across all namespaces. It requires specific RBAC permissions (ClusterRole and ClusterRoleBinding) to watch Services and Ingresses cluster-wide to announce them over mDNS.
Sources: external-mdns.yaml:12-46, values.yml:85-87
Resource Scoping and Security
The project uses values.yml and configMaps.yaml to define how application-level resources (likely in the default namespace) interact with the specialized namespaces.
- Security Contexts: Pods are configured with specific
runAsUser(1000) andrunAsGroup(1000) settings, with supplemental group IDs (994) to allow access to I2C groups mapped via the device manager. - Init Containers: Used to clone automation flows from GitHub into the data volume before the main application starts.
Sources: values.yml:19-27, values.yml:110-120
Resource Request Logic
The application requests specific hardware devices exposed by the device-manager namespace using the smarter-devices/ prefix.
| Resource Name | Request/Limit Value | Derived From |
|---|---|---|
smarter-devices/i2c-1 | 1 | Smarter Device Manager Plugin |
smarter-devices/i2c-20 | 1 | Smarter Device Manager Plugin |
smarter-devices/i2c-21 | 1 | Smarter Device Manager Plugin |
Sources: values.yml:9-16, configMaps.yaml:9
Deployment Summary
The swimctl architecture relies on the orchestration of these namespaces to function correctly on a Raspberry Pi host.
Namespace configuration ensures that the high-privilege smarter-device-manager and external-mdns components are separated from the application-level logic, providing a robust foundation for swimming pool automation.