Tutorial: rete personalizzata - Amazon EKS

Tutorial: rete personalizzata

Per impostazione predefinita, Amazon VPC CNI plugin for Kubernetes crea interfacce di rete elastiche secondarie (interfacce di rete) per il nodo Amazon EC2 nella stessa sottorete dell'interfaccia di rete primaria del nodo. Inoltre, associa all'interfaccia di rete secondaria gli stessi gruppi di sicurezza associati a quella primaria. È possibile far sì che il plug-in crei interfacce di rete secondarie in una sottorete diversa o associ gruppi di sicurezza diversi alle interfacce di rete secondarie, o entrambe le cose, in base a uno dei motivi riportati di seguito:

  • È disponibile un numero limitato di indirizzi IPv4 nella sottorete in cui si trova l'interfaccia di rete primaria. Ciò potrebbe limitare il numero di pods che è possibile creare nella sottorete. Utilizzando una sottorete diversa per le interfacce di rete secondarie, è possibile aumentare il numero di indirizzi IPv4 disponibili per i pods.

  • Per motivi di sicurezza, i pods dovrebbero usare sottoreti o gruppi di sicurezza diversi rispetto all'interfaccia di rete primaria del nodo.

  • I nodi sono configurati in sottoreti pubbliche e i pods possono essere collocati in sottoreti private. La tabella di instradamento associata a una sottorete pubblica include un percorso a un gateway Internet. La tabella di instradamento associata a una sottorete privata non include una route a un gateway Internet.

Considerazioni

  • Con una rete personalizzata abilitata, nessun indirizzo IP assegnato all'interfaccia di rete primaria viene assegnato ai pods. Solo gli indirizzi IP delle interfacce di rete secondarie vengono assegnati ai pods.

  • Se il cluster utilizza la famiglia IPv6, non è possibile usare la rete personalizzata.

  • Se si prevede di utilizzare una rete personalizzata esclusivamente per ridurre l'esaurimento dell'indirizzo IPv4, è invece possibile creare un cluster tramite la famiglia IPv6. Per ulteriori informazioni, consultare Tutorial: Assegnazione di indirizzi IPv6 a pods e services.

  • I pods implementati nelle sottoreti specificate per le interfacce di rete secondarie possono utilizzare sottoreti e gruppi di sicurezza diversi rispetto all'interfaccia di rete primaria del nodo, a patto che si trovino nello stesso VPC del nodo.

Prerequisiti

  • Scopri come Amazon VPC CNI plugin for Kubernetes crea interfacce di rete secondarie e assegna gli indirizzi IP ai pods. Per ulteriori informazioni, consulta Allocazione di ENI su GitHub.

  • La versione 2.8.6 o successiva o la versione 1.26.3 o successiva della AWS CLI installata e configurata sul dispositivo o nella AWS CloudShell. È possibile verificare la versione corrente con aws --version | cut -d / -f2 | cut -d ' ' -f1. I programmi di gestione dei pacchetti, come yum, apt-get o Homebrew per macOS, spesso sono aggiornati a versioni precedenti della AWS CLI. Per installare la versione più recente, consulta le sezioni Installazione, aggiornamento e disinstallazione di AWS CLI e Configurazione rapida con aws configure nella Guida per l'utente di AWS Command Line Interface. Anche la versione della AWS CLI installata nella AWS CloudShell potrebbe essere di diverse versioni precedenti alla più recente. Per aggiornarla, consulta la sezione Installazione di AWS CLI nella directory principale nella Guida per l'utente di AWS CloudShell.

  • Lo strumento a riga di comando kubectl è installato sul dispositivo o AWS CloudShell. La versione può essere uguale, o immediatamente precedente o successiva, alla versione Kubernetes del cluster. Ad esempio, se la versione del cluster è 1.22, puoi usare kubectl versione 1.21, 1.22 o 1.23. Per installare o aggiornare kubectl, consulta Installazione o aggiornamento di kubectl:

  • Ti consigliamo di completare la procedura descritta in questo argomento in una shell Bash. In alternativa, puoi apportare alcune modifiche alla tua shell per alcuni comandi di script, come i caratteri di continuazione della riga, e per il modo in cui le variabili vengono impostate e utilizzate.

