Oktober 2026: hvad der ændrede sig upstream, og hvad vi gjorde ved det

Hej fra team Obmondo,

Dette er oktoberudgaven af vores månedlige nyhedsbrev, hvor vi samler op på, hvad der ændrede sig i de open source-projekter, jeres platform kører på, og hvad vi gjorde ved det. Hver historie har to halvdele: nyheden upstream og det arbejde i KubeAid eller LinuxAid, der fulgte af den.

Kyverno udfaser sit gamle policy-format, og alle KubeAid-policies blev skrevet om inden fristen

Nyt: Kyverno 1.19 udfaser det gamle policy-format

Kyverno er en open source policy-motor til Kubernetes. Den kører inde i clusteret og tjekker hver ressource, der oprettes eller ændres, mod et sæt policies. En policy kan blokere en ændring, der bryder en regel, justere en ressource på vej ind eller oprette andre ressourcer ved siden af, så clusteret håndhæver sine egne regler i stedet for at stole på, at folk husker dem.

KubeAid leverer Kyverno-policies til de mønstre, de fleste clustre har brug for: at sende image pulls gennem jeres registry-cache, at kopiere registry pull secrets ind i hvert namespace og at give hvert namespace standardkvoter og -grænser for ressourcer. Oven på det skriver vi skræddersyede policies til kunder, hvor deres opsætning kræver det.

Kyverno 1.19 udkom den 20. august 2026, og KubeAid har leveret den siden den 24. august. Den udfaser de gamle policy-typer; fjernelsen er planlagt til 1.20, forventet november 2026.

Læs Kyvernos annoncering af 1.19 →

Vedligeholdelse: Alle policies skrevet om, før det gamle format forsvinder

Hver policy, KubeAid leverede, og hver policy, kunder kørte oven på, var af den gamle type. Alle ville være holdt op med at virke ved næste Kyverno-opgradering. Det nye format deler den gamle ClusterPolicy op i fem fokuserede typer, hver navngivet efter det, den gør: ValidatingPolicy tjekker en ressource og kan afvise den, MutatingPolicy ændrer en ressource på vej ind i clusteret, GeneratingPolicy opretter andre ressourcer ud fra den, ImageValidatingPolicy verificerer container-images, og DeletingPolicy rydder op.

Vi skrev hver KubeAid-policy om til en af disse. Hver policy blev testet i et miljø, der efterligner rigtige produktionsclustre, inklusive skiftet fra den gamle policy til den nye, sådan som det vil ske på jeres cluster. Ændringerne rulles ud i de kommende servicevinduer.

Lokis gamle Helm-chart er udfaset, central logning er bygget om, og en OpenTelemetry-pipeline ind i OpenObserve

Nyt: Lokis gamle Helm-chart er udfaset

Grafana Loki er et open source log-lager til Kubernetes. I modsætning til en søgemaskine indekserer det ikke teksten i hver loglinje; det indekserer et lille sæt labels, såsom namespace og container, og gemmer linjerne komprimeret ved siden af. Det holder det billigt at drive, og det forespørges fra den samme Grafana, der allerede viser jeres Prometheus-metrikker, så logs og metrikker ligger side om side ét sted.

To ting ændrede sig upstream. Helm-chartet loki-stack, det samlede chart, de fleste installationer startede fra, er markeret som udfaset af Grafana og leverer stadig Loki 2.9, mens Loki selv er nået til 3.7. Og siden den 16. marts 2026 vedligeholdes Loki-chartet i grafana-community-repositoriet af community'et, mens kopien i Grafanas eget repositorium kun holdes i vedligeholdelsestilstand.

Læs migreringsnotatet fra Lokis vedligeholdere →

Nyt: OpenObserve når 1.0

OpenObserve er en open source observability-platform, der samler logs, metrikker og traces ét sted. Den gemmer alt som kolonnebaserede filer på objektlager i stedet for i et søgeindeks, hvilket er det, der holder den billig at drive ved store mængder, og den taler OpenTelemetry indbygget, så alt, der udsender OTLP, kan sende til den uden en agent af sin egen. Version 1.0.0, den første udgivelse, projektet kalder generelt tilgængelig, udkom den 11. september 2026 med service level objectives med burn-rate-alarmer, sammensatte alarmer og databaseovervågning.

