Vom 24. bis 26. März 2026 war Amsterdam zum zweiten Mal das Zentrum des (europäischen) Cloud-Native-Universums. Über 13.000 Teilnehmende hatten sich nach offizieller Verlautbarung der CNCF auf den Weg zur KubeCon EU in die niederländische Metropole gemacht, um die neuesten Infos von Kubernetes und Co. zu erfahren. Der erste Tag war – wenig überraschend – dem Thema KI gewidmet.

Im Frühjahr 2026 kann man keine Open-Source-Konferenz in Europa ausrichten, ohne das Thema (Daten-)Souveränität deutlich anzusprechen. In diesem Punkt hat die KubeCon EU jedoch Potenzial verspielt. Es gab im Vorfeld lediglich eine kleine Satelliten-Veranstaltung zu dem Thema. Zwar stellten europäische Kubernetes-Anwender wie der IT-Dienstleister der Bundeswehr BWI oder die französische Eisenbahngesellschaft SNCF ihre Cloud-Native-Reise auf der großen Hauptbühne vor, es bleibt aber der Eindruck einer eher stiefmütterlichen Behandlung des Themas zurück. Die Thesen: „Global zusammenarbeiten und lokal installieren“ und „You can always fork“ sind nur bedingt hilfreich.

Neue Laufzeiten und Plattformen: Lima, urunc und die BSD-Welt

Obwohl Kubernetes bereits 12 Jahre existiert und sich zu einem Standard gemausert hat, sind noch wichtige Arbeiten an fundamentalen Bauteilen notwendig. Technisch ist die Container-Orchestrierung zu weiten Teilen mit Linux verknüpft. Das betrifft sowohl die darunterliegende Infrastruktur als auch die Applikationen in den Containern. Bei Letzteren gibt es gute Neuigkeiten für die BSD-Freunde und auch für macOS-Anwender: das Projekt Lima (Linux Machines). Dieses ist schon seit 2022 Teil der CNCF-Familie. Das ursprüngliche Ziel war eine bessere Unterstützung von Containern auf macOS-Rechnern. Inzwischen ist es unter anderem auch für Linux verfügbar und fokussiert sich auf leichtgewichtige virtuelle Maschinen.

Im Vorfeld der KubeCon EU 2026 ist Version 2.1 des Projekts erschienen, die nun auch macOS und FreeBSD als Gäste unterstützt. Das Feature ist allerdings noch im experimentellen Stadium. Anwender können mit Lima leichtgewichtige virtuelle Maschinen nutzen – vergleichbar mit Containern. Letztere und auch Kubernetes-Pods lassen sich ebenfalls mit Lima verwalten. In der Dokumentation finden sich Beispiele für K3s, k0s und RKE2. Alternativ gibt es aber noch weitere Projekte wie KubeVirt, die ebenfalls virtuelle Maschinen und Container gleichwertig behandeln.

Neuigkeiten wurden auch für OpenBSD verkündet. Das Projekt urunc liefert eine weitere Laufzeitumgebung für Container, die auf das Unikernel-Konzept zurückgreift. Daraus leitet sich auch der Name des Projekts ab. Das runc für Unikernels: urunc. Anstatt eines Prozesses in einem Container startet hier quasi ein kleiner Betriebssystemkern in abgeschotteter Umgebung. Das ist mit einer speziellen virtuellen Maschine vergleichbar und bereits von den Kata-Containern und Nabla bekannt. Das urunc-Projekt will einen speziellen Unikernel liefern, der mit BSD kompatibel ist. Dazu kommt ein minimalistisches Basissystem, um eine Anwendung ausführen zu können. Damit entfällt das Portieren von BSD-Anwendungen für Container. Sie müssen nicht mehr Linux-kompatibel sein. Es ist lediglich der Mehraufwand zum Verwalten der zusätzlichen Laufzeitumgebung urunc zu erbringen. Seit knapp einem Jahr ist das Projekt Teil der CNCF-Familie.

mTLS ohne Sidecars: Cilium integriert ztunnel

