Aggiunta di pool di nodi per lo scale up dei cluster

Per eseguire lo scale up di un cluster esistente aumentando il numero di pool di nodi nel cluster mediante la console, 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 Aggiungi pool di nodi per eseguire lo scale up del cluster mediante l'aggiunta di pool di nodi.
3. Immettere i dettagli per il nuovo pool di nodi:
   • Nome: un nome a scelta per il nuovo pool di nodi. Evitare di fornire informazioni riservate.
   • Compartimento: compartimento in cui creare il nuovo pool di nodi.
   • Tipo di nodo: se il tipo di rete del cluster è Networking pod nativo per la VCN, specificare il tipo di nodi di lavoro in questo pool di nodi (vedere Nodi virtuali e nodi gestiti). Selezionare una delle opzioni seguenti.
     • Gestito: selezionare questa opzione quando si desidera avere la responsabilità di gestire i nodi di lavoro nel pool di nodi. Nodi gestiti, in esecuzione su istanze di computazione (Bare Metal o virtual machine) nella tenancy. Poiché sei responsabile della gestione dei nodi gestiti, hai la flessibilità di configurarli per soddisfare i tuoi requisiti specifici. Sei responsabile dell'upgrade di Kubernetes sui nodi gestiti e della gestione della capacità del cluster.
     • Virtuale: selezionare questa opzione quando si desidera beneficiare di un'esperienza Kubernetes 'serverless'. I nodi virtuali ti consentono di eseguire pod Kubernetes su larga scala senza il sovraccarico operativo di eseguire l'upgrade dell'infrastruttura del piano dati e gestire la capacità dei cluster.

     Per ulteriori informazioni, vedere Confronto di nodi virtuali con nodi gestiti.

   • Versione Kubernetes: (solo pool di nodi gestiti) La versione di Kubernetes da eseguire su ogni nodo gestito in un pool di nodi gestiti. Per impostazione predefinita, è selezionata la versione di Kubernetes specificata per i nodi del piano di controllo. La versione Kubernetes sui nodi di lavoro deve essere la stessa di quella sui nodi del piano di controllo o una versione precedente ancora compatibile. Consulta Kubernetes Versions and 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.

4. Se il tipo di rete del cluster è Networking pod nativo per VCN ed è stata selezionata l'opzione Gestito come Tipo di nodo o se il tipo di rete del cluster è Overlay canale:

   1. Accettare le impostazioni predefinite per le opzioni avanzate del pool di nodi oppure selezionare Opzioni avanzate e specificare le alternative come indicato di seguito.

      • Cordone e scarico: specificare 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 per l'inizializzazione del cloud da eseguire su ogni istanza che ospita i 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).
      • Tag del pool di nodi e Tag dei nodi: (facoltativo) una o più tag da aggiungere al pool di nodi e alle istanze di computazione che ospitano i nodi di lavoro 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.
      • Aggiungere una chiave SSH: (facoltativo) generare una coppia di chiavi o caricare la parte di chiave pubblica della coppia di chiavi che si desidera utilizzare per l'accesso SSH a ogni nodo 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).

   2. Specificare i dettagli di configurazione per il pool di nodi gestiti:

      • 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à, assicurarsi che la forma del nodo, il dominio di disponibilità e il dominio di errore nella configurazione di posizionamento del pool di nodi corrispondano 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: la forma 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 predefinita, 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: l'immagine 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 predefinita, 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.

      • Conteggio nodi: il numero di nodi di lavoro da creare nel pool di nodi, inseriti nei domini di disponibilità selezionati e nella subnet regionale (consigliata) o specifica di AD specificata per ogni dominio di disponibilità.
      • 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: configurare 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 in transito. 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 è nativo per la rete pod VCN, specificare 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.

5. Se come Tipo di nodo è stato selezionato Virtuale:
   1. Specificare i dettagli di configurazione per il pool di nodi virtuali:
      • 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 domini aggiuntivi 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à.

      • Conteggio dei nodi: il numero di nodi virtuali da creare nel pool di nodi virtuali, inseriti nei domini di disponibilità selezionati e nella subnet regionale (consigliata) o specifica di AD specificata per ogni dominio di disponibilità.

      • Forma pod: la forma da utilizzare per i pod in esecuzione sui nodi virtuali nel pool di nodi virtuali. La forma determina il tipo di processore su cui eseguire il pod.

        Vengono visualizzate solo le forme disponibili nella tenancy supportate da Kubernetes Engine. Vedere Immagini supportate (incluse immagini personalizzate) e forme per i nodi di lavoro.

        Si noti che è necessario specificare in modo esplicito i requisiti delle risorse di CPU e memoria per i nodi virtuali nella specifica pod (vedere Assegna risorse di memoria a contenitori e pod e Assegna risorse CPU a contenitori e pod nella documentazione di Kubernetes).

      • Comunicazione nodo virtuale:
        • Compartimento della subnet: il compartimento in cui risiede la subnet del nodo virtuale.
        • Subnet: una subnet regionale (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). Vedere Configurazione 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: i pod in esecuzione sui nodi virtuali utilizzano il pod networking nativo per la VCN. Specificare 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 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). 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.

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

   2. Accettare le impostazioni predefinite per le opzioni avanzate del pool di nodi virtuali oppure selezionare Opzioni avanzate e specificare le alternative come indicato di seguito.

      • Tag del pool di nodi: (facoltativo) una o più tag da aggiungere al pool di nodi virtuali. 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.
      • 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 trattini consentono ai nodi virtuali di respingere i pod, garantendo in tal modo che i pod non vengano eseguiti sui nodi virtuali in un determinato pool di nodi virtuali. Si noti che è possibile applicare le taint solo ai nodi virtuali. Per ulteriori informazioni, vedere Assegnazione dei pod ai nodi nella documentazione di Kubernetes.
6. Selezionare Aggiungi per creare il nuovo pool di nodi.