1.36 informazioni sulla versione e operazioni di aggiornamento

Consulta le informazioni relative alla versione 1.36 del sito IBM Cloud® Kubernetes Service. Per ulteriori informazioni sulla versione 1.36 del progetto " Kubernetes ", consultare il registro delle modifiche all'indirizzo Kubernetes.

Kubernetes versione 1.36

IBM Cloud Kubernetes Service È un prodotto certificato " Kubernetes " per la versione 1.36 nell'ambito del programma di certificazione di conformità del software " Kubernetes " della CNCF. Kubernetes® è un marchio registrato della Fondazione “ Linux ” negli Stati Uniti e in altri paesi, ed è utilizzato in base a una licenza concessa dalla Fondazione “ Linux ”.

Calendario delle uscite

La tabella seguente riporta il calendario previsto per il rilascio della versione 1.36 di IBM Cloud® Kubernetes Service. È possibile utilizzare queste informazioni a fini di pianificazione, ad esempio per stimare il periodo approssimativo in cui la versione potrebbe non essere più supportata.

Le date contrassegnate con un simbolo che sembra un pugnale (†) non sono definitive e sono soggette a variazioni.

Calendario di rilascio della versione
Versione	Supportata?	Data di rilascio	data di cessazione del supporto
1.36	Sì	26 giugno 2026	1° agosto 2027 `†`

Preparazione dell'aggiornamento

Per un elenco completo delle modifiche che potrebbero influire sulle app distribuite in seguito all'aggiornamento del cluster, consultare il log delle modifiche della community all'indirizzo Kubernetes e il log delle modifiche di versione all'indirizzo IBM per la versione 1.36. È inoltre possibile consultare le utili avvertenze contenute nel documento “ Kubernetes ”.

Kubernetes Server API e tunnel Konnectivity disponibili sulla porta 443

