**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Personalizzazione dei nodi gestiti con modelli di avvio Per il massimo livello di personalizzazione, puoi distribuire nodi gestiti con il tuo modello di lancio in base ai passaggi di questa pagina. L'utilizzo di un modello di avvio consente funzionalità come fornire argomenti di bootstrap durante la distribuzione di un nodo (ad esempio, argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi), assegnare indirizzi IP ai Pod da un blocco CIDR diverso dall'indirizzo IP assegnato al nodo, distribuire la propria AMI personalizzata ai nodi o distribuire il proprio CNI personalizzato sui nodi. Quando fornisci il tuo modello di avvio alla prima creazione di un gruppo di nodi gestito, in seguito avrai anche una maggiore flessibilità. Dopo aver implementato un gruppo di nodi gestiti con un modello di avvio personalizzato, potrai aggiornarlo in maniera iterativa con una versione diversa dello stesso modello. Quando si aggiorna il gruppo di nodi a una versione diversa del modello di avvio, tutti i nodi del gruppo vengono riciclati in modo da corrispondere alla nuova configurazione della versione del modello di avvio specificata. I gruppi di nodi gestiti vengono sempre implementati con un modello di avvio da utilizzare con gruppo di Amazon EC2 Auto Scaling. Quando non è fornito un modello di avvio, l’API Amazon EKS ne crea automaticamente uno con i valori predefiniti nel tuo account. Tuttavia, consigliamo di non modificare i modelli di avvio generati automaticamente. Inoltre, i gruppi di nodi esistenti che non utilizzano un modello di avvio personalizzato non possono essere aggiornati direttamente. A tale scopo, sarà invece necessario creare un nuovo gruppo di nodi con un modello di avvio personalizzato. ## Informazioni di base sulla configurazione del modello di avvio Puoi creare un modello di lancio di Amazon EC2 Auto Scaling con la Console di gestione AWS CLI AWS o un SDK. AWS Per ulteriori informazioni, consulta [Creazione di un modello di avvio per un gruppo con scalabilità automatica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*. Alcune impostazioni di un modello di avvio sono simili a quelle utilizzate per la configurazione dei nodi gestiti. Quando si implementa o si aggiorna un gruppo di nodi con un modello di avvio, è necessario specificare alcune impostazioni nella configurazione del gruppo di nodi o nel modello di avvio. Non specificare un’impostazione in entrambe le posizioni. Se un’impostazione è impostata dove non dovrebbe, operazioni come la creazione o l’aggiornamento di un gruppo di nodi non hanno esito positivo. Nella tabella seguente sono elencate le impostazioni vietate in un modello di avvio. Elenca inoltre impostazioni simili, se disponibili, che sono necessarie per la configurazione del gruppo di nodi gestiti. Le impostazioni elencate sono quelle visualizzate nella console. Potrebbero avere nomi simili ma diversi nella AWS CLI e nell'SDK. | Modello di avvio – Vietato | Configurazione del gruppo di nodi Amazon EKS | | --- | --- | | **Sottorete** in **Interfacce di rete** (**Aggiungi interfaccia di rete**) | **Sottoreti** in **Configurazione di rete del gruppo di nodi** nella pagina **Specifica reti** | | **Profilo dell'istanza IAM** in **Dettagli avanzati** | **Ruolo IAM del nodo** in **Configurazione del gruppo di nodi** nella pagina **Configura gruppo di nodi** | | **Comportamento di arresto** e **Interrompi - Iberna comportamento** in **Dettagli avanzati**. Mantieni default **Non includere nell’impostazione del modello di avvio** nel modello di avvio per entrambe le impostazioni. | Nessun equivalente. Amazon EKS deve controllare il ciclo di vita dell'istanza, non il gruppo Auto Scaling. | Nella tabella seguente sono elencate le impostazioni vietate nella configurazione di un gruppo di nodi gestiti. Elenca inoltre impostazioni simili, se disponibili, richieste in un modello di avvio. Le impostazioni elencate sono quelle visualizzate nella console. Potrebbero avere nomi simili nella AWS CLI e nell'SDK. | Configurazione del gruppo di nodi Amazon EKS – Vietata | Modello di avvio | | --- | --- | | (Solo se è stata specificata un'AMI personalizzata in un modello di avvio) **Tipo di AMI** in **Configurazione di calcolo del gruppo di nodi** sulla pagina **Imposta configurazione di calcolo e dimensionamento**: la console mostra il messaggio **Specificato nel modello di lancio** e l'ID AMI specificato. Se nel modello di avvio non è stato specificato **Applicazione e immagini OS (Amazon Machine Image)**, è possibile selezionare un’AMI nella configurazione del gruppo di nodi. | **Applicazione e immagini OS (Amazon Machine Image)** in **Contenuti del modello di avvio**: è necessario specificare un ID se soddisfi uno dei seguenti requisiti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/launch-templates.html) | | **Dimensioni del disco** in **Configurazione di calcolo del gruppo di nodi** nella pagina **Imposta configurazione di calcolo e dimensionamento**: la console mostra il messaggio **Specificato nel modello di lancio**. | **Dimensioni** in **Archiviazione (volumi)** (**Aggiungi nuovo volume**). È necessario specificarlo nel modello di avvio. | | **Coppia di chiavi SSH** in **Configurazione del gruppo di nodi** nella pagina **Specifica reti**: la console mostra la chiave specificata nel modello di avvio o mostra il messaggio **Non specificato nel modello di lancio**. | **Nome della coppia di chiavi** in **Coppia di chiavi (login)**. | | Non è possibile specificare gruppi di sicurezza di origine a cui è consentito l’accesso remoto quando si utilizza un modello di avvio. | **Gruppi di sicurezza** in **Impostazioni di rete** per l'istanza o **Gruppi di sicurezza** in **Interfacce di rete** (**Aggiungi interfaccia di rete**), ma non entrambi. Per ulteriori informazioni, consulta [Utilizzo di gruppi di sicurezza personalizzati](#launch-template-security-groups). | **Nota** Se si esegue l'implementazione di un gruppo di nodi utilizzando un modello di avvio, specificare uno o nessun **Tipo di istanza** in **Contenuti del modello di avvio** in un modello di avvio. In alternativa, è possibile specificare 0-20 tipi di istanza per **Tipi di istanza** nella pagina **Impostare la configurazione di calcolo e dimensionamento** della console. In alternativa, è possibile farlo utilizzando altri strumenti che utilizzano l'API Amazon EKS. Se specifichi un tipo di istanza in un modello di avvio e si utilizza tale modello di avvio per implementare il gruppo di nodi, non è possibile specificare alcun tipo di istanza nella console o utilizzare altri strumenti che sfruttino l’API Amazon EKS. Se non specifichi un tipo di istanza in un modello di avvio nella console o in altri strumenti che utilizzano l’API Amazon EKS, il tipo di istanza `t3.medium` sarà utilizzato. Se il gruppo di nodi utilizza il tipo di capacità Spot, è consigliabile specificare più tipi di istanza utilizzando la console. Per ulteriori informazioni, consulta [Tipi di capacità del gruppo di nodi gestiti](managed-node-groups.md#managed-node-group-capacity-types). Se i container che si implementano nel gruppo di nodi utilizzano Instance Metadata Service versione 2, assicurarsi di impostare il **Limite hop di risposta metadati** a `2` nel modello di avvio. Per ulteriori informazioni, consulta [Metadati e dati dell'utente delle istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) nella *Guida per l'utente di Amazon EC2*. I modelli di avvio non supportano la funzionalità `InstanceRequirements` che consente la selezione flessibile del tipo di istanza. ## Assegnazione di tag a istanze Amazon EC2 É possibile utilizzare il parametro `TagSpecification` di un modello di avvio per specificare quali tag applicare alle istanze Amazon EC2 nel gruppo di nodi. L'entità IAM che chiama `CreateNodegroup` o `UpdateNodegroupVersion` APIs deve disporre delle autorizzazioni per `ec2:RunInstances` and `ec2:CreateTags` e i tag devono essere aggiunti al modello di lancio. ## Utilizzo di gruppi di sicurezza personalizzati É possibile utilizzare un modello di avvio per specificare i [gruppi di sicurezza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) Amazon EC2 da applicare alle istanze del gruppo di nodi. Questo può essere nel parametro gruppi di sicurezza a livello di istanza o come parte dei parametri di configurazione dell'interfaccia di rete. Non è possibile avviare un’istanza da un modello di avvio che specifica sia il livello di istanza sia l’interfaccia di rete dei gruppi di sicurezza. Considerare le seguenti condizioni che si applicano all'utilizzo di gruppi di sicurezza personalizzati con gruppi di nodi gestiti: + Quando si utilizza Console di gestione AWS, Amazon EKS consente solo modelli di avvio con una singola specifica di interfaccia di rete. + Per impostazione predefinita, Amazon EKS applica il [Gruppo di sicurezza del cluster](sec-group-reqs.md) alle istanze nel gruppo di nodi, per facilitare la comunicazione tra i nodi e il piano di controllo. Se specifichi gruppi di sicurezza personalizzati nel modello di avvio utilizzando entrambe le opzioni menzionate in precedenza, Amazon EKS non aggiunge il gruppo di sicurezza del cluster. Pertanto, è necessario assicurarsi che le regole in entrata e in uscita dei gruppi di sicurezza abilitino la comunicazione con l'endpoint del cluster. Se le regole del gruppo di sicurezza non sono corrette, i nodi (worker) non possono aggiungersi al cluster. Per ulteriori informazioni sulle regole del gruppo di sicurezza, consultare [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). + Se è necessario l'accesso SSH alle istanze nel gruppo di nodi, includere un gruppo di sicurezza che consenta tale accesso. ## Dati utente Amazon EC2 Il modello di avvio include una sezione per i dati utente personalizzati. Puoi specificare le impostazioni di configurazione per il tuo gruppo di nodi in questa sezione senza creare manualmente singole impostazioni personalizzate AMIs. Per ulteriori informazioni sulle impostazioni disponibili per Bottlerocket, consulta [Using user data on](https://github.com/bottlerocket-os/bottlerocket#using-user-data). GitHub É possibile fornire i dati utente Amazon EC2 nel tuo modello di avvio utilizzando `cloud-init` durante l'avvio delle istanze. Per ulteriori informazioni, consultare la documentazione [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). I dati utente possono essere utilizzati per eseguire operazioni di configurazione comuni. Sono comprese le seguenti opzioni: + [Inclusione di utenti o gruppi.](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) + [Installazione di pacchetti](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) I dati utente di Amazon EC2 nei modelli di avvio utilizzati con gruppi di nodi gestiti devono essere nel formato di archivio [multiparte MIME per Amazon Linux AMIs e nel formato](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) TOML per Bottlerocket. AMIs Questo perché i dati utente vengono uniti con i dati utente Amazon EKS necessari ai nodi per aderire al cluster. Non specificare alcun comando nei dati utente che avviano o modificano `kubelet`. Questa operazione viene eseguita come parte dei dati utente uniti da Amazon EKS. Certi parametri `kubelet`, come l'impostazione delle etichette sui nodi, possono essere configurati direttamente tramite l'API dei gruppi di nodi gestiti. **Nota** Per ulteriori informazioni sulle personalizzazioni `kubelet` avanzate, tra cui l'avvio manuale o il passaggio a parametri di configurazione personalizzati, vedere [Specifica di un'AMI](#launch-template-custom-ami). Amazon EKS non unisce i dati utente se un ID AMI viene specificato in un modello di avvio. I seguenti dettagli forniscono ulteriori informazioni sulla sezione dei dati utente. **Dati utente di Amazon Linux 2** È possibile unire più blocchi di dati utente in un unico blocco, detto file MIME in più parti. Ad esempio, è possibile combinare un hook di avvio del cloud per la configurazione del daemon Docker con uno script di shell dei dati utente che installa un pacchetto personalizzato. Un file MIME in più parti è composto dai seguenti elementi: + Il tipo di contenuto e la dichiarazione di delimitazione della parte: `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` + La dichiarazione della versione MIME: `MIME-Version: 1.0` + Uno o più blocchi di dati utente, che contengono i seguenti elementi: + La delimitazione di apertura, che indica l'inizio di un blocco di dati utente: `--==MYBOUNDARY==` + La dichiarazione del tipo di contenuto per il blocco: `Content-Type: text/cloud-config; charset="us-ascii"`. Per ulteriori informazioni sui tipi di contenuto, consultare la documentazione di [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html). + Il contenuto dei dati utente, ad esempio un elenco di comandi shell o direttive `cloud-init`. + La delimitazione di chiusura, che indica la fine del file MIME in più parti: `--==MYBOUNDARY==--` Di seguito è riportato un esempio di un file in più parti MIME che è possibile utilizzare per crearne uno. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash echo "Running custom user data script" --==MYBOUNDARY==-- ``` **Dati utente di Amazon Linux 2023** Amazon Linux 2023 (AL2023) introduce un nuovo processo di inizializzazione dei nodi `nodeadm` che utilizza uno schema di configurazione YAML. Se utilizzi gruppi di nodi autogestiti o un’AMI con un modello di avvio, ora dovrai fornire esplicitamente metadati del cluster aggiuntivi quando si crea un nuovo gruppo di nodi. Un [esempio](https://awslabs.github.io/amazon-eks-ami/nodeadm/) dei parametri minimi richiesti è come segue, dove ora `apiServerEndpoint`, `certificateAuthority` e il servizio `cidr` sono richiesti: ``` --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 ``` In genere questa configurazione è impostata nei dati utente, così com’è o incorporata in un documento MIME composto da più parti: ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: [...] --BOUNDARY-- ``` Nel AL2, i metadati di questi parametri sono stati scoperti dalla chiamata `DescribeCluster` API di Amazon EKS. Nel frattempo AL2023, questo comportamento è cambiato poiché la chiamata API aggiuntiva rischia di rallentare durante l'up-up di nodi su larga scala. Questa modifica non ha effetto su di te se utilizzi gruppi di nodi gestiti senza un modello di avvio o se utilizzi Karpenter. Per ulteriori informazioni su `certificateAuthority` e sul servizio `cidr`, consulta [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) nel *Riferimento di API Amazon EKS*. Ecco un esempio completo di dati AL2023 utente che combina uno script di shell per personalizzare il nodo (come l'installazione di pacchetti o la prememorizzazione nella cache delle immagini dei contenitori) con la configurazione richiesta. `nodeadm` Questo esempio mostra personalizzazioni comuni tra cui: \$1 Installazione di pacchetti di sistema aggiuntivi \$1 Pre-memorizzazione nella cache delle immagini dei container per migliorare il tempo di avvio del pod \$1 Impostazione della configurazione del proxy HTTP \$1 Configurazione dei flag `kubelet` per l’etichettatura dei nodi ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -o errexit set -o pipefail set -o nounset # Install additional packages yum install -y htop jq iptables-services # Pre-cache commonly used container images nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 & # Configure HTTP proxy if needed cat > /etc/profile.d/http-proxy.sh << 'EOF' export HTTP_PROXY="http://proxy.example.com:3128" export HTTPS_PROXY="http://proxy.example.com:3128" export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal" EOF --BOUNDARY Content-Type: application/node.eks.aws apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 kubelet: config: clusterDNS: - 10.100.0.10 flags: - --node-labels=app=my-app,environment=production --BOUNDARY-- ``` **Dati utente Bottlerocket** I dati utente delle strutture Bottlerocket nel formato TOML. È possibile fornire i dati utente da unire con i dati utente forniti da Amazon EKS. Ad esempio, è possibile fornire ulteriori impostazioni `kubelet`. ``` [settings.kubernetes.system-reserved] cpu = "10m" memory = "100Mi" ephemeral-storage= "1Gi" ``` Per ulteriori informazioni sulle impostazioni supportate, consultare la [documentazione Bottlerocket](https://github.com/bottlerocket-os/bottlerocket). È possibile configurare etichette di nodi e [taint](node-taints-managed-node-groups.md) nei dati utente. Consigliamo, tuttavia, di configurarle all'interno del gruppo di nodi. In questo caso, Amazon EKS applica queste configurazioni. Quando i dati utente sono uniti, la formattazione non è mantenuta, ma il contenuto rimane invariato. La configurazione fornita nei dati utente sostituisce tutte le impostazioni configurate da Amazon EKS. Quindi, se imposti `settings.kubernetes.max-pods` o `settings.kubernetes.cluster-dns-ip`, questi valori nei dati utente sono applicati ai nodi. Amazon EKS non supporta tutti i TOML validi. Di seguito è riportato un elenco di formati noti non supportati: + Quote all'interno delle chiavi stimate: `'quoted "value"' = "value"` + Quote evase nei valori: `str = "I’m a string. \"You can quote me\""` + Galleggianti e numeri interi misti: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` + Tipi misti nelle matrici: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` + Intestazioni tra parentesi con chiavi stimate: `[foo."bar.baz"]` **Dati utente Windows** I dati utente di Windows utilizzano i comandi. PowerShell Quando crei un gruppo di nodi gestiti, i dati utente personalizzati si combinano con i dati utente gestiti da Amazon EKS. PowerShell I tuoi comandi vengono prima, seguiti dai comandi gestiti per i dati utente, il tutto all'interno di un unico `` tag. Durante la creazione di gruppi di nodi Windows, Amazon EKS aggiorna il file `aws-auth` `ConfigMap` per consentire ai nodi basati su Linux di unirsi al cluster. Il servizio non configura automaticamente le autorizzazioni per Windows AMIs. Se utilizzi i nodi Windows, dovrai gestire l’accesso tramite l’API della voce di accesso o aggiornando direttamente `aws-auth` `ConfigMap`. Per ulteriori informazioni, consulta [Implementazione dei nodi Windows su cluster EKS](windows-support.md). Quando non è specificato alcun ID AMI nel modello di avvio, nei dati utente non utilizzare lo script bootstrap di Amazon EKS per Windows per configurare Amazon EKS. Di seguito sono riportati dati utente di esempio. ``` Write-Host "Running custom user data script" ``` ## Specifica di un'AMI Se si dispone di uno dei seguenti requisiti, specificare un ID AMI nel campo `ImageId` del modello di avvio. Selezionare il requisito di cui si dispone per ulteriori informazioni. ### Fornisci i dati utente per passare argomenti al `bootstrap.sh` file incluso in un' Linux/Bottlerocket AMI ottimizzata per Amazon EKS Il termine "bootstrapping" indica l'aggiunta di comandi che possono essere eseguiti all'avvio di un'istanza. Ad esempio, il bootstrap consente di utilizzare argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi. È possibile passare gli argomenti allo script `bootstrap.sh` utilizzando `eksctl` senza specificare un modello di avvio. Oppure è possibile farlo specificando le informazioni nella sezione dati utente di un modello di avvio. **eksctl senza specificare un modello di avvio** Crea un file denominato *my-nodegroup.yaml* con i seguenti contenuti. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` sono facoltativi, ma grazie alla loro definizione lo script `bootstrap.sh` può evitare di effettuare una chiamata a `describeCluster`. Ciò è utile nelle configurazioni di cluster privati o nei cluster in cui si effettuano dimensionamenti frequenti dei nodi. Per ulteriori informazioni sullo `bootstrap.sh` script, consulta il file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) su GitHub. + L'unico argomento richiesto è il nome del cluster (*my-cluster*). + Per recuperare l’ID di un’AMI ottimizzata per `ami-1234567890abcdef0 `, consulta le sezioni seguenti: + [Recupera le AMI Amazon Linux consigliate IDs](retrieve-ami-id.md) + [Recupera l'AMI Bottlerocket consigliata IDs](retrieve-ami-id-bottlerocket.md) + [Recupera l'AMI Microsoft Windows consigliata IDs](retrieve-windows-ami-id.md) + Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + Questo esempio fornisce un argomento `kubelet` per impostare un valore `max-pods` personalizzato utilizzando lo script `bootstrap.sh` incluso nell'AMI ottimizzata per Amazon EKS. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura. Per assistenza nella scelta di *my-max-pods-value*, consulta . Per ulteriori informazioni su come `maxPods` viene determinato quando si utilizzano i gruppi di nodi gestiti, vedere[Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence). ``` --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code managedNodeGroups: - name: my-nodegroup ami: ami-1234567890abcdef0 instanceType: m5.large privateNetworking: true disableIMDSv1: true labels: { x86-al2-specified-mng } overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false ``` Per ogni opzione disponibile per il file `eksctl` `config`, consulta [Schema del file config](https://eksctl.io/usage/schema/) nella documentazione su `eksctl`. L'utility `eksctl` crea autonomamente un modello di avvio e popola i dati utente con i dati forniti nel file `config`. Crea un gruppo di nodi con il comando seguente. ``` eksctl create nodegroup --config-file=my-nodegroup.yaml ``` **Dati utente in un modello di avvio** Specifica le seguenti informazioni nella sezione dati utente del modello di avvio. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` sono facoltativi, ma grazie alla loro definizione lo script `bootstrap.sh` può evitare di effettuare una chiamata a `describeCluster`. Ciò è utile nelle configurazioni di cluster privati o nei cluster in cui si effettuano dimensionamenti frequenti dei nodi. Per ulteriori informazioni sullo `bootstrap.sh` script, vedere il file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) su GitHub. + L'unico argomento richiesto è il nome del cluster (*my-cluster*). + Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + Questo esempio fornisce un argomento `kubelet` per impostare un valore `max-pods` personalizzato utilizzando lo script `bootstrap.sh` incluso nell'AMI ottimizzata per Amazon EKS. Per assistenza nella scelta di *my-max-pods-value*, consulta . Per ulteriori informazioni su come `maxPods` viene determinato quando si utilizzano i gruppi di nodi gestiti, vedere[Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence). ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -ex /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false --==MYBOUNDARY==-- ``` ### Fornire i dati dell’utente per passare gli argomenti al file `Start-EKSBootstrap.ps1` incluso nell’AMI Windows ottimizzata per Amazon EKS Il termine "bootstrapping" indica l'aggiunta di comandi che possono essere eseguiti all'avvio di un'istanza. È possibile passare gli argomenti allo script `Start-EKSBootstrap.ps1` utilizzando `eksctl` senza specificare un modello di avvio. Oppure è possibile farlo specificando le informazioni nella sezione dati utente di un modello di avvio. Per specificare un ID AMI Windows personalizzato, fai le seguenti considerazioni: + Devi utilizzare un modello di avvio e fornire i comandi bootstrap richiesti nella sezione dei dati utente. Per recuperare l'ID Windows desiderato, puoi utilizzare la tabella in [Crea nodi con Windows AMIs ottimizzato](eks-optimized-windows-ami.md). + Esistono vari limiti e condizioni. Ad esempio, è necessario aggiungere `eks:kube-proxy-windows` alla mappa di configurazione di AWS IAM Authenticator. Per ulteriori informazioni, consulta [Limiti e condizioni quando si specifica un ID AMI](#mng-ami-id-conditions). Specifica le seguenti informazioni nella sezione dati utente del modello di avvio. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `-APIServerEndpoint`, `-Base64ClusterCA` e `-DNSClusterIP` sono facoltativi, ma grazie alla loro definizione lo script `Start-EKSBootstrap.ps1` può evitare di effettuare una chiamata a `describeCluster`. + L'unico argomento richiesto è il nome del cluster (*my-cluster*). + Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + Per ulteriori argomenti, consulta.[Parametri di configurazione dello script di bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters). **Nota** Se utilizzi il servizio personalizzato CIDR, devi specificarlo utilizzando il parametro `-ServiceCIDR`. In caso contrario, la risoluzione DNS per i pod nel cluster avrà esito negativo. ``` [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName my-cluster ` -Base64ClusterCA certificate-authority ` -APIServerEndpoint api-server-endpoint ` -DNSClusterIP service-cidr.10 ``` ### Eseguire un'AMI personalizzata a causa di specifici requisiti di sicurezza, conformità o policy interne Per ulteriori informazioni, consulta [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) nella *Guida per l’utente di Amazon EC2*. La specifica di compilazione AMI Amazon EKS contiene risorse e script di configurazione per la creazione di un’AMI Amazon EKS personalizzata basata su Amazon Linux. Per ulteriori informazioni, consulta [Specifica della build AMI di Amazon EKS](https://github.com/awslabs/amazon-eks-ami/) su GitHub. Per creare AMIs installazioni personalizzate con altri sistemi operativi, consulta [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) on GitHub. Non è possibile utilizzare riferimenti dinamici ai parametri per AMI IDs nei modelli di avvio utilizzati con gruppi di nodi gestiti. **Importante** Quando si specifica un'AMI, Amazon EKS non convalida la versione di Kubernetes incorporata nell'AMI rispetto alla versione del piano di controllo del cluster. Sei responsabile di garantire che la versione Kubernetes della tua AMI personalizzata sia conforme alla politica di modifica della versione di [Kubernetes](https://kubernetes.io/releases/version-skew-policy): La `kubelet` versione sui tuoi nodi non deve essere più recente della versione del cluster La `kubelet` versione sui tuoi nodi deve essere uguale o superiore a 3 versioni secondarie rispetto alla versione del cluster (per la versione Kubernetes `1.28` o successiva) o fino a 2 versioni minori rispetto alla versione del cluster (per la versione Kubernetes o precedente) `1.27` La creazione di gruppi di nodi gestiti con violazioni dell'asimmetria delle versioni può comportare: I nodi non riescono a unirsi al cluster Comportamento indefinito o incompatibilità delle API Instabilità del cluster o errori del carico di lavoro Quando si specifica una AMI, Amazon EKS non unisce alcun dato utente. È l’utente, piuttosto, ad essere responsabile della fornitura dei comandi `bootstrap` richiesti per unire i nodi al cluster. Se i nodi non riescono a unirsi al cluster, le operazioni `CreateNodegroup` e `UpdateNodegroupVersion` di Amazon EKS non vengono eseguite con successo. ## Limiti e condizioni quando si specifica un ID AMI Di seguito sono riportati i limiti e le condizioni per la specifica di un ID AMI con gruppi di nodi gestiti: + È necessario creare un nuovo gruppo di nodi per passare dalla specifica o meno di un ID AMI in un modello di avvio. + Non riceverai una notifica nella console quando è disponibile una versione AMI più recente. Per aggiornare il gruppo di nodi a una versione AMI più recente, devi creare una nuova versione del modello di avvio con un ID AMI aggiornato. Quindi, è necessario aggiornare il gruppo di nodi con la nuova versione del modello di avvio. + I seguenti campi non possono essere impostati nell’API se si specifica un ID AMI: + `amiType` + `releaseVersion` + `version` + Se si specifica un ID AMI, qualsiasi set di `taints` nell'API viene applicato in modo asincrono. Per applicare i taint prima che un nodo si unisca al cluster, è necessario passare i taint a `kubelet` utilizzando il flag della riga di comando `--register-with-taints`. Per ulteriori informazioni, consulta [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) nella documentazione Kubernetes. + Quando specifichi un ID AMI personalizzato per i gruppi di nodi gestiti da Windows, aggiungilo `eks:kube-proxy-windows` alla mappa di configurazione di AWS IAM Authenticator. Questa API è necessaria per il funzionamento di DNS. 1. Apri la mappa di configurazione di AWS IAM Authenticator per modificarla. ``` kubectl edit -n kube-system cm aws-auth ``` 1. Aggiungi questa voce all’elenco `groups` sotto ogni `rolearn` associato ai nodi Windows. [La tua mappa di configurazione dovrebbe essere simile a aws-auth-cm-windows .yaml.](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml) ``` - eks:kube-proxy-windows ``` 1. Salva il file ed esci dall’editor di testo. + Per ogni AMI che utilizza un modello di avvio personalizzato, l’impostazione predefinita `HttpPutResponseHopLimit` per i gruppi di nodi gestiti è impostata su `2`.