Ein wichtiges Thema im Netzwerkbereich der Container ist noch immer mTLS (mutual Transport Layer Security). Das Schlüsselwort dabei lautet CNI (Container Network Interface). Eine bekannte Größe hier ist Cilium. Das Projekt startete vor zehn Jahren und steht seit 2021 unter der Obhut der CNCF. Seit Version 1.19 beherrscht Cilium auch mTLS, und zwar ohne die Verwendung sogenannter Sidecars oder die Notwendigkeit zur Anpassung der Container-Anwendungen. Ein wesentlicher Baustein ist eBPF. Das Format erlaubt einerseits umfassende Einblicke in die Vorgänge in Containern und Pods, darüber hinaus lassen sich damit Sicherheitsrichtlinien implementieren und durchsetzen.

Der andere Baustein ist ztunnel, das man vom Service Mesh Istio kennt. Im sogenannten Ambient-Modus hat hier jeder Knoten einen kleinen Proxy, der sich um die TLS-Vorgänge kümmert. Diese in Rust geschriebene Komponente hat Cilium nun ebenfalls integriert. Damit ließen sich ein paar bekannte Probleme aus dem eBPF-Ansatz lösen. Die Authentisierung ist spezifisch für jede Sitzung und nicht nur per Knoten. Es gehen nun keine initialen Pakete beim Handschlag verloren. Außerdem steigt der Durchsatz insgesamt, da ztunnel größere Datenmengen zusammenfasst und verschlüsselt. Das Loslegen ist recht einfach und erfolgt in drei Schritten. Zunächst muss man das ztunnel-Feature in den Helm-Charts für Cilium einschalten. Danach gilt es den ztunnel auszurollen. Am Schluss muss man das Label io.cilium/mtls-enabled=true auf den entsprechenden Namensraum setzen. Alle Pods, die dann dort landen, verwenden automatisch mTLS.

Resümee und der Blick nach vorn

Nach drei Tagen KubeCon-Konferenz lässt sich festhalten, dass es zwar auch im 12. Jahr noch sehr viel Energie und Leidenschaft für Kubernetes und Co. gibt, allerdings auch noch recht grundlegende Probleme in verschiedenen Bereichen zu lösen sind – und das auch ganz ohne den KI-Hype.

Angesichts weiter wachsender Besucherzahlen muss die CNCF die Planung ihrer Hausmessen entsprechend langfristig vorbereiten: Die nächste KubeCon EU findet vom 15. bis 18. März 2027 in Barcelona statt. Auch der Termin für 2028 steht bereits fest: Berlin soll vom 24. bis 27. April zum Mittelpunkt des Cloud-Native-Universums werden.

(map)

Google Research hat neue technische Details zu seinem Kompressionsalgorithmus TurboQuant veröffentlicht. Er solle den Key-Value-Cache großer Sprachmodelle auf bis zu 3 Bit pro Wert komprimieren – ohne messbare Einbußen bei der Modellgenauigkeit, teilten die Forscher mit. Auf Nvidia-H100-GPUs erreicht das Verfahren laut Google eine bis zu achtfache Beschleunigung bei der Berechnung von Attention-Logits gegenüber unquantisierten 32-Bit-Keys. Unquantisierte Key-Values sind in modernen Anwendungen jedoch normalerweise nicht anzutreffen. Viele Ansätze versuchen unter 4 Bit pro Wert zu erreichen, Google kombiniert für seine Herangehensweise die Verfahren PolarQuant und QJL.

Hintergrund

Der Key-Value-Cache, in dem Transformer-Modelle bereits berechnete Kontext-Informationen für den schnellen Zugriff zwischenspeichern, erfordert große Mengen Arbeitsspeicher. Bei langen Eingabesequenzen wächst dieser Cache stark an und wird zum Flaschenhals. Bisherige Vektorquantisierung lindert das zwar, erzeugt aber selbst einen Speicher-Overhead: Für jeden kleinen Datenblock müssen Quantisierungskonstanten in voller Präzision gespeichert werden, was den Kompressionsgewinn um 1 bis 2 Bit pro Wert wieder schmälert. Dieses Problem soll TurboQuant mit der Kombination von PolarQuant und QJL TurboQuant beseitigen.