Il server API di Kubernetes e il tunnel Konnectivity sono ora accessibili tramite la porta standard 443 di HTTPS, anziché tramite una porta di nodo assegnata dinamicamente (ad esempio, una porta nell'intervallo 20000–32767 ). Il traffico viene indirizzato al servizio backend corretto tramite il routing basato sul nome host; ecco perché ogni funzione dispone di un nome host dedicato, anche se tutti i servizi condividono la porta 443. Questa modifica semplifica la connessione al cluster da ambienti di rete con restrizioni, poiché non è più necessario autorizzare una porta non standard attraverso i firewall e i controlli di uscita. Il cluster mette a disposizione due nomi host appositamente creati tramite i propri endpoint di servizio privati e pubblici:

<cluster>.api.<region-domain> — l'endpoint del server API di Kubernetes
<cluster>.tunnel.<region-domain> — l'endpoint del tunnel Konnectivity utilizzato per la comunicazione tra il piano di controllo e il nodo di lavoro

Questa funzionalità è disponibile a partire dalla versione 1.36 di IKS nelle seguenti regioni: Montreal (ca-mon), Chennai (in-che) e Mumbai (in-mum). Il supporto per altre regioni sarà disponibile a breve.

Se hai aggiornato un cluster che utilizza l'endpoint di servizio pubblico, un file kubeconfig che fa ancora riferimento a tale endpoint ( URL ) continua a utilizzare la vecchia porta, causando il fallimento dei comandi kubectl a causa di timeout di connessione. Per evitare che ciò accada, scarica un nuovo file kubeconfig eseguendo il comando ibmcloud ks cluster config oppure aggiorna manualmente la porta nel tuo file kubeconfig esistente impostandola su 443.

Nuovi cluster: non è richiesta alcuna azione. I nuovi cluster vengono creati con endpoint sulla porta 443 e il file kubeconfig scaricato utilizza già la porta 443.
Cluster aggiornati che utilizzano esclusivamente l'endpoint del servizio privato: non è richiesta alcuna azione immediata. Le connessioni esistenti che puntano al precedente NodePort continuano a funzionare anche dopo l'aggiornamento. Il nuovo file kubeconfig che hai scaricato utilizza l'endpoint sulla porta 443.
Regole di rete personalizzate: aggiornare tutte le regole del firewall, dei gruppi di sicurezza o delle liste di autorizzazione in uscita che fanno esplicito riferimento alla vecchia porta del piano di controllo con numero elevato, in modo da consentire invece il traffico in uscita HTTPS sulla porta 443. È possibile rimuovere eventuali regole che hanno fissato la porta con il numero più alto precedente.
Elenchi di indirizzi consentiti basati su IP: i record DNS degli endpoint del servizio pubblico ora puntano agli indirizzi IP front-end di Akamai IP Protect (IPP) anziché ai precedenti indirizzi IP del bilanciatore di carico (NLB). Se il firewall o le regole di uscita consentono il traffico verso il cluster in base all'indirizzo IP di destinazione, aggiornarle in modo da utilizzare gli attuali intervalli di indirizzi IP IPP di Akamai.

L'accesso anonimo al server API di Kubernetes è ora limitato

L'accesso anonimo al server API di Kubernetes è ora limitato agli endpoint di controllo dello stato (/healthz, /readyz, /livez, /livez/ping). Tutti gli altri endpoint richiedono l'autenticazione (ad esempio, /version). Ciò riduce il rischio derivante da configurazioni errate accidentali del modello RBAC che concedono autorizzazioni a system:anonymous o system:unauthenticated.

Kubernetes La dashboard è obsoleta

La dashboard open source " Kubernetes " è stata dismessa e archiviata. La dashboard " Kubernetes " non viene più installata sui cluster appena creati e viene rimossa dai cluster con versioni precedenti quando si esegue l'aggiornamento a " 1.36 ". L'estensione Headlamp è disponibile come sostituto dell'interfaccia utente di Kubernetes.

NVIDIA I driver della GPU non vengono più installati automaticamente

A partire dalla versione Kubernetes 1.36, IBM Cloud Kubernetes Service non installa più automaticamente i driver GPU NVIDIA sui nodi di lavoro dotati di GPU. Per eseguire i carichi di lavoro sulla GPU, è necessario installare e gestire autonomamente i driver della GPU. Per ulteriori informazioni, consultare la sezione " Migrazione ai driver GPU autogestiti ".

L'autoscaler del cluster non supporta ancora la versione 1.36. Non aggiornare il cluster alla versione 1.36 se è installato l'autoscaler.

Aggiorna prima del master

Esamina le seguenti modifiche che devi apportare prima di aggiornare il master di Kubernetes.

Modifiche da apportare prima di aggiornare il master all' Kubernetes 1.36
Immettere	Descrizione
Rimosso: plugin per i volumi " Portworx " integrato nel sistema	Il plugin di volume " Portworx " integrato nel codice è stato rimosso in Kubernetes 1.36, completando così la migrazione al driver CSI Portworx. Sono state inoltre rimosse le funzionalità “ `CSIMigrationPortworx` ” (GA e bloccata da 1.33 ) e “alpha `InTreePluginPortworxUnregister` ”, e tutte le operazioni sui volumi Portworx presenti nel tree sono state reindirizzate a CSI. Prima di eseguire l'aggiornamento, assicurati che il driver CSI di Portworx sia installato e che le risorse `StorageClass`, `PersistentVolume` e `PersistentVolumeClaim` facciano riferimento al driver CSI. I cluster che continuano a utilizzare il plugin in-tree non potranno più accedere ai volumi " Portworx " dopo l'aggiornamento.
Modificato: convalida più rigorosa degli indirizzi IP e dei range CIDR	La funzione " `StrictIPCIDRValidation` " è abilitata per impostazione predefinita nel server API. I campi API che contengono valori IP o CIDR non accettano più indirizzi con zeri iniziali superflui (ad esempio, `010.000.000.005` invece di `10.0.0.5`) né valori CIDR con bit di host ambigui (ad esempio, `192.168.0.5/24` invece di `192.168.0.0/24` o `192.168.0.5/32`). Verificate i vostri manifest e gli strumenti relativi a risorse quali `Service`, `NetworkPolicy` e `EndpointSlice`, e correggete eventuali valori IP o CIDR non canonici prima di procedere all'aggiornamento. Una volta aggiornato il master, le richieste che creano o aggiornano oggetti con valori non validi vengono respinte.
Modificato: rinominate le metriche del piano di controllo	La metrica " `volume_operation_total_errors` " (kube-controller-manager) è stata rinominata " `volume_operation_errors_total`", mentre la metrica " `etcd_bookmark_counts` " è stata rinominata " `etcd_bookmark_total`". Se utilizzi dashboard di monitoraggio personalizzate o regole di avviso che fanno riferimento ai vecchi nomi delle metriche, aggiornale con i nuovi nomi in modo che il monitoraggio continui a funzionare dopo l'aggiornamento del piano di controllo.
Rimosso: plugin " `git-repo` " per la gestione del volume	Il plugin " `git-repo` " è disabilitato per impostazione predefinita e non è possibile riattivarlo; l'opzione " `GitRepoVolumeDriver` " non ha più alcun effetto. Questo tipo di volume non è più supportato in IBM Cloud Kubernetes Service a partire dalla versione 1.33. Se alcuni carichi di lavoro utilizzano ancora un volume `gitRepo`, migrarli su un volume `emptyDir` popolato da un container `init` che clona il repository utilizzando `git`. Per ulteriori informazioni, consultare la sezione " Rimozione del driver del volume ' `gitRepo` ' dall'albero".

Aggiorna dopo il master

Esamina le seguenti modifiche che dovrai apportare dopo aver aggiornato il master di Kubernetes.

Modifiche da apportare dopo l'aggiornamento del master a Kubernetes 1.36
Immettere	Descrizione
Obsoleto: Servizio `.spec.externalIPs`	Il campo " `.spec.externalIPs` " delle risorse `Service` è deprecato e il server API ora restituisce un avviso di deprecazione quando il campo viene impostato. Si prevede di smettere di utilizzare `externalIPs` e di instradare il traffico esterno tramite un servizio `LoadBalancer` o un Ingress. Per ulteriori informazioni, consultare la sezione " Indirizzi IP esterni".
Modificato: profilo predefinito " `kubectl debug` "	Il profilo predefinito per `kubectl debug` cambia da `legacy` a `general`. Se si dispone di script o runbook che dipendono dal comportamento del profilo “ `legacy` ”, specificare esplicitamente l’opzione “ `--profile=legacy` ”. Il profilo “ `legacy` ” sarà rimosso nella versione Kubernetes 1.39. Per ulteriori informazioni, consultare la sezione " Debug dei pod in esecuzione ".
Modificato: ordinamento degli eventi dell'informatore client-go (`AtomicFIFO`)	La funzionalità "client-go `AtomicFIFO` " è abilitata per impostazione predefinita. I magazzini degli informer vengono ora aggiornati completamente a una versione coerente delle risorse prima che vengano chiamati gli handler per singolo elemento `OnAdd`, `OnUpdate` e `OnDelete` ; inoltre, l'elaborazione di risincronizzazione degli informer subisce lievi modifiche, che possono determinare differenze osservabili nei tempi di invocazione degli handler. Testare i controller e gli operatori personalizzati che incorporano client-go. Se si riscontrano regressioni, è possibile impostare temporaneamente il feature gate “client-go” di `AtomicFIFO` su “ `false` ” nel proprio file binario del controller, in attesa di apportare le modifiche necessarie.
Modificato: convalida numerica più rigorosa per CustomResourceDefinition	CustomResourceDefinition La convalida (CRD) ora applica rigorosamente gli intervalli dei formati numerici `int32`, `int64`, `float` e `double` quando questi sono definiti in uno schema. Gli oggetti esistenti che contengono già valori fuori intervallo vengono mantenuti grazie al meccanismo di convalida a scatto, ma i valori nuovi o aggiornati devono rientrare nell'intervallo. Verifica le risorse personalizzate che utilizzano questi formati numerici.
Obsoleto: campo "allowlist" del plugin Credential	Nell'elenco delle eccezioni del plugin per le credenziali client, il campo " `AllowlistEntry.Name` " è stato rinominato " `AllowlistEntry.Command`". Se si configura un elenco di plugin per le credenziali autorizzati (ad esempio, tramite `kuberc`), aggiornare la configurazione in modo da utilizzare il nuovo nome del campo.
Obsoleto: accesso diretto a `metav1.FieldsV1.Raw`	L'accesso diretto al campo Raw di metav1.FieldsV1 è deprecato. Il codice che crea o legge i campi gestiti ( `FieldsV1` ) (ad esempio, controller o strumenti che ispezionano i campi gestiti) dovrebbe essere migrato ai nuovi metodi di accesso `NewFieldsV1(string)`, `GetRawBytes()`, `GetRawString()` e `SetRawBytes()`.
Azione richiesta: Scheduler personalizzato PreBind plugin	Il framework dello scheduler ora supporta l'esecuzione in parallelo dei plugin PreBind. Se gestisci plugin personalizzati per lo scheduler, aggiornali in modo che restituiscano un PreBindPreFlightResult dal metodo PreBindPreFlight ; restituendo nil si mantiene il comportamento sequenziale esistente, mentre i plugin attivano l'esecuzione parallela restituendo AllowParallel: true``. Questa operazione si applica solo ai cluster che utilizzano plugin di scheduler personalizzati.
Azione richiesta: RBAC granulare per i driver DRA	Quando la funzionalità " `DRAResourceClaimGranularStatusAuthorization` " è abilitata (versione beta su 1.36 ), i driver e i controller della Dynamic Resource Allocation (DRA) richiedono autorizzazioni RBAC granulari per aggiornare gli stati dell' `ResourceClaim`. Gli scheduler e i controller richiedono `update` o `patch` su `resourceclaims/binding`, mentre i driver DRA richiedono `associated-node:update` o `arbitrary-node:update` su `resourceclaims/driver`, in base alle restrizioni previste dal loro specifico `resourceNames`. Se utilizzi i driver DRA, aggiorna il loro RBAC. Questa operazione si applica solo ai cluster che utilizzano DRA.