Læs udgivelsesnoterne til OpenObserve 1.0.0 →

Vedligeholdelse: Central logning i KubeAid bygget om på community-chartet

KubeAid leverede Loki gennem loki-stack. Vi erstattede det med det community-vedligeholdte chart, på Loki 3.7, og skrev standardindstillingerne om omkring det: én Loki-instans per cluster med 30 dages opbevaring, håndhævet af compactoren; Fluent Bit som log-shipper, valgt frem for alternativerne for sit lave hukommelsesforbrug på hver node.

Når én node ikke længere er nok, vokser opsætningen til Lokis distribuerede tilstand på S3-kompatibelt objektlager; vi springer den mellemliggende "simple scalable"-tilstand over, som chartet markerer som udfaset og planlagt fjernet i Loki 4. Det nye chart er i KubeAid siden udgivelse 32.7.1 (2. september 2026).

Featureudvikling: Sådan bygges en observability-pipeline med OpenTelemetry, Hubble og OpenObserve

Sådan hænger en komplet pipeline ind i OpenObserve sammen på KubeAid. Vi satte den op for nylig for en kunde, og hver del af den ligger i KubeAid til fri afbenyttelse. OpenTelemetry Operator styrer collectorerne som Kubernetes-ressourcer. En agent på hver node videresender container-logs, nodens systemd-journal og Kubernetes-events. Hubble, netværksobservability-laget i Cilium, tilføjer en fortegnelse over hver forbindelse mellem pods, tilladt eller afvist, så et spørgsmål om en netværkspolicy besvares med en søgning i stedet for en pakkeopsamling. Login går gennem Keycloak SSO.

Metrikker bliver hos kube-prometheus-stakken. Det første design lod collectoren indsamle dem også, men hver alarmregel og hvert dashboard i KubeAid er bygget på kube-prometheus' label-konventioner, så kube-prometheus beholder metrikker og alarmering præcis som før og remote-writer en kopi til OpenObserve. Resultatet er én grænseflade, hvor en loglinje, en Kubernetes-event og den metrik, der steg i samme minut, ligger ved siden af hinanden, med OpenObserves færdige dashboards til kube-prometheus-metrikker inkluderet.

Vi håber, det er nyttigt som mønster. I kan sætte det op selv fra jeres clusters KubeAid-konfiguration, eller sige til, så sætter vi det op sammen med jer.

Backup-exporteren dækker nu MariaDB og alarmerer med mindre støj

Værktøj: Backup-exporteren: landede backuppen faktisk i bucketen?

Hvert backup-værktøj rapporterer om sine egne kørsler. Velero siger, at volume-snapshottet lykkedes, Postgres-operatoren siger, at dumpet blev færdigt, og et dashboard viser grønt. Ingen af dem besvarer det spørgsmål, der betyder noget, når I skal gendanne: ligger der en nylig, komplet kopi i objektlageret lige nu? En bucket-policy kan udløbe filer for tidligt, credentials kan rotere, en tidsplan kan sættes på pause og glemmes, og værktøjet bliver ved med at rapportere om den sidste kørsel, det kender til.

Backup-exporteren er en tjeneste, vi skrev til præcis det hul. Den kører på jeres cluster ved siden af KubeAid-agenten, læser backup-bucketsene direkte og daterer det, der faktisk ligger der, for Veleros volume-backups, Postgres' logiske og WAL-backups, MongoDB- og MariaDB-dumps og Sealed Secrets' masternøgle. Ud fra det eksporterer den Prometheus-metrikker, og de alarmregler, der følger med, udløses, når en backup mangler eller er ældre end det recovery point objective (RPO), der er aftalt for jeres cluster. Den kører på vores kunders clustre i dag, og de alarmer, den rejser, er dem, vores vagthold handler på.

Vedligeholdelse: Hvad der ændrede sig i exporteren i denne måned

Exporteren gik gennem tre udgivelser i september, med de tilhørende alarmregler i KubeAid:

