Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Operator stops reconciling permanently after its watch connections drop while idle

Aperta
  • Qualcosa non va?
#936 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
kubernetes, rust
Ambito
devops, infrastructure

Direzione di ricerca

Inizia dal comportamento di watch e backoff del controller in kube-runtime/src/controller/mod.rs intorno alla riga indicata, quindi esamina come questo operatore configura Controller e watcher::Config. Riproduci la disconnessione di un watch inattivo e confronta gli approcci constant-backoff e timeout ridotto descritti nell’issue. Il lavoro è completato quando gli operatori interessati si riconnettono dopo la disconnessione di watch inattivi e continuano il riconciling senza riavviare un pod.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type/bug
Affected Stackable version

26.7

Affected Trino version

481

Current and expected behavior

The trino, hive and airflow operators flip from recoverable watch-stream errors to a permanent failed to start watching object: client error (Connect) loop and never reconcile again until the pod is restarted. While wedged the operator looks healthy to Kubernetes: the process is running, its conversion webhook still answers.

Expected

A controller whose watch connection is dropped re-establishes it and continues reconciling, as it does for the first several drops.

Actual

ERROR kube_client::client::builder: failed with error client error (Connect)
WARN stackable_operator::logging::controller: Queued reconcile resulted in an error
  controller.name="trinocluster.trino.stackable.tech"
  error=failed to start watching object: ServiceError: client error (Connect)
  error.sources=[ServiceError: client error (Connect), client error (Connect), deadline has elapsed]

The problems seems to be upstream in kube-rs: https://github.com/kube-rs/kube/blob/main/kube-runtime/src/controller/mod.rs#L1704
Possible explanation for this issue: All watch triggers get merged into a single stream that then gets joint backoff - so if an operator watches e.g. 7 resources, the backoff fires instantly 6 times, which quickly leads to high sleep durations that ultimately go beyond the timeout.

While kube-rs has a long timeout configured (>200 secs) on the observed cluster some kind of proxy for the apiserver seems to terminate idle watches after 60 seconds, which is reliably triggered for the mentioned operators.

Possibly related: https://github.com/kube-rs/kube/issues/1915

As mentioned in the beginning, this potentially affects all our operators

Possible solution

Possible Workarounds:

Smaller, constant backoff
    use kube::runtime::utils::Backoff;

    struct ConstantBackoff(Duration);
    impl Iterator for ConstantBackoff {
        type Item = Duration;
        fn next(&mut self) -> Option<Duration> { Some(self.0) }
    }
    impl Backoff for ConstantBackoff {
        fn reset(&mut self) {}
    }

    Controller::new(api, watcher::Config::default())
        .trigger_backoff(ConstantBackoff(Duration::from_secs(2)))
Reduce timeout on watcher side:

Maybe as an optional parameter or something.

const WATCH_TIMEOUT_SECS: u32 = 40;

fn watch_config() -> watcher::Config {
    watcher::Config::default().timeout(WATCH_TIMEOUT_SECS)
}
Additional context

No response

Environment

No response

Would you like to work on fixing this bug?

None

Lingua principale
Rust
Stelle
63
Fork
13
Merge medio
1g 20h
PR unite (30g)
12

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stackabletech/trino-operator

Tutte le issue di stackabletech/trino-operator

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.