The Pulse

Google pianifica aggiornamenti del client Python di Kubernetes per i carichi di lavoro di IA

Gli ingegneri di Google Cloud e i contributori open source stanno modernizzando il client Python ufficiale di Kubernetes. La roadmap comprende il supporto asincrono nativo, la memorizzazione nella cache delle risorse e modifiche alla generazione del codice.

AI.info Team · · verificato · su 1 fonte ↓ · Pubblicato 13 nov 2026

Gli ingegneri di Google Cloud e i contributori open source stanno lavorando alle chiamate asincrone native, alla memorizzazione nella cache delle risorse e a un’elaborazione più rapida dei dati per il client Python ufficiale di Kubernetes, nell’ambito di un progetto di modernizzazione rivolto ai carichi di lavoro di IA e machine learning. In un post del 12 novembre, Google ha delineato una roadmap per il client, non annunciato una release completata.

Il lavoro è in corso insieme ai contributori del Kubernetes SIG API Machinery. Il client collega le applicazioni Python a Kubernetes, che il post descrive come un’infrastruttura per pianificare l’uso degli acceleratori, coordinare l’addestramento distribuito e scalare gli endpoint di model serving.

Sostituire un generatore obsoleto

Google afferma che il client viene scaricato da PyPI più di 73 milioni di volte al mese, ma che era rimasto in modalità di manutenzione ridotta per diversi anni. Invece di riprodurre ogni funzionalità del client Go di Kubernetes, il team afferma di concentrarsi sulle capacità necessarie agli sviluppatori e agli operatori Python, guidando le proprie priorità in base ai carichi di lavoro di IA e machine learning.

Fino a Kubernetes 1.35, il client Python generava circa 400.000 righe di codice API e dei modelli usando OpenAPI Generator v4.3.0 e i relativi template python-legacy. Quel generatore è stato deprecato nel 2020 e rimosso dal progetto upstream nel maggio 2022.

Il team sta lavorando alla migrazione a OpenAPI Generator v7.20.0 o versioni successive e a seguire le future release upstream. Secondo Google, l’aggiornamento previsto modernizzerebbe anche le annotazioni dei tipi e i metadati di packaging, oltre a consentire di contribuire ai template upstream con correzioni alle prestazioni e alla serializzazione.

Concorrenza e monitoraggio del cluster

La roadmap prevede il supporto nativo di asyncio nel client ufficiale. Finora, gli utenti che cercavano un’esecuzione asincrona si sono affidati a client della community o di terze parti, come kubernetes-asyncio, kr8s e lightkube.

Google afferma che il supporto nativo consentirà agli orchestratori, ai control plane dei modelli e ai notebook di effettuare chiamate concorrenti e non bloccanti all’API di Kubernetes. Un’altra aggiunta prevista è Shared Informers, un modello per mantenere una cache locale delle risorse del cluster basata sugli eventi.

L’implementazione proposta include la memorizzazione nella cache list-watch, la riconnessione automatica e gestori per gli eventi delle risorse. Google afferma che consentirebbe ai controller Python e ai gestori dei job di IA di monitorare lo stato del cluster e le risorse personalizzate con una frazione dell’uso di memoria e del carico sul server API.

Il team sta inoltre aggiungendo il supporto nativo ai canali WebSocket v5 per lo streaming di comandi remoti. Il lavoro segue la transizione di Kubernetes di operazioni come exec, attach e port-forward da SPDY a WebSocket.

Prestazioni nei cluster di grandi dimensioni

Il lavoro sulle prestazioni punta a migliorare l’elaborazione di grandi risposte JSON, incluse le liste di pod nei cluster di addestramento. Secondo il post, nei cluster di grandi dimensioni l’elenco di pod o nodi poteva richiedere 30 secondi o più in Python, a causa della ripetuta riconfigurazione dei modelli durante la deserializzazione.

Il livello legacy dei modelli crea e riconfigura ripetutamente oggetti di convalida dello schema durante l’elaborazione di queste risposte. Nell’ambito della migrazione del generatore, il team prevede di modificare l’inizializzazione dei modelli; secondo Google, l’obiettivo è ridurre il tempo necessario per deserializzare le query sui cluster di grandi dimensioni.

Il lavoro viene sviluppato apertamente e il team cerca feedback, casi d’uso e contributi. Indica agli sviluppatori i repository del client e della generazione del codice, oltre alle riunioni di triage del client Python di Kubernetes.