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. Aprire il menu di navigazione e selezionare Developer Services. In Container e artifact, selezionare Cluster Kubernetes (OKE).
2. Selezionare il compartimento che contiene il cluster.
3. Nella pagina Elenco cluster fare clic sul nome del cluster che si desidera modificare.
4. Nella pagina Dettagli cluster, in Risorse, fare clic su Pool di nodi.
5. Fare clic sul nome del pool di nodi da modificare.

6. Utilizzare la scheda Dettagli pool di nodi per visualizzare 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.

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

   1. Fare clic su Modifica e specificare quanto segue.
      • Nome: un nome diverso per il pool di nodi. Evitare di inserire informazioni riservate.

      • Versione: una versione diversa di Kubernetes da eseguire sui nuovi nodi di lavoro nel pool di nodi durante l'esecuzione di un upgrade in loco. La versione Kubernetes sui nodi di lavoro deve essere la stessa 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 Upgrading Managed Nodes to a Newer Kubernetes Version.

      • Conteggio nodi: un numero diverso di nodi nel pool di nodi. Vedere Scalatura dei pool di nodi.
      • Configurazione posizionamento nodo:
        • Dominio di disponibilità: dominio di disponibilità in cui inserire i nodi di lavoro.
        • Subnet dei nodi di lavoro: subnet regionale (consigliata) o subnet specifica di AD configurata per ospitare i nodi di lavoro. 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 della subnet.
        • Domini di errore: (facoltativo) uno o più domini di errore nel dominio di disponibilità in cui posizionare i nodi di lavoro.

        Facoltativamente, fare clic su Mostra opzioni avanzate per specificare un tipo di capacità da utilizzare (vedere Gestione dei tipi di capacità dei nodi di lavoro). Se si specifica un'assegnazione 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 dell'assegnazione capacità. Vedere Utilizzo delle assegnazioni capacità per il provisioning dei nodi gestiti.

        Facoltativamente, fare clic su Un'altra 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: 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.

        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 un altro software per il nodo.

        Per modificare l'immagine, fare clic su 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 basato su 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 necessario. Selezionare un'immagine OKE se si desidera ridurre al minimo il tempo necessario per eseguire il provisioning dei nodi di lavoro in fase di esecuzione rispetto alle immagini della piattaforma e delle 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 contenenti 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 boot: modificare la dimensione e le opzioni di cifratura per il volume di boot del nodo di lavoro.

        • Per specificare una dimensione personalizzata per il volume di avvio, selezionare la casella di controllo Specificare una dimensione del volume di avvio personalizzata. Quindi, 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 dei volumi di avvio personalizzati.

          Tenere presente che se si aumentano le dimensioni del volume di avvio, è necessario estendere anche la partizione per il volume di avvio (la partizione radice) per sfruttare le dimensioni maggiori. Vedere Estensione della partizione per un volume di avvio. Le immagini della piattaforma Oracle Linux includono il pacchetto oci-utils. È possibile utilizzare il comando oci-growfs di tale pacchetto in uno script cloud-init personalizzato per estendere la partizione radice e quindi far crescere il file system. Per ulteriori informazioni, vedere Estensione della partizione radice dei nodi di lavoro.

        • Per le istanze VM, è possibile selezionare facoltativamente la casella di controllo Usa cifratura in transito. Per le istanze bare metal che supportano la cifratura in transito, è abilitata per impostazione predefinita e non è configurabile. Per ulteriori informazioni sulla cifratura in transito, vedere Cifratura del volume 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 utilizzare facoltativamente 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 la casella di controllo Cifrare questo volume con una chiave gestita dall'utente. Selezionare il compartimento e il vault contenenti la chiave di cifratura master che si desidera utilizzare, quindi selezionare il compartimento e la chiave di cifratura master. Se si abilita questa opzione, la chiave verrà 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 è rete pod nativa VCN, modificare il modo in cui i pod nel pool di nodi comunicano tra loro utilizzando una subnet pod:
        • Subnet: subnet regionale configurata per ospitare i pod. La subnet pod specificata deve essere privata. In alcuni casi, la subnet del nodo di lavoro e la subnet del pod possono essere la stessa subnet (nel qual caso, Oracle consiglia di definire le regole di sicurezza nei gruppi di sicurezza di rete anziché negli elenchi di sicurezza). Vedere Configurazione della subnet.
        • Gruppo di sicurezza di rete: 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 e pod di lavoratori.

        Facoltativamente, fare clic su Mostra 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 è imposto da Kubernetes. Se si desidera disporre di 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 connettersi alla subnet del nodo di lavoro e almeno due VNIC per connettersi alla subnet del pod). Vedere Maximum number of VNICs and Pods Supported by Different Shapes.

        Per ulteriori informazioni sulla comunicazione pod, vedere Pod Networking.

   2. Accettare i valori esistenti per le opzioni avanzate del pool di nodi oppure fare clic su Mostra opzioni avanzate e specificare le alternative come indicato di seguito.

      • Cordon and Drain: cambia quando e come collegare ed estrarre i nodi di lavoro prima di terminarli.

        • Periodo di proroga di previsione (min): il periodo di tempo necessario per consentire di collegare ed eliminare i nodi di lavoro prima di terminarli. Accettare il valore predefinito (60 minuti) o specificare un'alternativa. Ad esempio, quando si esegue lo scale down di un pool di nodi o si modifica la relativa configurazione di posizionamento, potrebbe essere necessario consentire 30 minuti per collegare i nodi di lavoro ed eliminarli dai carichi di lavoro. Per terminare immediatamente i nodi di lavoro, senza cordonarli e drenarli, 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'avvio del cloud nelle 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.
        • Scegli script Cloud-Init: selezionare un file contenente lo script cloud-init oppure trascinare il file nella casella.
        • Incolla script Cloud-Init: copiare il contenuto di uno script cloud-init e incollarlo 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 fare clic su Scarica modello script di inizializzazione cloud personalizzato. Il file scaricato contiene la logica predefinita fornita dal motore Kubernetes. È possibile aggiungere la propria logica personalizzata prima o dopo la logica predefinita, ma non modificare la logica predefinita. Per alcuni esempi, vedere Esempio di casi d'uso per gli 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 l'indirizzamento dei carichi di lavoro in pool di nodi specifici. Ad esempio, per escludere tutti i nodi di 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).
      • Chiave SSH pubblica: (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à l'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).
   3. Fare clic su Salva modifiche per salvare le proprietà aggiornate.

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

   1. Fare clic su Modifica e specificare quanto segue.
      • Nome: un nome diverso per il pool di nodi. Evitare di inserire informazioni riservate.
      • Conteggio 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 Scalatura dei pool di nodi.
      • Configurazione posizionamento nodi:
        • Dominio di disponibilità: dominio di disponibilità in cui inserire nodi virtuali.
        • Domini di errore: (facoltativo) uno o più domini di errore nel dominio di disponibilità in cui posizionare i nodi virtuali.

        Facoltativamente, fare clic su Altra riga per selezionare più domini e subnet 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:
        • Subnet: subnet regionale diversa (consigliata) o 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 di utilizzare la subnet pod e la subnet del nodo virtuale come 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 e pod di lavoratori.
      • Comunicazione pod:
        • Subnet: subnet regionale diversa configurata per ospitare i pod. La subnet pod specificata per i nodi virtuali deve essere privata. Si consiglia che la subnet pod e la subnet del nodo virtuale siano la stessa subnet (nel qual caso, Oracle consiglia di definire le 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 e pod di lavoratori.

        Per ulteriori informazioni sulla comunicazione pod, vedere Pod Networking.

      • Etichette e taint Kubernetes: (facoltativo) abilitare la definizione dei destinatari dei carichi di lavoro in pool di nodi specifici aggiungendo etichette e taint ai nodi virtuali:
        • Etichette: una o più etichette (oltre a un'etichetta predefinita) da aggiungere ai nodi virtuali nel pool di nodi virtuali per abilitare l'indirizzamento dei carichi di lavoro in pool di nodi specifici.
        • Suggerimenti: uno o più suggerimenti da aggiungere ai nodi virtuali nel pool di nodi virtuali. I taint consentono ai nodi virtuali di respingere i pod e quindi garantiscono che i pod non vengano eseguiti su nodi virtuali in un determinato pool di nodi virtuali. È possibile applicare i taint solo ai nodi virtuali.

        Per ulteriori informazioni, consulta la sezione relativa all'assegnazione dei pod ai nodi nella documentazione di Kubernetes.

   2. Fare clic su Salva modifiche per salvare le proprietà aggiornate.
9. Utilizzare la scheda Tag pool di nodi e la scheda Tag nodo per aggiungere o modificare le tag applicate al pool di nodi e le tag applicate alle istanze di calcolo che ospitano i nodi di lavoro nel pool di nodi. L'applicazione di tag consente di raggruppare risorse eterogenee in vari compartimenti e di aggiungere annotazioni alle risorse con i propri metadati. Vedere Applicazione di tag alle risorse correlate al cluster Kubernetes.
10. In Risorse:
    • Fare clic su 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 facendo clic sul nome del nodo di lavoro.
    • Fare clic su Nodi virtuali per visualizzare informazioni su nodi di lavoro specifici in un pool di nodi virtuali.
    • Fare clic su Metriche per monitorare lo stato, la capacità e le prestazioni di un pool di nodi gestito. Per ulteriori informazioni, consulta le metriche OKE (Kubernetes Engine).
    • Fare clic su Richieste di lavoro per:
      • 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.