DevContainer User
67 lines
2.7 KiB
Markdown
67 lines
2.7 KiB
Markdown
# ADR 003: Static Pod Discovery with Label Selector Fallback
|
|
|
|
**Status**: Accepted
|
|
|
|
**Date**: 2026-03-05
|
|
|
|
**Deciders**: Development Team
|
|
|
|
---
|
|
|
|
## Context
|
|
|
|
kube-vip can be deployed in two ways:
|
|
|
|
1. **DaemonSet deployment**: Pods are managed by a DaemonSet and have standard labels (e.g., `app: kube-vip`) that can be used for label-selector based discovery.
|
|
2. **Static pod deployment**: Pod manifests are placed in `/etc/kubernetes/manifests/` on each node. Static pods do not have the same labels as DaemonSet-managed pods and follow the naming convention `kube-vip-<node-name>`.
|
|
|
|
The plugin needs to discover kube-vip pods regardless of the deployment method. The pod fetch uses a two-level fallback strategy: first try label-selector based discovery, then fall back to listing all pods in `kube-system` and filtering by name prefix.
|
|
|
|
---
|
|
|
|
## Decision
|
|
|
|
Implement a two-level pod discovery fallback:
|
|
|
|
1. **Primary**: Fetch pods using label selector (matches DaemonSet-deployed kube-vip).
|
|
2. **Fallback**: If the label-selector fetch fails or returns empty, list all pods in the `kube-system` namespace and filter by `name.startsWith('kube-vip')` (matches static pod naming convention).
|
|
|
|
This covers both deployment methods without requiring user configuration.
|
|
|
|
---
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
|
|
- ✅ Works with both DaemonSet and static pod deployments out of the box
|
|
- ✅ No user configuration needed — deployment method is auto-detected
|
|
- ✅ Automatic fallback is transparent to the user and other plugin components
|
|
|
|
### Negative
|
|
|
|
- ⚠️ Fallback fetches all `kube-system` pods, which is a broader query than necessary
|
|
- ⚠️ Name-prefix matching (`kube-vip`) is convention-dependent and could produce false positives if other pods share the prefix
|
|
|
|
These negatives are mitigated by the fact that `kube-system` typically has a manageable number of pods, and the name prefix `kube-vip` is the standard convention used by the kube-vip project.
|
|
|
|
---
|
|
|
|
## Alternatives Considered
|
|
|
|
1. **Label selector only** — Rejected. Would miss static pod deployments entirely, leaving users who deploy kube-vip as static pods without visibility.
|
|
|
|
2. **Name prefix only** — Rejected. Less efficient than label selector for DaemonSet deployments, as it requires listing all pods in the namespace rather than using server-side filtering.
|
|
|
|
3. **User-configured discovery method** — Rejected. Adds unnecessary configuration burden for something that can be reliably auto-detected through the fallback strategy.
|
|
|
|
4. **Node filesystem check for static pod manifests** — Rejected. Requires node-level filesystem access, which is not available to Headlamp plugins running in the browser.
|
|
|
|
---
|
|
|
|
## Changelog
|
|
|
|
| Date | Change |
|
|
| ---- | ------ |
|
|
| 2026-03-05 | Initial decision recorded |
|