• MariaDB er med på listen. Dumps lavet af MariaDB-operatoren opdages og dateres nu, med deres egne alarmer for manglende backup og overskredet RPO.
• Et tjek straks efter start. Exporteren tjekker bucketsene, så snart den starter, i stedet for at vente på sin første planlagte kørsel, og et langt tjek overlapper ikke længere med det næste.
• Én alarm per namespace. Alarmer for manglende backup og overskredet RPO grupperes per namespace og lister hvert berørt volume.
• Ingen alarmer for det, ingen bad om at få sikkerhedskopieret. Volumes, der er undtaget via label eller policy, volumes, der stadig venter på deres første kørsel, og volumes, der er slettet fra clusteret, forbliver tavse.

Kørende container-images scannes for kendte sårbarheder, med fundene i Obmondo-dashboardet

Værktøj: Scanning af de images, der kører, ikke dem, der blev pushet

Et container-image bygges én gang og kører i måneder, og de sårbarheder, der offentliggøres mod pakkerne inde i det, bliver ved med at komme efter bygningen. En registry-scanning ved push fanger det, der var kendt den dag; den siger intet om et image, der har kørt siden foråret, eller om et image hentet fra et offentligt registry, som aldrig passerede jeres registry overhovedet.

Trivy er en open source-scanner; den læser et image lag for lag, lister dets operativsystempakker og applikationsafhængigheder og matcher dem mod distributionernes og upstream-projekternes sikkerhedsbulletiner. Trivy Operator kører den inde i clusteret: den holder øje med hvert Deployment, StatefulSet, DaemonSet, Job og CronJob, scanner hvert image, de kører, skriver en VulnerabilityReport per workload og scanner igen, efterhånden som nye bulletiner offentliggøres, så et fund dukker op for et image, der ikke har ændret sig i måneder.

Læs dokumentationen til Trivy Operator →

Featureudvikling: Hvert fund i Obmondo-dashboardet, med sin opgraderingsvej

KubeAid leverer nu Trivy Operator med en delt scanner i clusteret, indstillet til kun at rapportere sårbarheder af graden Critical eller High, som der findes en rettet version til. En ny security-exporter i KubeAid-agenten indsamler rapporterne fra clusteret, slår hvert fund op til dets CVE-score, alvorlighedsgrad, berørte pakke og version, om der findes en rettet version og linket til bulletinen, og sender det videre til Obmondo. Exporteren læser kun.

I Obmondo-dashboardet ser I, hvilke kørende containere der bærer kendte sårbarheder, rangeret efter alvorlighedsgrad, og for hver, der kan rettes, den version, der lukker den. Der rejses en alarm, når et kørende image bærer en CVE af graden Critical eller High, og en opgradering, der lukker den, er tilgængelig, så opgraderingen kan bookes ind i et servicevindue. Fundene fastfryses mod den booking, og dashboardet viser, hvilke CVE'er servicevinduet lukkede.

ExternalDNS 0.22 læser en ny annotation, og en Service, der stadig bærer den gamle, kan miste sin DNS-record

Nyt: ExternalDNS 0.22 ændrer den annotation, den læser

ExternalDNS er den komponent, der holder DNS i trit med clusteret. Når en Service eller Ingress bærer en hostname-annotation, opretter den recorden hos DNS-udbyderen, og når Servicen forsvinder, fjerner den recorden igen. KubeAid leverer den som et styret chart, så den installeres og opdateres som enhver anden applikation på clusteret.

Udgivelse 0.22.0, offentliggjort den 20. august 2026, ændrede den annotation, den leder efter. Præfikset, der har været brugt siden projektets begyndelse, external-dns.alpha.kubernetes.io/, er erstattet af external-dns.kubernetes.io/, og det gamle præfiks læses ikke længere, medmindre ExternalDNS udtrykkeligt får besked på at beholde det. En Service, der stadig bærer den gamle annotation, ses ikke længere, og med sync-policy slået til er det værre end at blive overset: controlleren betragter den eksisterende record som forældreløs og sletter den hos udbyderen, så endpointet går offline. Samme udgivelse gør sync-policyen til en påkrævet indstilling: upsert-only er ikke længere standard. Helm-chartet fulgte den 11. september som 1.22.0, og KubeAid 32.9.0 tog det med i september.

Læs udgivelsesnoterne til ExternalDNS 0.22.0 →

Vedligeholdelse: Alle clustre flyttet til den nye annotation uden at miste en record