Per questo tutorial ti consigliamo di utilizzare i example values, tranne quando è indicato di sostituirli. Puoi sostituire qualsiasi example value quando si completano i passaggi per un cluster di produzione. Ti consigliamo di completare tutti i passaggi nello stesso terminale, dato che le variabili impostate e utilizzate durante la procedura non sono presenti in terminali diversi.

Fase 1: creazione di un VPC e di un cluster di test

Per creare un cluster

Le procedure seguenti illustrano la creazione di un VPC e un cluster di test, oltre alla configurazione di una rete personalizzata per tale cluster. Ti consigliamo di non utilizzare il cluster di test per i carichi di lavoro di produzione poiché alcune funzionalità da utilizzare con il cluster di produzione non sono trattate in questo argomento. Per ulteriori informazioni, consultare Creazione di un cluster Amazon EKS.

Per implementare le reti personalizzate nel cluster di produzione, passa alla Fase 2: configurazione del VPC.

  1. Definisci alcune variabili da utilizzare nei passaggi rimanenti. Sostituisci region-code con la Regione AWS in cui desideri creare il cluster.

    export cluster_name=my-custom-networking-cluster export region_code=region-code account_id=$(aws sts get-caller-identity --query Account --output text)
  2. Crea un VPC.

    1. Crea un VPC utilizzando un modello AWS CloudFormation di Amazon EKS.

      aws cloudformation create-stack --region $region_code --stack-name my-eks-custom-networking-vpc \ --template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \ --parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \ ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \ ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \ ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \ ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27

      La creazione dello stack AWS CloudFormation richiede alcuni minuti. Utilizza il comando seguente per verificare lo stato di implementazione dello stack.

      aws cloudformation describe-stacks --region $region_code --stack-name my-eks-custom-networking-vpc \ --query Stacks[].StackStatus --output text

      Non passare alla fase successiva finché l'output del comando non è CREATE_COMPLETE.

    2. Definisci le variabili con i valori degli ID delle sottoreti private creati dal modello.

      subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc --region $region_code \ --query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text) subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc --region $region_code \ --query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
    3. Definisci le variabili con le zone di disponibilità delle sottoreti recuperate nel passaggio precedente.

      az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --region $region_code --query 'Subnets[*].AvailabilityZone' --output text) az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --region $region_code --query 'Subnets[*].AvailabilityZone' --output text)
  3. Crea un ruolo IAM del cluster.

    1. Per creare un file JSON della policy di attendibilità IAM, esegui il comando seguente.

      cat >eks-cluster-role-trust-policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF
    2. Crea il ruolo IAM del cluster Amazon EKS. Se necessario, inserisci il prefisso eks-cluster-role-trust-policy.json nel percorso del computer in cui hai eseguito la scrittura del file nella fase precedente. Il comando associa il criterio di attendibilità creato nel passaggio precedente al ruolo. Per creare un ruolo IAM, è necessario assegnare all'entità IAM (utente o ruolo) che sta creando il ruolo l'azione IAM (autorizzazione) seguente:iam:CreateRole.

      aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
    3. Allega al ruolo la policy gestita da Amazon EKS, denominata AmazonEKSClusterPolicy. Per allegare una policy IAM a un'entità IAM (utente o ruolo), è necessario assegnare all'entità che sta allegando il criterio una delle azioni IAM (autorizzazioni) seguenti: iam:AttachUserPolicy o iam:AttachRolePolicy.

      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
  4. Crea un cluster Amazon EKS e configura il dispositivo per comunicare con esso.

    1. Crea un cluster.

      aws eks create-cluster --region $region_code --name my-custom-networking-cluster \ --role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \ --resources-vpc-config subnetIds=$subnet_id_1","$subnet_id_2
      Nota

      Potresti ricevere un errore che indica che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l'output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consultare Capacità insufficiente.

    2. La creazione del cluster richiede diversi minuti. Utilizza il comando seguente per verificare lo stato di implementazione del cluster.

      aws eks describe-cluster --region $region_code --name my-custom-networking-cluster --query cluster.status

      Non passare alla fase successiva finché l'output del comando non è ACTIVE.

    3. Configura kubectl per comunicare con il cluster.

      aws eks update-kubeconfig --region $region_code --name my-custom-networking-cluster

Fase 2: configurazione del VPC