PolarQuant: Kompression über Polarkoordinaten

PolarQuant weicht vom üblichen Ansatz ab, Vektoren in kartesischen Koordinaten zu verarbeiten. Stattdessen rotiert das Verfahren die Datenvektoren zufällig und wandelt sie anschließend in Polarkoordinaten um. Die Daten werden also nicht mehr als Abstände entlang einzelner Achsen gespeichert, sondern als Kombination aus einem Radius, der die Signalstärke beschreibt, und Winkeln, die die Bedeutung kodieren. Da die entstehenden Winkelverteilungen stark konzentriert und vorhersagbar sind, entfällt der sonst nötige Normalisierungsschritt mitsamt seinem Speicher-Overhead. PolarQuant übernimmt in TurboQuant den Großteil der Kompressionsarbeit.

QJL: Fehlerkorrektur mit einem Bit

Die zweite Stufe adressiert den kleinen Restfehler, den PolarQuant hinterlässt. QJL (Quantized Johnson-Lindenstrauss) nutzt die in der theoretischen Informatik bekannte Johnson-Lindenstrauss-Transformation, um die verbleibenden hochdimensionalen Fehlerdaten auf ein einziges Vorzeichen-Bit pro Wert zu reduzieren. Die wesentlichen Abstände und Relationen zwischen den Datenpunkten bleiben dabei erhalten. QJL fungiert so als mathematische Fehlerkorrektur: Sie eliminiert systematische Verzerrungen in den Attention-Scores, ohne zusätzlichen Speicher-Overhead zu verursachen.

Vielversprechende Benchmarks

Google hat alle drei Algorithmen mit den Open-Source-Modellen Llama-3.1-8B-Instruct und Ministral-7B-Instruct auf gängigen Long-Context-Benchmarks getestet, darunter LongBench, Needle in a Haystack, ZeroSCROLLS, RULER und L-Eval. Die Ergebnisse: In den Needle-in-a-Haystack-Tests reduzierte TurboQuant den KV-Speicher laut Google um mindestens den Faktor 6; in den im ICLR-Paper gezeigten LongBench-Ergebnissen liegen die Kompressionsraten je nach Bitbreite darunter oder darüber. Dabei sollen die Modelle in den getesteten Aufgaben – Frage-Antwort-Szenarien, Code-Generierung und Zusammenfassungen – nicht an Qualität verloren haben. In den Needle-in-a-Haystack-Tests, bei denen ein Modell eine einzelne Information in großen Textmengen finden muss, erzielte TurboQuant über alle Benchmarks hinweg die gleiche Genauigkeit wie die Vollpräzisions-Basis (Score: 0,997).

Ein Training oder Feintuning der Modelle ist für den Einsatz von TurboQuant nicht erforderlich. Google vergleicht TurboQuant in der Vektorsuche mit Product Quantization (PQ) und RabitQ: Im Paper kritisieren die Autoren an PQ vor allem den datensatzabhängigen Trainingsaufwand und die Notwendigkeit großer Codebooks. An RaBitQ bemängelt Google die fehlende Vektorisierung, fehlende GPU-Unterstützung und zusätzliche Overheads.

Einsatz in Gemini und der Google-Suche

Google sieht die Hauptanwendung von TurboQuant in der Beseitigung von KV-Cache-Engpässen in Modellen wie Gemini. Darüber hinaus soll das Verfahren die semantische Vektorsuche beschleunigen, bei der nicht nach Schlüsselwörtern, sondern nach inhaltlicher Ähnlichkeit in Milliarden von Vektoren gesucht wird. Durch die geringe Speicheranforderung und den nahezu wegfallenden Preprocessing-Aufwand ließen sich große Vektorindizes deutlich effizienter aufbauen und abfragen.