• Audit først: Alle Services og Ingresses på alle styrede clustre blev gennemgået for det gamle præfiks. Database-endpoints, gateways og applikations-hostnames bar det stadig.
• Tørkørsel på staging: Den nye udgivelse blev kørt på staging-clustre med --dry-run=true, så controlleren loggede, hvad den ville oprette, ændre eller slette, uden at røre udbyderen. Den log blev læst for sletninger før alt andet.
• Begge præfikser under flytningen: ExternalDNS blev sat op til at læse det gamle præfiks ved siden af det nye, så et manifest kunne opdateres i Git i sit eget tempo, mens recorderne blev stående.
• Manifester først, controller bagefter: Annotationerne blev flyttet til external-dns.kubernetes.io/hostname i versionsstyringen, og controller-opgraderingen kørte i de faste servicevinduer.

KubeOne 1.14, en runde kubeaid-cli-rettelser, og KubeAid-agenten på arm64 med live opdateringsstatus

Nyt: KubeOne 1.14 flytter det understøttede spænd til Kubernetes 1.34 til 1.36

KubeOne er værktøjet fra Kubermatic, der installerer og opgraderer kubeadm-baseret Kubernetes på servere, I allerede har. KubeAid bruger det til almindelig bare metal og rene virtuelle maskiner, de hosts, der ikke har et cloud-API bag sig; clustre på AWS, Azure og Hetzner bygges i stedet med Cluster API. Version 1.14.0 udkom den 27. juli 2026 og understøtter Kubernetes 1.34, 1.35 og 1.36, mens 1.33 er droppet. Værktøjet til at migrere væk fra in-tree cloud providers er fjernet i denne udgivelse, så et cluster, der stadig kører på en, skal gøre den flytning færdig på 1.13 først. Patch-udgivelser fulgte gennem august, op til 1.14.3 den 24. august.

Læs udgivelsesnoterne til KubeOne 1.14.0 →

Nyt: KubeAid-agenten: forbindelsen mellem jeres cluster og Obmondo

Hvert KubeAid-cluster, Obmondo passer, kører en lille agent. Den autentificerer sig mod Obmondo-API'et med et klientcertifikat og rapporterer det, platformen har brug for at vide: hvor mange noder clusteret har, hvilken Kubernetes-version det kører, og, gennem de exportere, der er beskrevet tidligere i denne udgave, tilstanden af dets backups og sårbarhederne i dets kørende images. Den udfører også arbejdet under et aftalt servicevindue: den forbereder KubeAid-opdateringen som en ændring til jeres clusters konfigurationsrepositorium, venter på merge og kører Argo CD-syncs applikation for applikation. Agenten holder Obmondo-credentialet og intet andet; de exportere, der har brug for læseadgang til hele clusteret, kører som separate workloads med deres egne rettigheder.

Se kubeaid-agent-chartet i KubeAid →

Vedligeholdelse: kubeaid-cli: hvad der ændrede sig omkring opsætning og opgradering af clustre

kubeaid-cli er KubeAids kommandolinjeværktøj, der bootstrapper et cluster og opgraderer det. For et bare metal-cluster renderer det KubeOne-konfigurationen fra jeres clusters konfigurationsrepositorium, kører KubeOne og håndterer det, der kommer før og efter: Argo CD-bootstrap, drain af hver node, tjekket af at hver node kom tilbage på målversionen. Over de seneste to måneder fik det en række forbedringer, de fleste fundet under opgradering af rigtige clustre:

• Opgraderinger til Kubernetes 1.35 og 1.36. KubeOne 1.14.3 og Cilium 1.20.2 følger med; Cilium 1.19 er kun testet op til Kubernetes 1.34, så de to hører sammen.
• Ét hjem per cluster. Konfiguration, kubeconfig og logs for et cluster ligger nu i deres egen mappe. To clustre bootstrappet fra samme arbejdsmappe overskriver ikke længere hinandens kubeconfig, og en kubeconfig lander aldrig mere inde i et git-checkout.
• Ingen stiltiende genbrug. At starte en ny konfiguration ved siden af en eksisterende spørger nu, før den genbruges, i stedet for at give det gamle clusters navn tilbage som standard.
• Opgraderinger på virtuelle maskiner. Tjekket for cgroup v2, der kører før en opgradering, genkender nu KVM- og QEMU-gæster, hvor det før stoppede opgraderingen.
• To alarmer, der aldrig forsvandt. Scheduleren og controller manageren på KubeOne-clustre eksponerer nu deres metrikker, så Prometheus kan nå dem, hvilket gør en ende på de to "instance unreachable"-alarmer, der fyrede permanent.