Questo tutorial richiede il VPC creato nella Fase 1: creazione di un VPC e di un cluster di test. Per un cluster di produzione, modificare i passaggi in base al VPC, sostituendo tutti i example values con i propri.

  1. Esegui il comando riportato di seguito per confermare che la versione del plug-in CNI di Amazon VPC attualmente installata sia 1.6.3-eksbuild.2 o successiva.

    kubectl describe daemonset aws-node -n kube-system | grep amazon-k8s-cni: | cut -d "/" -f 2

    Di seguito è riportato l'output di esempio.

    amazon-k8s-cni:v1.11.4-eksbuild.1

    Se la versione è precedente alla 1.6.3-eksbuild.2, è necessario aggiornarla. Per ulteriori informazioni, consultare le sezioni sugli aggiornamenti di Gestione del componente aggiuntivo Amazon VPC CNI plugin for Kubernetes.

  2. Recupera l'ID del VPC in cui si trova il cluster e memorizzarlo in una variabile per l'utilizzo nei passaggi successivi. Per un cluster di produzione, sostituisci my-custom-networking-cluster con il nome del cluster.

    vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --region $region_code --query "cluster.resourcesVpcConfig.vpcId" --output text)
  3. Associa un blocco di instradamento interdominio senza classi (CIDR) aggiuntivo al VPC del cluster. Il blocco CIDR non può sovrapporsi a blocchi CIDR esistenti già associati.

    1. Visualizza i blocchi CIDR attualmente associati al tuo VPC.

      aws ec2 describe-vpcs --vpc-ids $vpc_id --region $region_code \ --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      Di seguito è riportato l'output di esempio.

      ---------------------------------- | DescribeVpcs | +-----------------+--------------+ | CIDRBlock | State | +-----------------+--------------+ | 192.168.0.0/24 | associated | +-----------------+--------------+
    2. Associa un blocco CIDR aggiuntivo al VPC. Per ulteriori informazioni, consulta Associazione di blocchi CIDR IPv4 aggiuntivi al VPC nella Guida per l'utente di Amazon VPC.

      aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --region $region_code --cidr-block 192.168.1.0/24
    3. Verifica che il nuovo blocco sia associato.

      aws ec2 describe-vpcs --vpc-ids $vpc_id --region $region_code \ --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table

      Di seguito è riportato l'output di esempio.

      ---------------------------------- | DescribeVpcs | +-----------------+--------------+ | CIDRBlock | State | +-----------------+--------------+ | 192.168.0.0/24 | associated | | 192.168.1.0/24 | associated | +-----------------+--------------+

    Non andare al passaggio successivo finché il nuovo State del blocco CIDR non è associated.

  4. Crea tutte le sottoreti che vuoi utilizzare in ogni zona di disponibilità in cui si trovano le sottoreti esistenti. Specifica un blocco CIDR all'interno del blocco CIDR associato al VPC in una fase precedente.

    1. Crea nuove sottoreti. È necessario creare le sottoreti in un blocco CIDR VPC diverso rispetto alle sottoreti esistenti, ma all'interno delle stesse zone di disponibilità. In questo esempio si crea una sottorete nel nuovo blocco CIDR in ogni zona di disponibilità in cui esistono le sottoreti private attuali. Gli ID delle sottoreti create vengono memorizzati in variabili da utilizzare nei passaggi successivi. I valori Name corrispondono a quelli assegnati alle sottoreti create utilizzando il modello Amazon EKS VPC in un passaggio precedente. I nomi non sono obbligatori. È possibile utilizzare nomi diversi.

      new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --region $region_code --availability-zone $az_1 --cidr-block 192.168.1.0/27 \ --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \ --query Subnet.SubnetId --output text) new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --region $region_code --availability-zone $az_2 --cidr-block 192.168.1.32/27 \ --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \ --query Subnet.SubnetId --output text)
      Importante

      Per impostazione predefinita, le nuove sottoreti sono implicitamente associate alla tabella di instradamento principale del VPC. Questa tabella di instradamento consente la comunicazione tra tutte le risorse implementate nel VPC, ad eccezione delle risorse con indirizzi IP esterni ai blocchi CIDR associate al VPC. Per modificare questo comportamento, associa la tabella di instradamento alle sottoreti. Per ulteriori informazioni, consulta Tabelle di instradamento per sottoreti nella Guida per l'utente di Amazon VPC.

    2. Per visualizzare le sottoreti attuali nel tuo VPC.

      aws ec2 describe-subnets --region $region_code --filters "Name=vpc-id,Values=$vpc_id" \ --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \ --output table

      Di seguito è riportato l'output di esempio.

      ---------------------------------------------------------------------- | DescribeSubnets | +------------------+--------------------+----------------------------+ | AvailabilityZone | CidrBlock | SubnetId | +------------------+--------------------+----------------------------+ | us-west-2d | 192.168.0.0/27 | subnet-example1 | | us-west-2a | 192.168.0.32/27 | subnet-example2 | | us-west-2a | 192.168.0.64/27 | subnet-example3 | | us-west-2d | 192.168.0.96/27 | subnet-example4 | | us-west-2a | 192.168.1.0/27 | subnet-example5 | | us-west-2d | 192.168.1.32/27 | subnet-example6 | +------------------+--------------------+----------------------------+

      Come puoi vedere, le sottoreti create nel blocco CIDR 192.168.1.0 si trovano nelle stesse zone di disponibilità di quelle create nel blocco CIDR 192.168.0.0.

