Personalizza i nodi gestiti con modelli di lancio - Amazon EKS

Aiutaci 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à.

Personalizza i nodi gestiti con modelli di lancio

Per ottenere il massimo livello di personalizzazione, è possibile implementare i nodi gestiti utilizzando il proprio modello di avvio. L'utilizzo di un modello di avvio consente funzionalità come le seguenti:

  • Fornisci argomenti di bootstrap durante l'implementazione di un nodo, ad esempio argomenti kubelet aggiuntivi.

  • Assegna gli indirizzi IP ai Pod da un blocco CIDR diverso dall'indirizzo IP assegnato al nodo.

  • Implementa la tua AMI personalizzata sui nodi.

  • Implementa il tuo 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 distribuiti con un modello di avvio da utilizzare con il gruppo Amazon EC2 Auto Scaling. Quando non fornisci un modello di lancio, l'API Amazon EKS ne crea uno automaticamente con valori predefiniti nel tuo account. Tuttavia, non è consigliabile modificare i modelli di lancio 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 AWS Management Console AWS CLI o un SDK. AWS Per ulteriori informazioni, consulta Creating a Launch Template for an Auto Scaling group nella Amazon Auto EC2 Scaling User Guide. 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 entrambi i punti. Se un'impostazione esiste dove non dovrebbe, operazioni come la creazione o l'aggiornamento di un gruppo di nodi hanno esito negativo.

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 l'impostazione predefinita Non includere nel modello di avvio l'impostazione 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 le immagini dell'applicazione e del sistema operativo (Amazon Machine Image) non sono state specificate nel modello di avvio, puoi selezionare un'AMI nella configurazione del gruppo di nodi.

Application and OS Images (Amazon Machine Image) (Applicazione e immagini OS [Amazon Machine Image]) in Launch template contents (Contenuti del modello di avvio): è necessario specificare un ID se soddisfi uno dei seguenti requisiti:

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.

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 lancio e lo usi per distribuire il tuo gruppo di nodi, non puoi specificare alcun tipo di istanza nella console o utilizzare altri strumenti che utilizzano l'API Amazon EKS. Se non specifichi un tipo di istanza in un modello di lancio, nella console o utilizzando altri strumenti che utilizzano l'API Amazon EKS, viene utilizzato il tipo di t3.medium istanza. 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.

  • 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 dell'istanza e dati utente nella Amazon EC2 User Guide. Se si esegue l'implementazione di un gruppo di nodi gestiti senza utilizzare un modello di avvio personalizzato, questo valore viene impostato automaticamente per il gruppo di nodi nel modello di avvio predefinito.

Etichettatura delle istanze Amazon EC2

Puoi utilizzare il TagSpecification parametro di un modello di lancio per specificare quali tag applicare alle EC2 istanze Amazon nel tuo 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

Puoi utilizzare un modello di lancio per specificare gruppi di EC2 sicurezza Amazon personalizzati da applicare alle istanze del tuo 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. Tuttavia, non puoi creare un modello di lancio che specifichi sia il livello di istanza che i gruppi di sicurezza dell'interfaccia di rete. Considerare le seguenti condizioni che si applicano all'utilizzo di gruppi di sicurezza personalizzati con gruppi di nodi gestiti:

  • Quando si utilizza AWS Management Console, 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 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 lancio utilizzando una delle 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 di lavoro non possono entrare a far parte del cluster. Per ulteriori informazioni sulle regole del gruppo di sicurezza, consultare Visualizza i requisiti dei gruppi di sicurezza Amazon EKS per i cluster.

  • Se è necessario l'accesso SSH alle istanze nel gruppo di nodi, includere un gruppo di sicurezza che consenta tale accesso.

Dati EC2 utente Amazon

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 singoli elementi personalizzati AMIs. Per ulteriori informazioni sulle impostazioni disponibili per Bottlerocket, consulta Using user data on. GitHub