Hver opgradering, vi kører for en kunde, øves først på en virtuel maskine, der efterligner clusteret, med den samme kubeaid-cli-udgivelse, der skal bruges i servicevinduet. Den generalprøve er der, de fleste af rettelserne ovenfor kom fra.

Se udgivelserne af kubeaid-cli →

Featureudvikling: KubeAid Agent kører på arm64 og viser opdateringen, mens den sker

To forbedringer landede i september, begge i udgivelse 1.1.3 af 28. september 2026.

Images til amd64 og arm64. Indtil september blev agentens image kun bygget til amd64. På et cluster, der blander arkitekturer, såsom et med Ampere-baserede arm64-servere fra Hetzner ved siden af amd64-noder, kunne podden blive placeret på en arm64-node og gå ned ved start, og dermed stoppede rapporteringen af nodeantal, og der blev rejst en alarm. Hver udgivelse offentliggøres nu til begge arkitekturer under samme tag, så scheduleren kan placere agenten på enhver node. Udgivelser bærer også major- og major.minor-tags, så et cluster kan følge en linje af udgivelser uden at låse hver patch fast.

Live fremdrift i Obmondo-portalen. Under et opdateringsvindue rapporterer agenten nu opdateringens tilstand til Obmondo undervejs: planen, hver applikation, efterhånden som den synkroniserer, er synkroniseret eller fejlet, og om opdateringen venter på merge. Obmondo-portalen viser det live, så I kan følge et servicevindue, mens det kører, i stedet for at vente på rapporten til sidst eller selv læse Argo CD. Rapporteringen er asynkron, så en langsom forbindelse til API'et forsinker aldrig en sync.

NVIDIA GPU Operator er nu et KubeAid-chart

Værktøj: Hvad en GPU-node har brug for, før den kan køre en model

At køre AI-modeller på jeres eget cluster kræver mere end en node med en GPU i. Kernedriveren, container-toolkittet, det device-plugin, der fortæller Kubernetes, hvor mange GPU'er en node har, og den exporter, der offentliggør GPU-metrikker, skal alle installeres i matchende versioner på hver GPU-node og opgraderes sammen. NVIDIA GPU Operator gør det som en Kubernetes-operator: den finder de noder, der har en GPU, installerer komponenterne på dem som containere og holder dem i trit. Udgivelse 26.7.0 udkom den 21. august 2026.

Se udgivelsen af GPU Operator →

Featureudvikling: GPU Operator er nu et KubeAid-chart

Indtil september var GPU Operator et upstream-chart, som KubeAid ikke styrede. KubeAid 32.9.1 tilføjer den som et KubeAid-chart, så den installeres og opgraderes som enhver anden applikation på clusteret.

MinIO er arkiveret, og RustFS 1.0 tager over som backup-lager, med en kopi uden for huset

Nyt: MinIOs community-udgave er arkiveret, og RustFS 1.0 er ude

MinIO er et open source, S3-kompatibelt objektlager, og i årevis var det det populære valg til at køre et på egne servere. I december 2025 satte MinIO sit open source-repositorium i vedligeholdelsestilstand, så udviklingen kun fortsatte i det kommercielle produkt, og den 25. april 2026 blev repositoriet arkiveret.

RustFS er et S3-kompatibelt objektlager skrevet i Rust under Apache 2.0-licensen, bygget som en erstatning for MinIO: erasure coding, versionering, object lock, livscyklusregler og bucket-replikering. Version 1.0.0, den første udgivelse, projektet kalder produktionsklar, udkom den 16. september 2026.

Læs udgivelsesnoterne til RustFS 1.0.0 →

Featureudvikling: RustFS som backup-lager, installeret af LinuxAid, med en kopi uden for huset

En backup skal ligge uden for det cluster, den beskytter. Efter MinIOs udfasning flyttede backupperne først til Zenko CloudServer, som kører på en almindelig server, men ikke på Kubernetes, og vi ønskede ét lager, der kører begge steder. Vi kiggede også på Garage, et andet S3-kompatibelt lager, men det er tidligt i sit liv, og dets rettigheder er for grove til det, en backup har brug for. RustFS vandt på to punkter: credentials med begrænset adgang er nemmere at sætte op, og konfigurationen er enklere.