Fase 3: configurazione di risorse Kubernetes

Configurazione di risorse Kubernetes

  1. Imposta la variabile di ambiente AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG su true nel aws-node DaemonSet.

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  2. Recupera l'ID del gruppo di sicurezza del cluster e memorizzalo in una variabile da utilizzare nel passaggio successivo. Amazon EKS crea automaticamente questo gruppo di sicurezza durante la creazione del cluster.

    cluster_security_group_id=$(aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
  3. Crea una risorsa personalizzata ENIConfig per ogni sottorete in cui vuoi implementare i pods.

    1. Crea un file univoco per ogni configurazione di interfaccia di rete.

      I comandi seguenti creano file ENIConfig separati per le due sottoreti create in una fase precedente. Il valore di name deve essere univoco. Il nome corrisponde alla zona di disponibilità in cui si trova la sottorete. Il gruppo di sicurezza del cluster viene assegnato a ENIConfig.

      cat >$az_1.yaml <<EOF apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $az_1 spec: securityGroups: - $cluster_security_group_id subnet: $new_subnet_id_1 EOF
      cat >$az_2.yaml <<EOF apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $az_2 spec: securityGroups: - $cluster_security_group_id subnet: $new_subnet_id_2 EOF

      Per un cluster di produzione, puoi apportare le seguenti modifiche ai comandi precedenti:

      • Sostituisci $cluster_security_group_id con l'ID di un gruppo di sicurezza esistente da utilizzare per ciascun ENIConfig.

      • Quando possibile, assegna a ENIConfigs lo stesso nome della zona di disponibilità che utilizzerai per ENIConfig. Per una serie di motivi, tuttavia, potrebbe essere necessario utilizzare nomi diversi per ENIConfigs e le zone di disponibilità. Ad esempio, se nella stessa zona di disponibilità sono presenti più di due sottoreti e si desidera utilizzarle entrambe con reti personalizzate, saranno necessari più ENIConfigs per la stessa zona di disponibilità. Dal momento che ogni ENIConfig richiede un nome univoco, non puoi assegnare lo stesso nome della zona di disponibilità a più ENIConfigs.

        Se i nomi di ENIConfig non sono tutti uguali a quelli delle zone di disponibilità, sostituisci $az_1 e $az_2 con i nomi scelti nei comandi precedenti e prendi nota dei nodi con ENIConfig come descritto più avanti in questo tutorial.

      Nota

      Nel caso in cui non si specifichi un gruppo di sicurezza valido da utilizzare con un cluster di produzione:

      • se si utilizza la versione 1.8.0 o successiva del Amazon VPC CNI plugin for Kubernetes, vengono impiegati i gruppi di sicurezza associati all'interfaccia di rete elastica primaria del nodo.

      • se si utilizza una versione del Amazon VPC CNI plugin for Kubernetes precedente alla 1.8.0, il gruppo di sicurezza di default per il VPC viene assegnato alle interfacce di rete secondarie.

      Importante
      • AWS_VPC_K8S_CNI_EXTERNALSNAT=false è un'impostazione predefinita per la configurazione del plug-in CNI di Amazon VPC per Kubernetes. Per impostazione predefinita, il traffico destinato agli indirizzi IP che non si trovano all'interno di uno dei blocchi CIDR associati al VPC utilizza i gruppi di sicurezza e le sottoreti dell'interfaccia di rete primaria del nodo. Le sottoreti e i gruppi di sicurezza definiti in ENIConfigs al fine di creare interfacce di rete secondarie non vengono utilizzati per questo traffico. Per ulteriori informazioni su questa impostazione, consulta SNAT per pods.

      • Se si utilizzano gruppi di sicurezza anche per i pods, il gruppo di sicurezza specificato in una SecurityGroupPolicy viene utilizzato al posto di quello specificato in ENIConfigs. Per ulteriori informazioni, consultare Tutorial: gruppi di sicurezza per pods.

    2. Applica ogni file delle risorse personalizzato creato in precedenza al cluster con i comandi seguenti.

      kubectl apply -f $az_1.yaml kubectl apply -f $az_2.yaml
  4. Verifica che ENIConfigs sia stato creato.

    kubectl get ENIConfigs

    Di seguito è riportato l'output di esempio.

    NAME AGE us-west-2a 117s us-west-2d 105s
  5. Se stai abilitando la rete personalizzata su un cluster di produzione e hai assegnato a ENIConfigs un nome diverso da quello dalla zona di disponibilità per cui lo stai utilizzando, passa alla fase successiva per implementare i nodi Amazon EC2.

    Consenti a Kubernetes di applicare automaticamente ENIConfig per una zona di disponibilità a tutti i nuovi nodi Amazon EC2 creati nel cluster.

    1. Per il cluster di test in questo tutorial, passa alla fase successiva.

      Per il cluster di produzione, verifica la presenza di un'annotation con il codice k8s.amazonaws.com/eniConfig per la variabile di ambiente ENI_CONFIG_ANNOTATION_DEF nelle specifiche del container per aws-node DaemonSet.

      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF

      Se viene restituito un output, l'annotazione è presente. Se non viene restituito alcun output, la variabile non viene impostata. Per un cluster di produzione, puoi scegliere di utilizzare la presente impostazione o quella riportata nel passaggio successivo. L'utilizzo di questa impostazione sovrascrive quella del passaggio successivo. In questo tutorial viene utilizzata l'impostazione riportata nel passaggio successivo.

    2. Aggiorna il tuo aws-node DaemonSet per applicare automaticamente ENIConfig per una zona di disponibilità a tutti i nuovi nodi Amazon EC2 creati nel cluster.

      kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone

Fase 4: implementazione di nodi Amazon EC2

Per implementare i nodi Amazon EC2

  1. Creare un ruolo IAM del nodo.

    1. Per creare un file JSON della policy di attendibilità IAM, esegui il comando seguente.

      cat >node-role-trust-relationship.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF
    2. Eseguire questo comando per impostare una variabile per il nome del ruolo. Puoi sostituire myCustomNetworkingAmazonEKSNodeRole con un nome a tua scelta.

      export node_role_name=myCustomNetworkingAmazonEKSNodeRole
    3. Crea il ruolo IAM e memorizza il nome della risorsa Amazon (ARN) restituito in una variabile da utilizzare in una fase successiva.

      node_role_arn=$(aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json" \ --query Role.Arn --output text)
    4. Allega al ruolo IAM le tre policy gestite IAM richieste.

      aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \ --role-name $node_role_name aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \ --role-name $node_role_name aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \ --role-name $node_role_name
      Importante

      Per semplicità, in questo tutorial la policy AmazonEKS_CNI_Policy è allegata al ruolo IAM del nodo. Tuttavia, in un cluster di produzione, si consiglia di allegare la policy a un ruolo IAM separato da utilizzare solo con Amazon VPC CNI plugin for Kubernetes. Per ulteriori informazioni, consultare Configurazione del Amazon VPC CNI plugin for Kubernetes per l'utilizzo dei ruoli IAM per gli account di servizio.

  2. Creare uno dei seguenti tipi di gruppi di nodi. Per determinare il tipo di istanza da implementare, consulta Scelta di un tipo di istanza Amazon EC2. Per questo tutorial, utilizza l'opzione Gestito, senza un modello di avvio o con un modello di avvio senza un ID AMI specificato. Se prevedi di utilizzare il gruppo di nodi per i carichi di lavoro di produzione, ti consigliamo di familiarizzare con tutte le opzioni del gruppo di nodi gestito e autogestito prima di implementare il gruppo di nodi.

    • Gestito: implementare il gruppo di nodi utilizzando una delle opzioni seguenti:

      • Senza un modello di avvio o con un modello di avvio senza un ID AMI specificato: esegui il comando seguente. Per questo tutorial, utilizza i example values. Per un gruppo di nodi di produzione, sostituisci tutti i example values con i tuoi.

        aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name my-nodegroup \ --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
      • Con un modello di avvio con un ID AMI specificato

        1. Determina il numero massimo di pods consigliato da Amazon EKS per i nodi. Segui le istruzioni riportate in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di pods, aggiungendo --cni-custom-networking-enabled alla fase 3 di questo argomento. Annota l'output restituito per l'utilizzo in un passaggio successivo.

        2. Nel modello di avvio, specifica un ID AMI ottimizzato per Amazon EKS o un'AMI personalizzata sviluppata con l'AMI ottimizzato per Amazon EKS, quindi implementa il gruppo di nodi utilizzando un modello di avvio e fornisci i seguenti dati utente nel modello di avvio. Questi dati utente passano argomenti nel file bootstrap.sh. Per ulteriori informazioni sul file bootstrap, consulta bootstrap.sh su GitHub. Puoi sostituire 20 con il valore del passaggio precedente (consigliato) o con un tuo valore desiderato.

          /etc/eks/bootstrap.sh my-cluster --use-max-pods false --kubelet-extra-args '--max-pods=20'

          Se si è creata un'AMI personalizzata che non è stata sviluppata con l'AMI ottimizzata per Amazon EKS, bisogna creare autonomamente la configurazione.

    • Autogestito

      1. Determina il numero massimo di pods consigliato da Amazon EKS per i nodi. Segui le istruzioni riportate in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di pods, aggiungendo --cni-custom-networking-enabled alla fase 3 di questo argomento. Annota l'output restituito per l'utilizzo in un passaggio successivo.

      2. Implementa il gruppo di nodi utilizzando le istruzioni in Avvio di nodi Amazon Linux autogestiti. Specificare il seguente testo per il parametro BootstrapArguments. Puoi sostituire 20 con il valore del passaggio precedente (consigliato) o con un tuo valore desiderato.

        --use-max-pods false --kubelet-extra-args '--max-pods=20'
    Nota

    Se vuoi che i nodi presenti in un cluster di produzione supportino un numero significativamente più elevato di pods, esegui nuovamente lo script in Per ogni tipo di istanza Amazon EC2, Amazon EKS consiglia un numero massimo di pods. Aggiungi inoltre l'opzione --cni-prefix-delegation-enabled al comando. Ad esempio, per un tipo di istanza m5.large viene restituito 110. Per istruzioni su come abilitare questa funzionalità, consulta Aumentare la quantità di indirizzi IP disponibili per i nodi Amazon EC2. Puoi utilizzare questa funzionalità con una rete personalizzata.

    La creazione di gruppi di nodi richiede diversi minuti. Puoi verificare lo stato della creazione di un gruppo di nodi gestiti con il comando seguente.

    aws eks describe-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

    Non andare al passaggio successivo finché l'output restituito non è ACTIVE.

  3. Ai fini di questo tutorial, puoi ignorare questo passaggio.

    Per un cluster di produzione, se hai assegnato a ENIConfigs un nome diverso da quello della zona di disponibilità in cui lo stai utilizzando, devi annotare i nodi con il nome ENIConfig da utilizzare con il nodo. Questo passaggio non è necessario se disponi di una sola sottorete in ogni zona di disponibilità e hai assegnato a ENIConfigs gli stessi nomi delle zone di disponibilità. Questo perché il Amazon VPC CNI plugin for Kubernetes associa automaticamente il ENIConfig corretto al nodo se questa opzione è stata abilitata in una fase precedente.

    1. Ottieni l'elenco dei nodi nel cluster.

      kubectl get nodes

      Di seguito è riportato l'output di esempio.

      NAME STATUS ROLES AGE VERSION ip-192-168-0-126.us-west-2.compute.internal Ready <none> 8m49s v1.22.9-eks-810597c ip-192-168-0-92.us-west-2.compute.internal Ready <none> 8m34s v1.22.9-eks-810597c
    2. Determina in quale zona di disponibilità si trova ogni nodo. Esegui il comando seguente per ogni nodo restituito nel passaggio precedente.

      aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \ --query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'

      Di seguito è riportato l'output di esempio.

      [ { "AvailabilityZone": "us-west-2d", "SubnetId": "subnet-Example5" } ]
    3. Annota ogni nodo con la risorsa ENIConfig creata per l'ID della sottorete e la zona di disponibilità. Puoi annotare solo un nodo con un ENIConfig, ma più nodi con lo stesso ENIConfig. Sostituire il example values con quello in proprio possesso.

      kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1 kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
  4. Se in un cluster di produzione erano presenti nodi con pods in esecuzione prima di passare all'utilizzo della funzionalità di rete personalizzata, completa le attività seguenti:

    1. Assicurati di avere dei nodi disponibili abilitati per la funzionalità di rete personalizzata.

    2. Cordonare ed espellere i nodi per interrompere normalmente i pods. Per ulteriori informazioni, consulta Espulsione di un nodo in modo sicuro nella documentazione di Kubernetes.

    3. Termina i nodi. Se i nodi si trovano in un gruppo di nodi gestito esistente, puoi eliminare il gruppo di nodi. Sostituire il example values con quello in proprio possesso.

      aws eks delete-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup

    Solo i nuovi nodi registrati con l'etichetta k8s.amazonaws.com/eniConfig useranno la nuova funzionalità di rete personalizzata.

  5. Verifica che ai pods venga assegnato un indirizzo IP da un blocco CIDR associato a una delle sottoreti create in una fase precedente.

    kubectl get pods -A -o wide

    Di seguito è riportato l'output di esempio.

    NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.93 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.108 ip-192-168-0-126.us-west-2.compute.internal <none> <none> kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.93 ip-192-168-0-92.us-west-2.compute.internal <none> <none> kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.108 ip-192-168-0-126.us-west-2.compute.internal <none> <none>

    Ai pods coredns vengono assegnati indirizzi IP dal blocco CIDR 192.168.1.0 aggiunto al VPC. Senza una rete personalizzata, ai pod sarebbero stati assegnati indirizzi provenienti dall'unico blocco CIDR originariamente associato al VPC, ossia il blocco CIDR 192.168.0.0.

    Se una spec del pod's contiene il valore hostNetwork=true, viene assegnato l'indirizzo IP principale del nodo, non un indirizzo proveniente dalle sottoreti aggiunte. Per impostazione predefinita, questo valore è impostato su false. Questo valore è impostato su true per i pods kube-proxy e Amazon VPC CNI plugin for Kubernetes (aws-node) in esecuzione nel cluster. Per questo motivo al kube-proxy e ai pods aws-node del plug-in non vengono assegnati indirizzi 192.168.1.x nell'output precedente. Per ulteriori informazioni sull'impostazione di un hostNetwork per i pod's, consulta PodSpec v1 core nella documentazione di riferimento delle API di Kubernetes.

Fase 5: eliminazione delle risorse del tutorial

Ti consigliamo di eliminare le risorse create dopo aver completato il tutorial. In seguito, potrai modificare i passaggi per abilitare la rete personalizzata di un cluster di produzione.

Per eliminare le risorse del tutorial

  1. Se il gruppo di nodi creato era solo a scopo di test, eliminalo.

    aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name my-nodegroup

    Il processo di eliminazione del cluster potrebbe non essere effettivamente completo anche dopo la visualizzazione dell'output AWS CLI. Questo processo di eliminazione richiede alcuni minuti. Verifica che il processo sia completo con il comando seguente.

    aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

    Non continuare finché l'output restituito non è simile al seguente.

    An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
  2. Se il gruppo di nodi creato era solo a scopo di test, elimina il ruolo IAM del nodo.

    1. Scollega le policy dal ruolo.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
    2. Elimina il ruolo.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSNodeRole
  3. Elimina il cluster.

    aws eks delete-cluster --region $region_code --name $cluster_name

    Verifica l'eliminazione del cluster con il comando seguente.

    aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status --output text

    Quando viene restituito un output simile al seguente, il cluster è stato eliminato correttamente.

    An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
  4. Elimina il ruolo IAM del cluster.

    1. Scollega le policy dal ruolo.

      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
    2. Elimina il ruolo.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
  5. Elimina le sottoreti create in una fase precedente.

    aws ec2 delete-subnet --region $region_code --subnet-id $new_subnet_id_1 aws ec2 delete-subnet --region $region_code --subnet-id $new_subnet_id_2
  6. Elimina il VPC creato.

    aws cloudformation delete-stack --region $region_code --stack-name my-eks-custom-networking-vpc