Aggiornamento di un pool di nodi gestiti

Per modificare le proprietà dei pool di nodi e dei nodi di lavoro dei cluster Kubernetes esistenti, effettuare le operazioni riportate di seguito.

1. Nella pagina della lista Cluster selezionare il nome del cluster che si desidera modificare. Se è necessaria assistenza per trovare la pagina della lista o il cluster, vedere Elenca cluster.
2. Selezionare la scheda Pool di nodi, quindi selezionare il nome del pool di nodi che si desidera modificare.

3. Utilizzare la scheda Dettagli della pagina Pool di nodi per visualizzare le informazioni sul pool di nodi, tra cui:

   • Stato del pool di nodi.
   • OCID del pool di nodi.
   • Tipo di nodi di lavoro nel pool di nodi (gestito o virtuale).
   • Configurazione attualmente utilizzata quando si avviano nuovi nodi di lavoro nel pool di nodi, tra cui:
     • la versione di Kubernetes da eseguire sui nodi di lavoro
     • la forma da utilizzare per i nodi di lavoro
     • l'immagine da utilizzare sui nodi di lavoro
   • Domini di disponibilità, domini di errore e subnet regionali diverse (consigliata) o subnet specifiche di AD che ospitano nodi di lavoro.

   Il tipo di nodi di lavoro nel pool di nodi (gestito o virtuale) determina le proprietà del pool di nodi e dei nodi di lavoro che è possibile modificare.