Vi skrev et Puppet-modul, udgivet som puppet-rustfs, så LinuxAid installerer og styrer RustFS på en Linux-server: tjenesten kører som en container, dens data ligger på et dedikeret filsystem, og S3-endpointet eksponeres gennem HAProxy med et TLS-certifikat, der hentes automatisk. På Kubernetes-siden gik KubeAids RustFS-chart til 1.0.0 dagen efter udgivelsen, og MinIO-chartsene blev fjernet fra KubeAid i september.

Anden halvdel er kopien uden for huset. Bucket-replikering i RustFS synkroniserer hver backup til en anden RustFS på en anden lokation, også provisioneret gennem LinuxAid. Adgang følger princippet om mindst mulig rettighed: et backup-job får credentials, der kun kan tilføje objekter, og med versionering og object lock slået til kan intet, et backup-job kan gøre, overskrive eller slette en tidligere backup. Et kompromitteret cluster kan ikke tage sin egen historik med sig.

HAProxy 3.2 LTS er hoveddøren på Linux-hosts, så ingen applikationsport vender mod internettet på egen hånd

Nyt: HAProxy 3.2 er en langtidsunderstøttet udgivelse, vedligeholdt indtil 2030

HAProxy er den open source-load balancer og reverse proxy, der sidder foran tjenester på en Linux-host. Den terminerer TLS, router forespørgsler efter hostname og sender dem videre til applikationen bagved, så applikationen selv aldrig lytter på internettet.

Version 3.2 er en langtidsunderstøttet udgivelse (LTS), vedligeholdt af upstream indtil 2030. Den fordeler arbejdet på tværs af trådgrupper, så maskiner med mange kerner bruger mindre tid på at vente på låse, udvider certifikatlageret fra 3.0 og tilføjer en første indbygget ACME-klient, så proxyen selv kan hente og forny sine certifikater. Den strammer også håndteringen af misdannet protokoltrafik.

Grunden til, at det betyder noget på en Linux-host, er de tjenester, der har for vane at ende der: et S3-kompatibelt objektlager, der lytter på sin egen port, et fjernadministrationspanel på en anden. Hver af dem eksponeret direkte er en separat ting at kryptere, beskytte og begrænse. Bag én LTS-reverse proxy deler de én hoveddør.

Læs annonceringen af HAProxy 3.2 LTS →

Vedligeholdelse: Ét indgangspunkt per host, certifikater overvåget, backend-porte lukket

LinuxAids edge-routing på Linux-hosts blev bygget om omkring HAProxy 3.2:

• Følger LTS-sporet: HAProxy installeres fra upstreams 3.2-repositories, så hosten får sikkerheds- og stabilitetsopdateringerne fra den gren og bliver på en lige-nummereret LTS-udgivelse.
• Én profil til enhver backend: En standardprofil lægger en backend, for eksempel RustFS' S3-endpoint eller RustDesks webgrænseflade, bag et hostname på port 443 med TLS termineret af HAProxy.
• Certifikater overvåget, ikke scriptet: Fornyelse flyttede fra eksterne scripts til HAProxys certifikatlager. En certifikatinspektør rapporterer dage til udløb til Prometheus og fjerner tærsklerne for domæner, der ikke længere findes.
• Oppetidstjek afgrænset per host: Blackbox exporter-tjek er bundet til den host, der betjener domænet, så to hosts ikke længere prober hinandens domæner, og oppetidsgrafen i Grafana er korrekt.
• Firewall som politik: Firewall-regler er erklæret i LinuxAids host-politik. Backend-porte er lukket mod internettet og kan kun nås gennem HAProxy.

Resultatet er en HTTPS-front for lager- og administrationsværktøjer, der ikke kræver manuel fornyelse, med overvågning, der holder sig stille, medmindre et certifikat eller et domæne virkelig er i problemer.

• Tak, fordi I læste med. Vi håber, I fandt noget af værdi i denne udgave. Hvis noget her rejste et spørgsmål, så skriv til os på info@obmondo.com, så svarer vi. Vi ses i næste måned.