Migrated from nfvelten/arbitus#132
Summary
Arbitus currently reloads config via SIGUSR1 or a 30-second file polling interval. In Kubernetes, config is typically stored in a ConfigMap. The current approach requires either manual SIGUSR1 signals or waiting up to 30s for changes to take effect.
A kube-rs-based ConfigMap watcher would detect changes instantly and push them through the existing tokio::sync::watch live-config channel.
Implementation (feature-gated)
[features]
kubernetes = ["dep:kube", "dep:k8s-openapi"]
[dependencies]
kube = { version = "0.98", features = ["client", "runtime"], optional = true }
k8s-openapi = { version = "0.22", features = ["latest"], optional = true }
// Watch ConfigMap and reload config on change
async fn watch_configmap(client: Client, namespace: &str, name: &str, tx: watch::Sender<Config>) {
let cms: Api<ConfigMap> = Api::namespaced(client, namespace);
let mut stream = watcher(cms, watcher::Config::default()).boxed();
while let Some(Ok(event)) = stream.next().await {
if let watcher::Event::Applied(cm) = event {
if let Some(yaml) = cm.data.and_then(|d| d.get("gateway.yml").cloned()) {
if let Ok(config) = serde_yaml::from_str(&yaml) {
let _ = tx.send(config);
}
}
}
}
}
Feature-gated so non-K8s users don't pull in K8s dependencies.
References
- FEATURE_ADOPTION_FEASIBILITY.md §3
Migrated from nfvelten/arbitus#132
Summary
Arbitus currently reloads config via SIGUSR1 or a 30-second file polling interval. In Kubernetes, config is typically stored in a ConfigMap. The current approach requires either manual SIGUSR1 signals or waiting up to 30s for changes to take effect.
A
kube-rs-based ConfigMap watcher would detect changes instantly and push them through the existingtokio::sync::watchlive-config channel.Implementation (feature-gated)
Feature-gated so non-K8s users don't pull in K8s dependencies.
References