4. (facoltativo) Nel caso di un pool di nodi gestiti e di nodi gestiti, modificare le proprietà come indicato di seguito.

   1. Dal menu Azioni selezionare Modifica e specificare quanto segue.
      • Nome: nome diverso per il pool di nodi. Evitare di fornire informazioni riservate.

      • Versione: una versione diversa di Kubernetes da eseguire sui nuovi nodi di lavoro nel pool di nodi quando si esegue un upgrade in loco. La versione Kubernetes nei nodi di lavoro deve essere la stessa della versione dei nodi del piano di controllo oppure una versione precedente ancora compatibile (vedere Versioni Kubernetes e Kubernetes Engine (OKE)).

        Tenere presente che se si specifica un'immagine OKE per i nodi di lavoro, la versione Kubernetes selezionata qui deve essere uguale alla versione di Kubernetes nell'immagine OKE.

        Per avviare nuovi nodi di lavoro che eseguono la versione di Kubernetes specificata, 'eliminare' i nodi di lavoro esistenti nel pool di nodi (per impedire l'avvio di nuovi pod ed eliminare i pod esistenti) e quindi arrestare ciascuno dei nodi di lavoro esistenti a turno.

        Puoi anche specificare una versione diversa di Kubernetes da eseguire sui nuovi nodi di lavoro eseguendo un upgrade non in loco. Per ulteriori informazioni sull'upgrade dei nodi di lavoro, vedere Aggiornamento dei nodi gestiti a una versione Kubernetes più recente.

      • Conteggio nodi: un numero diverso di nodi nel pool di nodi. Vedere Ridimensionamento dei pool di nodi.

      • Opzioni avanzate: accettare i valori esistenti per le opzioni avanzate del pool di nodi oppure selezionare Opzioni avanzate e specificare le alternative come indicato di seguito.

        • Cordone e scarico: modificare quando e come collegare e scollegare i nodi di lavoro prima di terminarli.

          • Periodo di tolleranza rimozione (min): il periodo di tempo necessario per consentire il cordone e il drenaggio dei nodi di lavoro prima di terminarli. Accettare il valore predefinito (60 minuti, ovvero il massimo) oppure specificare un'alternativa. Ad esempio, quando si esegue lo scale down di un pool di nodi o ne si modifica la configurazione di posizionamento, è possibile consentire 30 minuti per collegare i nodi di lavoro ed eliminarli dai carichi di lavoro. Per terminare immediatamente i nodi di lavoro, senza collegarli e svuotarli, specificare 0 minuti.
          • Forza interruzione dopo il periodo di tolleranza: quando si sostituiscono i nodi o si eliminano i nodi nel pool di nodi, specificare se terminare i nodi di lavoro alla fine del periodo di tolleranza di rimozione, anche se non sono stati collegati correttamente e scaricati. Per impostazione predefinita, questa opzione non è selezionata.
          • Azione Forza dopo il periodo di tolleranza: quando si eseguono task di manutenzione sui nodi di lavoro (ad esempio, il riavvio di un nodo e la sostituzione del volume di avvio di un nodo), se eseguire l'azione alla fine del periodo di tolleranza di rimozione, anche se il nodo di lavoro non è stato collegato e scaricato correttamente. Per impostazione predefinita, questa opzione non è selezionata.

          I pool di nodi contenenti nodi di lavoro che non possono essere chiusi o terminati entro il periodo di tolleranza della rimozione hanno lo stato Richiede attenzione. Lo stato della richiesta di lavoro che ha avviato l'operazione di cessazione è impostato su Non riuscito e l'operazione di cessazione viene annullata. Per ulteriori informazioni, vedere Monitoraggio dei cluster.

          Per ulteriori informazioni, vedere Registrazione e rimozione dei nodi gestiti prima dello spegnimento o della cessazione.

        • Script di inizializzazione: (facoltativo) uno script diverso per l'inizializzazione del cloud da eseguire sulle istanze che ospitano nodi di lavoro quando l'istanza viene avviata per la prima volta. Lo script specificato deve essere scritto in uno dei formati supportati da cloud-init (ad esempio, cloud-config) e deve essere un tipo di file supportato (ad esempio, .yaml). Specificare lo script come indicato di seguito.
          • Scegliere lo script di inizializzazione cloud: selezionare un file contenente lo script di inizializzazione cloud oppure trascinare il file nella casella.
          • Incolla script cloud-init: copia il contenuto di uno script cloud-init e incollalo nella casella.

          Se in precedenza non sono stati scritti script di inizializzazione cloud per l'inizializzazione dei nodi di lavoro nei cluster creati da Kubernetes Engine, potrebbe essere utile selezionare Scarica per scaricare un modello di script di inizializzazione cloud. Il file scaricato contiene la logica predefinita fornita da Kubernetes Engine. È possibile aggiungere la propria logica personalizzata prima o dopo la logica predefinita, ma non modificarla. Per esempi, vedere Usi di esempio per script di inizializzazione cloud personalizzati.

        • Etichette Kubernetes: (facoltativo) una o più etichette (oltre a un'etichetta predefinita) da aggiungere ai nodi di lavoro nel pool di nodi per abilitare la definizione dei destinatari dei carichi di lavoro in pool di nodi specifici. Ad esempio, per escludere tutti i nodi in un pool di nodi dalla lista di server backend in un set backend del load balancer, specificare node.kubernetes.io/exclude-from-external-load-balancers=true (vedere node.kubernetes.io/exclude-from-external-load-balancers).
        • Aggiungi una chiave SSH: (facoltativo) una parte diversa della chiave pubblica della coppia di chiavi che si desidera utilizzare per l'accesso SSH ai nodi nel pool di nodi. La chiave pubblica viene installata su tutti i nodi di lavoro nel cluster. Tenere presente che se non si specifica una chiave SSH pubblica, Kubernetes Engine ne fornirà una. Tuttavia, poiché non si dispone della chiave privata corrispondente, non si avrà accesso SSH ai nodi di lavoro. Tenere presente che non è possibile utilizzare SSH per accedere direttamente a qualsiasi nodo di lavoro nelle subnet private (vedere Connessione ai nodi gestiti nelle subnet private mediante SSH).
      • Configurazione posizionamento dei nodi:
        • Dominio di disponibilità: dominio di disponibilità in cui posizionare i nodi di lavoro.
        • Compartimento subnet nodo lavoratore: il compartimento in cui risiede la subnet nodo di lavoro.
        • Subnet del nodo del lavoro: subnet regionale (consigliata) o specifica di AD configurata per i nodi di lavoro host. Se sono state specificate subnet del load balancer, le subnet dei nodi di lavoro devono essere diverse. Le subnet specificate possono essere private (consigliate) o pubbliche. Vedere Configurazione subnet.
        • Domini di errore: (facoltativo) uno o più domini di errore nel dominio di disponibilità in cui posizionare i nodi di lavoro.

        Facoltativamente, selezionare Opzioni avanzate per specificare un tipo di capacità da utilizzare (vedere Gestione dei tipi di capacità dei nodi di lavoro). Se si specifica una riserva capacità, tenere presente che la forma del nodo, il dominio di disponibilità e il dominio di errore nella configurazione di posizionamento del pool di nodi gestiti devono corrispondere rispettivamente al tipo di istanza, al dominio di disponibilità e al dominio di errore della riserva capacità. Vedere Utilizzo delle riserve capacità per eseguire il provisioning dei nodi gestiti.

        Facoltativamente, selezionare Aggiungi riga per selezionare domini e subnet aggiuntivi in cui posizionare i nodi di lavoro.

        Quando vengono creati, i nodi di lavoro vengono distribuiti nel modo più uniforme possibile tra i domini di disponibilità e i domini di errore selezionati. Se non si seleziona alcun dominio di errore per un determinato dominio di disponibilità, i nodi di lavoro vengono distribuiti nel modo più uniforme possibile in tutti i domini di errore in tale dominio di disponibilità.

      • Forma nodo: una forma diversa da utilizzare per i nodi di lavoro nel pool di nodi. La forma determina il numero di CPU e la quantità di memoria allocata a ciascun nodo. Per modificare la forma, selezionare Modifica forma.

        Vengono visualizzate solo le forme disponibili nella tenancy supportate da Kubernetes Engine.

        Se si seleziona una forma flessibile, è possibile specificare in modo esplicito il numero di CPU e la quantità di memoria.

        Vedere Immagini supportate (incluse immagini personalizzate) e forme per i nodi di lavoro.

      • Immagine: un'immagine diversa da utilizzare sui nodi di lavoro nel pool di nodi. Un'immagine è un modello di unità fissa virtuale che determina il sistema operativo e altro software per il nodo.

        Per modificare l'immagine, selezionare Modifica immagine. Nella finestra Sfoglia tutte le immagini, scegliere un'origine immagine e selezionare un'immagine come indicato di seguito.

        • Immagini del nodo di lavoro OKE: consigliato. Fornito da Oracle e costruito sulle immagini della piattaforma. Le immagini OKE sono ottimizzate per fungere da immagini di base per i nodi di lavoro, con tutte le configurazioni necessarie e il software richiesto. Selezionare un'immagine OKE se si desidera ridurre al minimo il tempo necessario per eseguire il provisioning dei nodi di lavoro in runtime rispetto alle immagini della piattaforma e alle immagini personalizzate.

          I nomi immagine OKE includono il numero di versione della versione Kubernetes in essi contenuta. Tenere presente che se si specifica una versione Kubernetes per il pool di nodi, l'immagine OKE selezionata qui deve avere lo stesso numero di versione della versione Kubernetes del pool di nodi.

        • Immagini della piattaforma: fornite da Oracle e contengono solo un sistema operativo Oracle Linux. Selezionare un'immagine della piattaforma se si desidera che Kubernetes Engine scarichi, installi e configuri il software richiesto quando l'istanza di computazione che ospita un nodo di lavoro viene avviata per la prima volta.

        Vedere Immagini supportate (incluse immagini personalizzate) e forme per i nodi di lavoro.

      • Usa regole di sicurezza nel gruppo di sicurezza di rete (NSG): controlla l'accesso al pool di nodi utilizzando le regole di sicurezza definite per uno o più gruppi di sicurezza di rete (NSG) specificati (fino a un massimo di cinque). È possibile utilizzare le regole di sicurezza definite per i gruppi NSG anziché quelle definite per le liste di sicurezza (si consiglia di utilizzare i gruppi NSG). Per ulteriori informazioni sulle regole di sicurezza da specificare per il gruppo NSG, vedere Regole di sicurezza per i nodi di lavoro.

      • Volume di avvio: modificare le opzioni di dimensione e cifratura per il volume di avvio del nodo di lavoro.

        • Per specificare una dimensione personalizzata per il volume d'avvio, selezionare Specificare una dimensione personalizzata del volume d'avvio e immettere una dimensione personalizzata da 50 GB a 32 TB. La dimensione specificata deve essere maggiore della dimensione predefinita del volume di avvio per l'immagine selezionata. Per ulteriori informazioni, vedere Dimensioni personalizzate dei volumi di avvio.

          Tenere presente che se si aumenta la dimensione del volume di avvio, è inoltre necessario estendere la partizione per il volume di avvio (la partizione radice) per sfruttare la dimensione più grande. Vedere Estensione della partizione per un volume di boot. Le immagini della piattaforma Oracle Linux includono il pacchetto oci-utils. È possibile utilizzare il comando oci-growfs di tale pacchetto in uno script personalizzato di inizializzazione cloud per estendere la partizione root e quindi ingrandire il file system. Per ulteriori informazioni, vedere Estensione della partizione root dei nodi di lavoro.

        • Per le istanze VM, è possibile selezionare facoltativamente Usa cifratura in transito. Per le istanze Bare Metal che supportano la cifratura in transito, questa è abilitata per impostazione predefinita e non è configurabile. Per ulteriori informazioni sulla cifratura in transito, vedere Cifratura dei volumi a blocchi. Se si utilizza la propria chiave di cifratura del servizio Vault per il volume di avvio, questa chiave viene utilizzata anche per la cifratura in transito. In caso contrario, viene utilizzata la chiave di cifratura fornita da Oracle.
        • I volumi di avvio sono cifrati per impostazione predefinita, ma è possibile facoltativamente utilizzare la propria chiave di cifratura del servizio Vault per cifrare i dati in questo volume. Per utilizzare il servizio vault per le esigenze di cifratura, selezionare Cifra questo volume con una chiave gestita dall'utente. Selezionare il compartimento vault e il vault contenenti la chiave di cifratura master che si desidera utilizzare, quindi selezionare il compartimento della chiave di cifratura master e la chiave di cifratura master. Se si abilita questa opzione, questa chiave viene utilizzata sia per la cifratura dei dati in archivio che per la cifratura in transito.
          Importante
          
          Il servizio per volumi a blocchi non supporta la cifratura dei volumi con chiavi cifrate utilizzando l'algoritmo Rivest-Shamir-Adleman (RSA). Quando si utilizzano chiavi proprie, è necessario utilizzare le chiavi cifrate utilizzando l'algoritmo AES (Advanced Encryption Standard). Ciò si applica ai volumi a blocchi e ai volumi di avvio.

        Tenere presente che per utilizzare la propria chiave di cifratura del servizio Vault per cifrare i dati, un criterio IAM deve concedere l'accesso alla chiave di cifratura del servizio. Vedere Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/or File Systems.

      • Comunicazione pod: quando il tipo di rete del cluster è Networking pod nativo per VCN, modificare il modo in cui i pod nel pool di nodi comunicano tra loro utilizzando una subnet pod:
        • Compartimento della subnet: il compartimento in cui risiede la subnet del pod.
        • Subnet: subnet regionale configurata per ospitare i pod. La subnet pod specificata deve essere privata. In alcune situazioni, la subnet del nodo di lavoro e la subnet del pod possono essere la stessa subnet (nel qual caso, Oracle consiglia di definire regole di sicurezza nei gruppi di sicurezza di rete anziché nelle liste di sicurezza). Vedere Configurazione subnet.
        • Usa regole di sicurezza nel gruppo di sicurezza di rete (NSG): controlla l'accesso alla subnet pod utilizzando le regole di sicurezza definite per uno o più gruppi di sicurezza di rete (NSG) specificati (fino a un massimo di cinque). È possibile utilizzare le regole di sicurezza definite per i gruppi NSG anziché quelle definite per le liste di sicurezza (si consiglia di utilizzare i gruppi NSG). Per ulteriori informazioni sulle regole di sicurezza da specificare per il gruppo NSG, vedere Regole di sicurezza per nodi di lavoro e pod.

        Facoltativamente, selezionare Opzioni avanzate per specificare il numero massimo di pod che si desidera eseguire su un singolo nodo di lavoro in un pool di nodi, fino a un limite di 110. Il limite di 110 viene imposto da Kubernetes. Se desideri più di 31 pod su un singolo nodo di lavoro, la forma specificata per il pool di nodi deve supportare tre o più VNIC (una VNIC per la connessione alla subnet del nodo di lavoro e almeno due VNIC per la connessione alla subnet del pod). Vedere Numero massimo di VNIC e pod supportati da forme diverse.

        Per ulteriori informazioni sulla comunicazione con i pod, vedere Pod Networking.

   2. Selezionare Aggiorna per salvare le proprietà aggiornate.

5. (facoltativo) Nel caso di un pool di nodi virtuali e di nodi virtuali, modificare le proprietà come indicato di seguito.

   1. Dal menu Azioni selezionare Modifica e specificare quanto segue.
      • Nome: nome diverso per il pool di nodi. Evitare di fornire informazioni riservate.
      • Conteggio dei nodi: un numero diverso di nodi virtuali da creare nel pool di nodi virtuali, posizionati nei domini di disponibilità selezionati e nella subnet regionale (consigliata) o nella subnet specifica di AD specificata per ogni dominio di disponibilità. Vedere Ridimensionamento dei pool di nodi.
      • Configurazione posizionamento dei nodi:
        • Dominio di disponibilità: dominio di disponibilità in cui posizionare i nodi virtuali.
        • Domini di errore: (facoltativo) uno o più domini di errore nel dominio di disponibilità in cui posizionare i nodi virtuali.

        Facoltativamente, selezionare Aggiungi riga per selezionare altri domini in cui posizionare i nodi virtuali.

        Quando vengono creati, i nodi virtuali vengono distribuiti nel modo più uniforme possibile tra i domini di disponibilità e i domini di errore selezionati. Se non si seleziona alcun dominio di errore per un determinato dominio di disponibilità, i nodi virtuali vengono distribuiti nel modo più uniforme possibile in tutti i domini di errore in tale dominio di disponibilità.

      • Comunicazione nodo virtuale:
        • Compartimento della subnet: il compartimento in cui risiede la subnet del nodo virtuale.
        • Subnet: una subnet regionale diversa (consigliata) o una subnet specifica di AD configurata per ospitare i nodi virtuali. Se sono state specificate subnet del load balancer, le subnet dei nodi virtuali devono essere diverse. Le subnet specificate possono essere private (consigliate) o pubbliche e possono essere regionali (consigliate) o specifiche di AD. Si consiglia che la subnet pod e la subnet del nodo virtuale siano la stessa subnet (nel qual caso, la subnet del nodo virtuale deve essere privata). Per ulteriori informazioni, vedere Configurazione della subnet.
        • Usa regole di sicurezza nel gruppo di sicurezza di rete (NSG): controlla l'accesso alla subnet del nodo virtuale utilizzando le regole di sicurezza definite per uno o più gruppi di sicurezza di rete (NSG) specificati (fino a un massimo di cinque). È possibile utilizzare le regole di sicurezza definite per i gruppi NSG anziché quelle definite per le liste di sicurezza (si consiglia di utilizzare i gruppi NSG). Per ulteriori informazioni sulle regole di sicurezza da specificare per il gruppo NSG, vedere Regole di sicurezza per nodi di lavoro e pod.
      • Comunicazione pod:
        • Compartimento della subnet: il compartimento in cui risiede la subnet del pod.
        • Subnet: subnet regionale diversa configurata per i pod host. La subnet pod specificata per i nodi virtuali deve essere privata. È consigliabile che la subnet pod e la subnet del nodo virtuale siano la stessa subnet (nel qual caso, Oracle consiglia di definire regole di sicurezza nei gruppi di sicurezza di rete anziché nelle liste di sicurezza). Per ulteriori informazioni, vedere Configurazione della subnet.
        • Usa regole di sicurezza nel gruppo di sicurezza di rete (NSG): controlla l'accesso alla subnet pod utilizzando le regole di sicurezza definite per uno o più gruppi di sicurezza di rete (NSG) specificati (fino a un massimo di cinque). È possibile utilizzare le regole di sicurezza definite per i gruppi NSG anziché quelle definite per le liste di sicurezza (si consiglia di utilizzare i gruppi NSG). Per ulteriori informazioni sulle regole di sicurezza da specificare per il gruppo NSG, vedere Regole di sicurezza per nodi di lavoro e pod.

        Per ulteriori informazioni sulla comunicazione con i pod, vedere Pod Networking.

      • Etichette Kubernetes: (facoltativo) una o più etichette (oltre a un'etichetta predefinita) da aggiungere ai nodi virtuali nel pool di nodi virtuali per abilitare la definizione dei destinatari dei carichi di lavoro in pool di nodi specifici. Per ulteriori informazioni, vedere Assegnazione dei pod ai nodi nella documentazione di Kubernetes.
      • Taints di Kubernetes: (facoltativo) uno o più taaints da aggiungere ai nodi virtuali nel pool di nodi virtuali. I tenute consentono ai nodi virtuali di respingere i pod e quindi di assicurarsi che i pod non vengano eseguiti sui nodi virtuali in un determinato pool di nodi virtuali. È possibile applicare i filtri solo ai nodi virtuali. Per ulteriori informazioni, vedere Assegnazione dei pod ai nodi nella documentazione di Kubernetes.
   2. Selezionare Aggiorna per salvare le proprietà aggiornate.
6. Per i pool di nodi gestiti, utilizzare la scheda Etichette Kubernetes per visualizzare le etichette applicate ai nodi gestiti. Per i pool di nodi virtuali, utilizzare la scheda Etichette e taint Kubernetes per visualizzare sia le etichette che i taint applicati ai nodi virtuali.
7. Utilizzare la scheda Nodi per visualizzare informazioni su nodi di lavoro specifici in un pool di nodi gestiti. Facoltativamente, modificare i dettagli di configurazione di un nodo di lavoro specifico selezionando il nome del nodo di lavoro.
8. Utilizzare la scheda Nodi virtuali per visualizzare informazioni su nodi di lavoro specifici in un pool di nodi virtuali.
9. Utilizzare la scheda Monitoraggio per monitorare lo stato, la capacità e le prestazioni di un pool di nodi gestiti. Per ulteriori informazioni, vedere Metriche OKE (Kubernetes Engine).
10. Utilizzare la scheda Richieste di lavoro.
    • Recupera i dettagli di una richiesta di lavoro specifica per la risorsa del pool di nodi.
    • Elencare le richieste di lavoro per la risorsa del pool di nodi.

    Per ulteriori informazioni, vedere Visualizzazione delle richieste di lavoro.

11. Utilizzare la scheda Tag per aggiungere o modificare le tag applicate al pool di nodi (e, nel caso di un pool di nodi gestiti, le tag applicate alle istanze di computazione che ospitano nodi gestiti nel pool di nodi). L'applicazione di tag ti consente di raggruppare risorse eterogenee tra compartimenti e ti consente anche di annotare le risorse con i tuoi metadati. Vedere Applicazione di tag alle risorse correlate ai cluster Kubernetes.