[helm] Publish not-ready addresses on the tablet headless Service so restarting servers stay resolvable
I maintainer di solito rispondono entro 2 giorni
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 76/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- helm, java, kubernetes
- Ambito
- devops, infrastructure
Direzione di ricerca
Leggi templates/svc-tablet.yaml e individua come il chart espone le impostazioni dei servizi; esamina il template del headless Service del coordinator e i values per trovare la configurazione corrispondente. Aggiungi le impostazioni richieste, attive per impostazione predefinita, per entrambi i servizi, poi renderizza il chart per confermare che i due headless Services pubblicano gli indirizzi dei pod non pronti, mentre i Metrics Services restano invariati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Search before asking
- I searched in the issues and found nothing similar.
Description
Search before asking
- I searched in the issues and found nothing similar.
Motivation
Clients reach tablet servers through the CLIENT listener the chart advertises: <pod>.tablet-server-hs.<namespace>.svc.cluster.local. tablet-server-hs is a headless Service without publishNotReadyAddresses, so Kubernetes publishes a pod's DNS record only while the pod is Ready.
The chart's readiness probe is a cluster-health gate: a restarted tablet server stays NotReady until the whole cluster is GREEN (all replicas in sync, all leaders active), up to healthCheckTimeoutSeconds (1200 s by default). During that window the server is running, is registered in ZooKeeper, takes part in replication and can be named as a leader in metadata, but its hostname doesn't resolve.
What we saw on 1.0.0 during a rolling restart (3 tablet servers, ~11 minutes NotReady per server):
- The lake tiering job failed over twice with
java.net.UnknownHostException: tablet-server-2.tablet-server-hs.<ns>.svc.cluster.local. - Writers that still routed requests to the restarting server failed with
UnknownHostExceptionfor the whole window, and their metadata refreshes against that server failed the same way.
Setting publishNotReadyAddresses: true on the Service by hand made the restarting server resolvable immediately and removed the UnknownHostException errors. This is the usual pattern for StatefulSet peer-discovery Services, which need per-pod DNS regardless of readiness. The deprecated service.alpha.kubernetes.io/tolerate-unready-endpoints annotation is not an alternative: it's ignored by the EndpointSlice controller (tested on Kubernetes 1.35).
It also becomes a requirement if the INTERNAL listener is advertised by DNS name instead of pod IP (#2076): otherwise peers can't reach a restarting server during the gate either.
Readiness still controls rollouts: the StatefulSet controller and PodDisruptionBudgets use pod readiness, not the Service's endpoints, so the gate keeps working.
Solution
- Add
publishNotReadyAddresses: truetotemplates/svc-tablet.yaml, configurable throughtablet.service.publishNotReadyAddresses(defaulttrue). - Do the same for
coordinator-server-hs(coordinator.service.publishNotReadyAddresses), which is the clients' bootstrap address. - Leave the metrics Services unchanged.
Willingness to contribute
- I'm willing to submit a PR!
- Lingua principale
- Java
- Stelle
- 2.2k
- Fork
- 658
- Merge medio
- 3g 1h
- PR unite (30g)
- 120
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/fluss
-
[lake/iceberg] Reserved write-mode properties can be set and reset through their `iceberg.` keyForse già presa @aphenix-r7 l’ha presa 14 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
apache/fluss#4658 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
[common] Decimal#hashCode is inconsistent with Decimal#equalsForse già presa @firasbouzazi l’ha presa 26 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
apache/fluss#4538 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
[security] PlainSaslServerProvider conflicts with Hadoop SASL provider causing authentication failureForse già presa @xinzhang-hello l’ha presa 32 giorni fa. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 2 giorni
-
[server] KV snapshot scheduling stops permanently after a transient snapshot-init failureForse già presa @zhang-arvin l’ha presa 32 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
apache/fluss#4489 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
[docs] Document advertised-resource and ACL principal ignore-case optionsForse già presa @EchoLee5 l’ha presa 44 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di apache/fluss
Issue simili
-
pending:code-area pending:issue-category to-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
area:core bug priority:p2
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
aomarai/minecraft-mcp#247 ·
I maintainer di solito rispondono entro 1 giorno
-
help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
antonyrag/ragleap-core#1062 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
projectnessie/nessie#13256 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
Vakore/ZappierGames#232 ·