TurboQuant wird auf der ICLR 2026 vorgestellt, PolarQuant und QJL auf der AISTATS 2026. Weitere Informationen finden sich im Google-Research-Blog.

(fo)

Android 17 wird die erste Version von Googles mobilem Betriebssystem mit Schutz vor Angriffen durch Quantencomputer sein. Das hat der Konzern am Mittwoch bekannt gegeben. Der Schutz wird auf verschiedenen Ebenen von Android implementiert – auch App-Entwickler müssen mithelfen.

Vorsorgliche, mehrjährige Umstellung

Wie Google in seiner Ankündigung schreibt, befindet sich die moderne digitale Sicherheit an einem Wendepunkt. Quantencomputer stellten neben ihren Vorteilen auch eine Gefahr dar, denn sie könnten herkömmliche Verschlüsselung schon bald mit Leichtigkeit knacken. Um gegen künftige potenzielle Angriffe durch Quantencomputer gewappnet zu sein, plant Google „eine vorsorgliche, mehrjährige Umstellung auf die Post-Quanten-Kryptografie (PQC)“. Google bereite sich eigenen Angaben zufolge schon seit 2016 auf eine „Postquantenwelt“ vor.

Auch Android muss entsprechend abgesichert werden, so der Konzern. Beim mobilen Betriebssystem aus Mountain View gehe die Absicherung über das Patchen einzelner Anwendungen oder Transportprotokolle hinaus. Die gesamte Plattformarchitektur des Betriebssystems müsse angefasst werden.

Der Ankündigung Googles zufolge, in der der Konzern zum ersten Mal öffentlich über eine Absicherung des Betriebssystems gegen Angriffe durch Quantencomputer schreibt, erhält Android 17 ab der nächsten Beta-Version eine umfassende Integration des kürzlich fertiggestellten NIST-PQC-Standards, um eine „quantenresistente Vertrauenskette“ (quantum-resistant chain of trust) zu integrieren. Diese „Chain of Trust“ schütze die Plattform kontinuierlich – „vom Hochfahren des Betriebssystems bis hin zur Ausführung weltweit verteilter Anwendungen“.

Quantensicherer Bootvorgang

Google integriert zunächst zwei Neuerungen im Bereich der Postquanten-Kryptografie (PQC) in Android 17. Zum einen zieht der Signaturalgorithmus ML-DSA (Module-Lattice-based Digital Signature Algorithm) in die Android-Verified-Boot-Bibliothek (AVB) ein. So wird der Bootvorgang quantensicher.

Zum anderen beginnt Google damit, die Remote-Attestation auf eine vollständig PQC-konforme Architektur umzustellen. Dabei handelt es sich um eine Funktion, mit der ein Gerät seinen aktuellen Zustand gegenüber einem Remote-Server nachweisen kann, um etwa einem Server in einem Unternehmensnetzwerk zu beweisen, dass es eine sichere Betriebssystemversion ausführt.

Der Schutz des Betriebssystems stellt laut Google „nur die erste Verteidigungsstufe“ dar. Auch Entwickler müssen über die erforderlichen kryptografischen Grundelemente verfügen, um PQC-Schlüssel nutzen und eine robuste Identitätsprüfung einrichten zu können. Hierfür wird Google den Android Keystore um ML-DSA-Unterstützung erweitern, damit Entwickler Schlüssel generieren und diese direkt in der sicheren Hardware des Geräts speichern können. Damit soll „eine neue Ära der Identitätsprüfung und Authentifizierung für das App-Ökosystem eingeläutet werden, ohne dass Entwickler eigene kryptografische Implementierungen entwickeln müssen“.

Google plant zudem, den Play Store sowie die Entwicklersignaturen aller darin gelisteten Apps auf PQC umzustellen. Der Konzern unterhält selbst Forschungseinrichtungen, die sich intensiv mit Quantencomputing beschäftigen und neuerdings neutrale Atome erforschen.

Die stabile Version von Android 17 wird voraussichtlich im Juni 2026 zunächst für Googles Pixel-Modelle erwartet.

(afl)