aYOUne

Changelog

Was sich verändert hat — gruppiert nach Release, filterbar nach Komponente und Repository.

Gruppieren nach: Release Meilenstein
Komponente
Allecoord 18applications 8pages 7hr 6pm 6ayauto 5notifications 5tasks 5onboarding 4page-editor 4pwa 4blocks 3coding 3i18n 3module-feature 3rag 3alerts 2auth 2cascade-68 2codegen 2courses 2credentials 2deps 2doc-engine 2infra 2migrate 2node 2pipeline-red-head-audit 2pm-states 2podcast 2routes 2security 2seeds 2selfhost 2types 2validator 2voice 2wallboard 2webpages 2agent-env 1alarme 1audit 1autopilot-safe 1awards 1briefing 1briefings 1build 1cache 1coding-live 1codingjobs 1consumers 1crawl-monitor 1crm 1css 1ctas 1dashboard 1dispatch 1domains 1employees 1experiments 1funktionen 1gantt 1huelle 1humanizer 1import 1invite 1jobs 1karriere 1keyword-planner 1kiosk-dashboard 1kiosk-keyboard 1kiosk-settings 1learning 1ledger 1lock 1logging 1mailfunnel 1mails 1mcp/rag 1memory-curator-daily 1modules 1monitoring 1multi-select 1overlays 1personal 1pipeline-melder 1playground 1portal 1portal-invite 1portrait 1reporting 1reseller 1route 1scheduler 1senderbrands 1shop 1sitemap 1states 1sub-view 1ucd 1ucds 1user-menu 1vault 1workspace-create 1workspaces 1
Repository
Alleayoune 196api 1automation-scripts 1mobile-app 1models 1
Weitere Änderungen 2
Fix node

Spreizung zaehlt nur Pods derselben Fassung (matchLabelKeys, 0.1.10)

GEMESSEN, nicht abgeleitet: nach der Ausbringung von 0.1.9 landeten BEIDE Repliken
von ayoune-updates-develop-node auf demselben Knoten (fp7m), waehrend heartbeats im
selben Lauf sauber auf zwei Knoten verteilte. Gegenprobe: das Loeschen einer der
beiden updates-Repliken liess den Ersatz-Pod auf einem ANDEREN Knoten (fny8) starten
- der Mechanismus greift also, nur nicht waehrend eines Rollouts.

Ursache: der labelSelector der Spreizung (name/instance/app) trifft auch die Pods der
ALTEN Fassung. Waehrend eines Rollouts zaehlen die mit, die Schiefe wird gegen den
falschen Bestand gerechnet, und mit dem weichen ScheduleAnyway kann die Wertung dann
zugunsten eines einzelnen Knotens ausfallen.

matchLabelKeys: [pod-template-hash] beschraenkt die Zaehlung auf dieselbe Fassung
(stabil seit K8s 1.30, Cluster faehrt 1.35). Umkehrprobe gefahren: der API-Server
liefert das Feld im Objekt zurueck, verwirft es also nicht still.

Ein-Replikat-Render bleibt gegen 0.1.7 identisch (ausser dem Fassungs-Etikett);
leere matchLabelKeys-Liste laesst das Feld ersatzlos entfallen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Neu node

PodDisruptionBudget + Knoten-Spreizung fuer Mehr-Replikat-Dienste (0.1.8)

Anlass: 2026-08-22T18:19Z raeumte ein ScaleDown des Cluster-Autoscalers BEIDE
Repliken von ayoune-states-develop-node zugleich (0/2, rund 14 Minuten). Das Chart
bot dem Autoscaler nichts an, was ihn bremst - im ganzen Baum existierte genau EIN
PodDisruptionBudget, und der gehoert dem Istio-Ingressgateway.

- templates/pdb.yaml: PDB, gerendert NUR bei replicaCount > 1, minAvailable: 1,
Selektor = die drei POD-Etiketten (name/instance/app). Ein echter bool in
podDisruptionBudget.enabled schlaegt die Automatik; maxUnavailable schlaegt
minAvailable.
- deployment.yaml: topologySpreadConstraints - Roh-Durchreichung (Bauform wie
affinity) plus Automatik ab replicaCount > 1 mit chart-gerendertem labelSelector.
whenUnsatisfiable: ScheduleAnyway, bewusst weich.
- values.yaml: podDisruptionBudget / topologySpreadConstraints / topologySpread.

Fuer die 227 Ein-Replikat-Dienste aendert sich NICHTS: helm template 0.1.7 gegen
0.1.8 ist identisch ausser dem helm.sh/chart-Etikett (das jeder Chart-Bump traegt);
bei replicaCount 0 und 1 wird weder PDB noch Spread gerendert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>