Puoi fornire i dati EC2 utente di Amazon nel tuo modello di lancio utilizzando cloud-init quando avvii le tue istanze. Per ulteriori informazioni, consultare la documentazione cloud-init. I dati utente possono essere utilizzati per eseguire operazioni di configurazione comuni. Sono comprese le seguenti opzioni:

I dati EC2 degli utenti Amazon nei modelli di avvio utilizzati con i gruppi di nodi gestiti devono essere nel formato di archivio multiparte MIME per Amazon Linux AMIs e nel formato 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 possa essere avviato o modificato. 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. Se in un modello di avvio viene specificato un ID AMI personalizzato, Amazon EKS non unisce i dati utente.

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.

    • 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 crei un nuovo gruppo di nodi. Un esempio dei parametri minimi richiesti è il seguente apiServerEndpointcertificateAuthority, dove ora cidr sono richiesti e il servizio:

--- 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 viene 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 Amazon EKS. Con AL2 023, 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 sul certificateAuthority serviziocidr, consulta DescribeClusterla pagina Amazon EKS API Reference.

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. È possibile configurare etichette di nodi e taint 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 vengono uniti, la formattazione non viene preservata, ma il contenuto rimane lo stesso. La configurazione fornita nei dati utente sostituisce tutte le impostazioni configurate da Amazon EKS. Quindi, se imposti settings.kubernetes.max-pods osettings.kubernetes.cluster-dns-ip, questi valori nei dati utente vengono 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", { name = "Baz", email = "baz@example.com" }]

  • Intestazioni tra parentesi con chiavi stimate: [foo."bar.baz"]

Dati utente Windows

I dati utente di Windows utilizzano PowerShell comandi. 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 <powershell></powershell> tag.

Nota

Se non è specificato alcun ID AMI nel modello di avvio, non utilizzare lo script Windows Amazon EKS Bootstrap nei dati utente per configurare Amazon EKS.

Di seguito sono riportati dati utente di esempio.

<powershell> Write-Host "Running custom user data script" </powershell>

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.

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 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 esegue spesso la scalabilità interna e orizzontale dei nodi. Per ulteriori informazioni sullo bootstrap.sh script, consulta il file 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 , puoi fare riferimento alle tabelle nelle sezioni seguenti:

  • 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ò superare i 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 Amazon EKS ha consigliato il numero massimo di pod per ogni tipo di EC2 istanza Amazon.

    --- 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 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 lancio

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 esegue spesso la scalabilità interna e orizzontale dei nodi. Per ulteriori informazioni sullo bootstrap.sh script, consulta il file 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 Amazon EKS ha consigliato il numero massimo di pod per ogni tipo di EC2 istanza Amazon.

    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==--

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.

Se desideri specificare un ID AMI Windows personalizzato, tieni presenti 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 ottimizzato. AMIs

  • 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.

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.

    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.

<powershell> [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName my-cluster ` -Base64ClusterCA certificate-authority ` -APIServerEndpoint api-server-endpoint ` -DNSClusterIP service-cidr.10 </powershell>

Per ulteriori informazioni, consulta Amazon Machine Images (AMI) nella Amazon EC2 User Guide. La specifica di build dell'AMI Amazon EKS contiene risorse e script di configurazione per creare un'AMI Amazon EKS personalizzata basata su Amazon Linux. Per ulteriori informazioni, consulta Specifica della build AMI di Amazon EKS su GitHub. Per creare AMIs installazioni personalizzate con altri sistemi operativi, consulta Amazon EKS Sample Custom AMIs on GitHub.

Importante

Quando si specifica un'AMI, Amazon EKS non unisce alcun dato utente. Piuttosto, sei responsabile della fornitura dei bootstrap comandi necessari affinché i nodi entrino a far parte del 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 ricevi notifiche 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 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
    2. Aggiungi questa voce all'groupselenco sotto ciascuno dei nodi rolearn associati a Windows. La tua mappa di configurazione dovrebbe essere simile a aws-auth-cm-windows.yaml.

      - eks:kube-proxy-windows
    3. Salva il file ed esci dall'editor di testo.