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. Aprire il menu di navigazione e selezionare Developer Services. In Container e artifact, selezionare Cluster Kubernetes (OKE).
2. Scegliere un compartimento in cui si dispone dell'autorizzazione per lavorare.
3. Nella pagina Elenco cluster fare clic sul nome del cluster che si desidera modificare.
4. In Risorse fare clic su Pool di nodi.
5. Fare clic sul pulsante Aggiungi pool di nodi ed eseguire lo scale up del cluster aggiungendo pool di nodi.
6. Immettere i dettagli per il nuovo pool di nodi:
   • Nome: nome scelto per il nuovo pool di nodi. Evitare di inserire informazioni riservate.
   • Compartimento: compartimento in cui creare il nuovo pool di nodi.
   • Tipo di nodo: se il tipo di rete del cluster è VCN: networking pod nativo, 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 trarre vantaggio da un'esperienza Kubernetes 'serverless'. I nodi virtuali ti consentono di eseguire i pod Kubernetes su larga scala senza il sovraccarico operativo derivante dall'upgrade dell'infrastruttura del piano dati e dalla gestione della capacità dei cluster.

     Per ulteriori informazioni, vedere Confronto dei nodi virtuali con i nodi gestiti.

   • Versione: (solo pool di nodi gestiti) La versione di Kubernetes da eseguire su ogni nodo gestito in un pool di nodi gestiti. Per impostazione predefinita, viene selezionata la versione di Kubernetes specificata per i nodi del piano di controllo. 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 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.

7. Se il tipo di rete del cluster è rete pod nativa VCN ed è stato selezionato Gestito come Tipo di nodo oppure se il tipo di rete del cluster è Overlay multicanale:

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

      • Configurazione posizionamento nodi:
        • 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à, 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 dell'assegnazione capacità. Vedere Utilizzo delle assegnazioni capacità per il provisioning dei nodi gestiti.

        Facoltativamente, fare clic su 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 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: 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 un altro software per il nodo.

        Per modificare l'immagine predefinita, 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.

      • 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 nella subnet 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 boot: configurare le opzioni di dimensione e 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 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 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 è VCN: networking pod nativo, specificare 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.
        • 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.

        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 le impostazioni predefinite per le opzioni avanzate del pool di nodi oppure selezionare Mostra opzioni avanzate e specificare le alternative come indicato di seguito.

      • Cordon and Drain: specificare 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) script per l'avvio del cloud da eseguire su ogni istanza che ospita 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).
      • Tag del pool di nodi e Tag dei nodi: (facoltativo) una o più tag da aggiungere al pool di nodi e alle istanze di calcolo che ospitano 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.
      • Chiave SSH pubblica: (facoltativo) la parte della chiave pubblica della coppia di chiavi che si desidera utilizzare per l'accesso SSH a ciascun nodo del 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).
8. Se come Tipo di nodo è stato selezionato Virtuale:
   1. Specificare i dettagli di configurazione per il pool di nodi virtuali:
      • 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 domini e subnet 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 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 nella subnet 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:
        • Subnet: subnet regionale (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). 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: i pod in esecuzione sui nodi virtuali utilizzano il networking pod nativo VCN. Specificare 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 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). 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.

   2. Accettare le impostazioni predefinite per le opzioni avanzate del pool di nodi virtuali oppure fare clic su Mostra opzioni avanzate e specificare le alternative come indicato di seguito.

      • Tag pool di nodi: (facoltativo) una o più tag da aggiungere al pool di nodi virtuali. 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.
      • 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, garantendo in tal modo che i pod non vengano eseguiti su nodi virtuali in un determinato pool di nodi virtuali. Si noti che è 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.

9. Fare clic su Aggiungi per creare il nuovo pool di nodi.