Graceful scaling of nodes with daemonset.
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- kubernetes
- Ambito
- devops, infrastructure
Direzione di ricerca
Inizia esaminando i NodePool startupTaints e le DaemonSet tolerations mostrati nell'issue, quindi analizza come sys-box-runtime passi da Initialization a running durante lo scaling dei nodi. Riproduci il comportamento di node-storm con la configurazione Kubernetes fornita; il lavoro è completato quando è disponibile un approccio documentato o convalidato che consenta ai nodi di attendere il DaemonSet senza attivare uno scaling eccessivo.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What is the recommended method to handle scaling of nodes to prevent node storms when an app has a dependency of node state label sys-box-runtime=running . The initialization time of of sys-box causes conflicts with autos scaling groups. Current configuration:
Karpeneter scaling
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: foo
spec:
template:
metadata:
labels:
karpenter.sh/capacity-type: on-demand
spec:
startupTaints:
- key: karpenter.sh/wait
value: "true"
effect: NoSchedule
limits:
cpu: 1000
Testing this configuration but sys-box-runtime=Initialization is slow and causes node storms as it waits for sys-box-runtime=running
apiVersion: apps/v1
kind: DaemonSet
metadata:
...
spec:
...
spec:
tolerations:
- key: karpenter.sh/wait
operator: Exists
effect: NoSchedule
...
I would prefer not to solve this by throwing higher compute specs at it and can wait for the daemon set to be in a running state when nodes scale. Is there a better method?
- Lingua principale
- Shell
- Stelle
- 3.9k
- Fork
- 236
- Merge medio
- 33m
- PR unite (30g)
- 1
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la 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 nestybox/sysbox
-
sysbox-fs closes a container's seccomp listener on a transient POLLERR, so mount/umount fail with ENOSYSForse già presa @sjawhar l’ha presa 19 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Overlay mount from a new pid namespace fails with EINVAL (nsenter agent panics), breaks BuildKit SBOMForse già presa @adam-joura l’ha presa 4 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 15/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 64/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
Tutte le issue di nestybox/sysbox
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
-
good first issue packaging
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
-
help wanted let's document new command
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
tldr-pages/tldr#24773 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
I maintainer di solito rispondono entro 1 giorno