Creazione di una classe di nodi per Amazon EKS

Le classi di nodi Amazon EKS sono modelli che forniscono un controllo granulare sulla configurazione dei nodi gestiti dalla modalità automatica di EKS. Una classe di nodi definisce le impostazioni a livello di infrastruttura che si applicano ai gruppi di nodi del cluster EKS, tra cui la configurazione di rete, le impostazioni di storage e il tagging delle risorse. Questo argomento mostra come creare e configurare una classe di nodi per soddisfare i tuoi requisiti operativi specifici.

Quando è necessario personalizzare le modalità di provisioning e configurazione delle istanze EC2 da parte della modalità automatica di EKS oltre le impostazioni predefinite, la creazione di una classe di nodi fornisce un controllo preciso sui parametri critici dell’infrastruttura. Ad esempio, è possibile specificare il posizionamento di sottoreti private per una maggiore sicurezza, configurare lo storage temporaneo delle istanze per carichi di lavoro sensibili alle prestazioni o applicare tag personalizzati per l’allocazione dei costi.

Considerazioni per carichi di lavoro sparsi o su larga scala

La modalità automatica EKS utilizza la delega dei prefissi (prefissi) per impostazione predefinita. /28 Ogni nodo riserva 16 IP pod, una soluzione efficace per carichi di lavoro ad alta densità di pod che occupano tali slot. Per i carichi di lavoro pod-sparse (pochi pod per nodo, comuni nei carichi di lavoro ML o GPU, o carichi di lavoro antiaffinity pesanti) destinati a più di qualche centinaio di nodi per zona di disponibilità, la modalità IP secondaria () è una configurazione più ottimizzata. "32" Assegna un IP per pod anziché riservarne 16 per nodo, il che estende la capacità effettiva delle sottoreti pod. /20

Per ulteriori informazioni, consulta Modalità IP secondaria per pod. Per mantenere i pod in una sottorete separata dai nodi (indipendentemente dalla modalità di allocazione), vedere. Sottoreti e gruppi di sicurezza separati per i Pods

Creazione di una classe di nodi

Per creare una NodeClass, segui questi passaggi:

1. Crea un file YAML (ad esempio, nodeclass.yaml) con la configurazione della classe di nodi

2. Applica la configurazione al cluster utilizzando kubectl

3. Fai riferimento alla classe di nodi nella configurazione del tuo pool di nodi. Per ulteriori informazioni, consulta Crea un pool di nodi per la modalità automatica di EKS.

kubectl deve essere installato e configurato. Per ulteriori informazioni, consulta Configurazione per l’utilizzo di Amazon EKS.

Esempio di classe di nodi di base

Ecco un esempio di classe di nodi:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-compute
spec:
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
  ephemeralStorage:
    size: "160Gi"

Ciò NodeClass aumenta la quantità di spazio di archiviazione temporaneo sul nodo.

Applica questa configurazione usando:

kubectl apply -f nodeclass.yaml

Poi fai riferimento alla classe di nodi nella configurazione del pool di nodi. Per ulteriori informazioni, consulta Crea un pool di nodi per la modalità automatica di EKS.

Creazione di una voce di accesso alla classe di nodi

Se crei una classe di nodi personalizzata, devi creare una voce di accesso EKS per consentire ai nodi di unirsi al cluster. Quando si utilizzano la classe di nodi e i pool di nodi integrati, EKS crea automaticamente le voci di accesso.

Per informazioni sul funzionamento delle voci di accesso, consulta Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS.

Quando si creano voci di accesso per le classi di nodi della modalità automatica di EKS, è necessario usare il tipo di voce di accesso EC2.

Creazione di un accesso con CLI

Per creare una voce di accesso per i nodi EC2 e associare la policy dei nodi di EKS Auto:

Aggiorna i comandi CLI seguenti con il nome del cluster e l’ARN del ruolo del nodo. Il ruolo del nodo ARN viene specificato nella classe di nodi YAML.

# Create the access entry for EC2 nodes
aws eks create-access-entry \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --type EC2

# Associate the auto node policy
aws eks associate-access-policy \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
  --access-scope type=cluster

Crea una voce di accesso con CloudFormation

Per creare una voce di accesso per i nodi EC2 e associare la policy dei nodi di EKS Auto:

Aggiorna quanto segue CloudFormation con il nome del cluster e l'ARN del ruolo del nodo. Il ruolo del nodo ARN viene specificato nella classe di nodi YAML.

EKSAutoNodeRoleAccessEntry:
  Type: AWS::EKS::AccessEntry
  Properties:
    ClusterName: <cluster-name>
    PrincipalArn: <node-role-arn>
    Type: "EC2"
    AccessPolicies:
      - AccessScope:
          Type: cluster
        PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
  DependsOn: [ <cluster-name> ] # previously defined in CloudFormation

Per informazioni sulla distribuzione degli CloudFormation stack, vedi Guida introduttiva con CloudFormation

Specifiche della classe di nodi

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: my-node-class
spec:
  # Required fields

  # role and instanceProfile are mutually exclusive fields.
  role: MyNodeRole  # IAM role for EC2 instances
  # instanceProfile: eks-MyNodeInstanceProfile  # IAM instance-profile for EC2 instances

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0123456789abcdef0"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
    # Alternative approaches:
    # - id: "sg-0123456789abcdef0"
    # - name: "eks-cluster-security-group"

  # Optional: Pod subnet selector for advanced networking
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0987654321fedcba0"
  # must include Pod security group selector also
  podSecurityGroupSelectorTerms:
    - tags:
        Name: "eks-pod-sg"
    # Alternative using direct security group ID
    # - id: "sg-0123456789abcdef0"

  # Optional: Selects on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        Name: "targeted-odcr"
      # Optional owning account ID filter
      owner: "012345678901"

  # Optional fields
  snatPolicy: Random  # or Disabled

  networkPolicy: DefaultAllow  # or DefaultDeny
  networkPolicyEventLogs: Disabled  # or Enabled

  ephemeralStorage:
    size: "80Gi"    # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
    iops: 3000      # Range: 3000-16000
    throughput: 125 # Range: 125-1000
    # Optional KMS key for encryption
    kmsKeyID: "arn:aws: kms:region:account:key/key-id"
    # Accepted formats:
    # KMS Key ID
    # KMS Key ARN
    # Key Alias Name
    # Key Alias ARN

  advancedNetworking:
    # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
    # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
    associatePublicIPAddress: false

    # Optional: Forward proxy, commonly requires certificateBundles as well
    # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
    httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
    #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
    noProxy: #Max 50 entries
        - localhost #Max 255 characters each
        - 127.0.0.1
        #- ::1 # IPv6 localhost
        #- 0:0:0:0:0:0:0:1 # IPv6 localhost
        - 169.254.169.254 # EC2 Instance Metadata Service
        #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
        # Domains to exclude, put all VPC endpoints here
        - .internal
        - .eks.amazonaws.com
    # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
    ipv4PrefixSize: Auto # or "32"

    # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
    enableV4Egress: false

    # Optional: Static network interface configuration for EFA workloads
    networkInterfaces:
      # The primary ENI (networkCardIndex 0, deviceIndex 0) must use interfaceType: interface
      # secondaryIPv4Count and secondaryIPv4PrefixCount are only supported on networkCardIndex 0
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4Count: 10
    - deviceIndex: 1
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 2 # Only one of secondaryIPv4Count or secondaryIPv4PrefixCount per ENI
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1

  advancedSecurity:
    # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
    fips: false

  # Optional: Custom certificate bundles.
  certificateBundles:
    - name: "custom-cert"
      data: "base64-encoded-cert-data"

  # Optional: EC2 Placement Group
  placementGroupSelector:
    name: "targeted-pg"
    # Alternative use direct placement group ID
    # id: "pg-02465754522cda020"

  # Optional: Additional EC2 tags (with restrictions)
  tags:
    Environment: "production"
    Team: "platform"
    # Note: Cannot use restricted tags like:
    # - kubernetes.io/cluster/*
    # - karpenter.sh/provisioner-name
    # - karpenter.sh/nodepool
    # - karpenter.sh/nodeclaim
    # - karpenter.sh/managed-by
    # - eks.amazonaws.com/nodeclass

Considerazioni

• Se vuoi verificare la quantità di storage locale di cui dispone un’istanza, puoi descrivere il nodo per visualizzare la risorsa di storage temporaneo.

• Crittografia dei volumi: EKS utilizza la chiave KMS personalizzata configurata per crittografare il volume principale di sola lettura dell'istanza e il volume di dati. read/write

• Sostituisci il ruolo IAM del nodo: se modifichi il ruolo IAM del nodo associato a NodeClass, dovrai creare una nuova voce d’accesso. EKS crea automaticamente una voce d’accesso per il ruolo IAM del nodo durante la creazione del cluster. Il ruolo IAM del nodo richiede la policy di accesso di AmazonEKSAutoNodePolicy EKS. Per ulteriori informazioni, consulta Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS.

• densità massima di pod: EKS limita il numero massimo di pod su un nodo a 110. Questo limite viene applicato dopo il calcolo del numero massimo di pod attuale. Per ulteriori informazioni, consulta Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale.

• Tag: se vuoi propagare i tag da Kubernetes a EC2, devi configurare autorizzazioni IAM aggiuntive. Per ulteriori informazioni, consulta Informazioni su identità e accesso in modalità automatica di EKS.

• Classe di nodi predefinita: non assegnare un nome alla classe di nodi default personalizzata. Questo perché la modalità automatica di EKS include una NodeClass denominata default che viene fornita automaticamente quando si abilita almeno un NodePool integrato. Per informazioni sull’abilitazione dei NodePools, consulta Attivazione o disattivazione Built-in NodePools.

• comportamento di subnetSelectorTerms con più sottoreti: se esistono più sottoreti che soddisfano le condizioni di subnetSelectorTerms o che vengono fornite tramite ID, la modalità automatica di EKS crea nodi distribuiti tra le sottoreti.

  • Se le sottoreti si trovano in zone di disponibilità (AZ) diverse, è possibile usare funzionalità di Kubernetes come i vincoli di distribuzione della topologia dei pod e il routing basato sulla topologia per distribuire rispettivamente i pod e il traffico tra le zone.

  • Se nella stessa AZ sono presenti più sottoreti che corrispondono al subnetSelectorTerms, la modalità automatica di EKS crea pod su ciascun nodo distribuito tra le sottoreti in quella AZ. La modalità automatica di EKS crea interfacce di rete secondarie su ogni nodo nelle altre sottoreti della stessa AZ. Decide in base al numero di indirizzi IP disponibili in ciascuna sottorete, per usare le sottoreti in modo più efficiente. Non è tuttavia possibile specificare quale sottorete viene usata dalla modalità automatica di EKS per ogni Pod; se hai bisogno che i Pod funzionino in sottoreti specifiche, usa Sottoreti e gruppi di sicurezza separati per i Pods.

• Restrizioni relative alla strategia dei gruppi di collocamento: ogni strategia di gruppo di collocamento (cluster, partizione, spread) presenta limitazioni specifiche sui tipi di istanze, sugli AZ e sulla capacità. Per i dettagli, consulta le strategie dei gruppi di collocamento nella Amazon EC2 User Guide.

• Gruppo di spread placement — limite di 7 istanze: un gruppo di spread placement a livello di rack consente un massimo di 7 istanze in esecuzione per zona di disponibilità per gruppo. Ciò crea i seguenti casi limite:

  • Sostituzione Drift bloccata al massimo della capacità: EKS Auto Mode avvia un nodo sostitutivo prima di terminare quello precedente. Quando un PG diffuso ha 7 istanze in un AZ, l'avvio sostitutivo fallisce e il nodo drifted rimane in funzione fino a quando non si libera uno slot.

  • Tutti gli AZ al massimo della loro capacità: se ogni AZ nello spread PG è al limite di 7 istanze, non è possibile programmare alcuna sostituzione. I nodi Drifted o candidati al consolidamento restano in funzione a tempo indeterminato.

  • Nessun fallback all'esterno del gruppo di posizionamento: EKS Auto Mode non tenta di avviare istanze sostitutive all'esterno del gruppo di posizionamento.

  • Soluzione alternativa: utilizzare la politica di WhenEmpty consolidamento (). consolidationPolicy: WhenEmpty I nodi vengono eliminati solo dopo che tutti i pod non appartenenti a daemonset si sono esauriti, liberando uno slot PG senza dover prima avviare un altro server sostitutivo. Nota che drift utilizza sempre replace-then-delete indipendentemente dalla politica di consolidamento, quindi drift rimane bloccato al massimo della capacità.

• Blocco AZ del gruppo di posizionamento del cluster: una volta che la prima istanza viene lanciata in un gruppo di posizionamento del cluster, il PG viene aggiunto a quell'AZ. Se NodePool consentite più AZ, i lanci paralleli durante lo scale-up iniziale potrebbero avere esito negativo: uno riesce e blocca l'AZ, gli altri falliscono a causa di errori di capacità. Inserite la AZ nelle vostre NodePool esigenze per evitare guasti transitori.

• Gruppo di posizionamento delle partizioni: i gruppi di posizionamento delle partizioni sono supportati senza vincoli aggiuntivi oltre ai limiti standard EC2.

• Il consolidamento può spostare i pod fuori da un gruppo di collocamento: se un pod non ha vincoli di pianificazione relativi al gruppo di posizionamento (ad esempio attivoeks.amazonaws.com/placement-group-id), il consolidamento può spostarlo nodeSelector in un nodo esterno al PG. Le applicazioni che richiedono l'appartenenza a un gruppo di collocamento devono esprimerlo tramite vincoli a livello di pod.

• Gruppo di posizionamento inesistente o eliminato: se un NodeClass fa riferimento a un gruppo di posizionamento che non esiste o è stato eliminato, non viene avviata alcuna istanza. Il formato ID del gruppo di collocamento viene convalidato al momento dell'ammissione, ma l'esistenza viene verificata solo al momento dell'avvio. Se un gruppo di posizionamento viene eliminato mentre i nodi sono in esecuzione, i nodi esistenti vengono contrassegnati come drifted e rimangono in esecuzione a tempo indeterminato perché anche i lanci di Drift Replacement sono bloccati.

• Hugepages: per informazioni sulla configurazione di hugepages sui nodi, consulta. Configura enormi pagine sui nodi

• Impostazioni Kubelet: per informazioni su come sovrascrivere le impostazioni di Kubelet come la densità dei pod, le soglie di sfratto e la rotazione dei log, vedi. Configura le impostazioni kubelet sui nodi

• Kernel sysctls — Per informazioni sulla configurazione del kernel sysctls sui nodi, vedi. Configura sysctls del kernel sui nodi

Sottoreti e gruppi di sicurezza separati per i Pods

I podSecurityGroupSelectorTerms campi podSubnetSelectorTerms and consentono configurazioni di rete avanzate consentendo ai Pods di utilizzare sottoreti e gruppi di sicurezza diversi rispetto ai rispettivi nodi. Entrambi i campi devono essere specificati insieme. Questa separazione offre maggiore controllo sul routing del traffico di rete e sulle policy di sicurezza.

Nota

Questa funzionalità è diversa dalla funzionalità Security Groups for Pods (SGPP) utilizzata con il VPC CNI per il calcolo in modalità automatica non EKS. SGPP non è supportato nella modalità EKS Auto. Utilizza invece podSecurityGroupSelectorTerms in NodeClass per applicare gruppi di sicurezza separati al traffico Pod. I gruppi di sicurezza si applicano a NodeClass livello, il che significa che tutti i Pod sui nodi che utilizzano NodeClass condividono gli stessi gruppi di sicurezza Pod.

Come funziona

Quando configuri podSubnetSelectorTerms epodSecurityGroupSelectorTerms:

1. L'ENI primario del nodo utilizza le sottoreti e i gruppi di sicurezza di e. subnetSelectorTerms securityGroupSelectorTerms A questa interfaccia viene assegnato solo l'indirizzo IP del nodo.

2. EKS Auto Mode crea ENI secondari nelle sottoreti corrispondentipodSubnetSelectorTerms, con i gruppi di sicurezza collegati. podSecurityGroupSelectorTerms Gli indirizzi IP dei pod vengono allocati da questi ENI secondari utilizzando i prefissi /28 per impostazione predefinita, con riserva automatica agli IP secondari (/32) quando non è disponibile un blocco di prefisso contiguo. Se ipv4PrefixSize è impostato su in, vengono utilizzati solo gli IP secondari. "32" advancedNetworking

3. I gruppi di sicurezza specificati in podSecurityGroupSelectorTerms si applicano al traffico Pod all'interno del VPC. Per il traffico destinato all'esterno del VPC, i Pods utilizzano l'ENI primario del nodo (e i relativi gruppi di sicurezza) perché la traduzione degli indirizzi di rete di origine (SNAT) traduce l'IP del Pod nell'IP del nodo. Puoi modificare questo comportamento con il campo in. snatPolicy NodeClass

Casi d’uso

Usa podSubnetSelectorTerms e podSecurityGroupSelectorTerms quando devi:

• Applica diversi gruppi di sicurezza per controllare separatamente il traffico per nodi e pod.

• Separa il traffico dell'infrastruttura (comunicazione da nodo a nodo) dal traffico delle applicazioni (comunicazione). Pod-to-Pod

• Applicare configurazioni di rete diverse alle sottoreti dei nodi rispetto alle sottoreti Pod.

• Configurare i proxy inversi o il filtraggio di rete in modo specifico per il traffico dei nodi senza influire sul traffico dei Pod. Utilizza advancedNetworking e certificateBundles per definire il tuo proxy inverso e qualsiasi certificato autofirmato o privato per il proxy.

Configurazione di esempio

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  # Subnets and security groups for EC2 instances (nodes)
  subnetSelectorTerms:
    - tags:
        Name: "node-subnet"
        kubernetes.io/role/internal-elb: "1"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  # Separate subnets and security groups for Pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

  podSecurityGroupSelectorTerms:
  - tags:
      Name: "eks-pod-sg"

Considerazioni per sottoreti Pod e gruppi di sicurezza separati

• Ambito del gruppo di sicurezza: i gruppi di sicurezza di podSecurityGroupSelectorTerms sono collegati agli ENI secondari e si applicano al traffico Pod all'interno del VPC. Quando SNAT è abilitato (impostazione predefinitasnatPolicy: Random), il traffico in uscita dal VPC viene tradotto nell'indirizzo IP ENI primario del nodo, quindi i gruppi di sicurezza del nodo securityGroupSelectorTerms si applicano invece a quel traffico. Se lo impostisnatPolicy: Disabled, i Pods utilizzano i propri indirizzi IP per tutto il traffico e devi assicurarti che i gruppi di routing e sicurezza siano configurati di conseguenza.

• NodeClass-level granularità: i gruppi di sicurezza dei Pod si applicano a tutti i Pod pianificati sui nodi utilizzando il. NodeClass Per applicare diversi gruppi di sicurezza a diversi carichi di lavoro, crea NodePool risorse binarie separate NodeClass e utilizza taint, tolleranze o selettori di nodi per pianificare i carichi di lavoro sui nodi appropriati.

• Densità di pod ridotta: è possibile eseguire un numero inferiore di pod su ogni nodo perché l'interfaccia di rete principale del nodo è riservata all'IP del nodo e non può essere utilizzata per i pod.

• Limitazioni del selettore di sottorete: lo standard subnetSelectorTerms e le securityGroupSelectorTerms configurazioni non si applicano alla selezione della sottorete o del gruppo di sicurezza di Pod.

• Pianificazione della rete: assicurati che lo spazio degli indirizzi IP sia adeguato sia nella sottorete del nodo che in quella del pod per supportare i requisiti del tuo carico di lavoro.

• Configurazione del routing: verifica che la tabella di routing e l'Access Control List (ACL) di rete delle sottoreti Pod siano configurati correttamente per la comunicazione tra nodo e sottoreti Pod.

• Zone di disponibilità: verifica di aver creato sottoreti del pod su più zone di disponibilità. Se si utilizza una sottorete Pod specifica, deve trovarsi nella stessa AZ della sottorete del nodo AZ.

Modalità IP secondaria per pod

Il ipv4PrefixSize campo consente configurazioni di rete avanzate assegnando solo indirizzi IP secondari ai nodi. Questa funzionalità non assegna i prefissi (/28) ai nodi e mantiene solo un IP secondario come minimalIPTarget.

advancedNetworking.ipv4PrefixSizeaccetta due valori: Auto (impostazione predefinita; delega dei prefissi; maggiore velocità di creazione dei pod; riserva un minimo di 16 IP per nodo) e "32" (modalità IP secondaria; 1 IP per pod; aggiunge chiamate per pod; pod per nodo limitati dall'ENI del tipo di istanzaAssignPrivateIpAddresses). IP-limit

In Auto modalità, EKS Auto Mode assegna un /28 prefisso (16 IP) a ciascun nodo in anticipo e ne aggiunge un altro /28 quando la richiesta del pod supera la capacità del blocco corrente, quindi 16 è un minimo per nodo anziché un limite.

Usa i seguenti numeri per la pianificazione; i cluster reali variano. Quando la sottorete del pod diventa frammentata e nessuna rete contigua /28 è libera, la Auto modalità ritorna all'allocazione per IP su quel nodo. Per-node Il conteggio degli IP si trova quindi al di sotto dello schema di 16 per prefisso mostrato di seguito.

Esempio A: 1 pod sul nodo

• Modalità IP secondaria: 1 pod IP + 1 nodo IP = 2 IP in uso.

• Modalità prefisso: 1 nodo IP + 16 IP del primo /28 prefisso (di cui 1 utilizzato dal pod, 15 per i pod futuri) = 17 IP allocati, 2 in uso.

Esempio B: 18 pod sul nodo

• Modalità IP secondaria: 18 IP pod + 1 nodo IP = 19 IP in uso.

• Modalità prefisso: 1 nodo IP + 2 × /28 prefissi (32 IP in totale, il primo /28 pieno a 16 pod, il secondo /28 contiene i pod 17-18 con 14 per i pod futuri) = 33 IP allocati, 19 in uso.

Per passare alla modalità IP secondaria (1 IP per pod, nessuna prenotazione con prefisso) per un carico di lavoro limitato ai pod, crea un with personalizzato e indicane uno personalizzato. NodeClass advancedNetworking.ipv4PrefixSize: "32" NodePool I pool integrati general-purpose e i pool di system nodi utilizzano il provisioning automatico default NodeClass; l'override ipv4PrefixSize richiede una configurazione personalizzata abbinata a una personalizzata. NodeClass NodePool

Casi d’uso

• Migliore utilizzo dell'indirizzo IP della sottorete

• Nessuna frammentazione del prefisso

Configurazione di esempio

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    ipv4PrefixSize: "32"

Considerazioni sulla modalità IP secondaria

• Velocità di creazione dei pod ridotta: poiché viene riscaldato solo un IP secondario, il servizio IPAM richiede più tempo per eseguire il provisioning degli IP quando vengono creati più pod.

Disabilita l'uscita IPv4 dai pod IPv6 nei cluster IPv6.

Il enableV4Egress true campo è predefinito. Per i cluster IPv6 in modalità automatica, la funzionalità può essere disabilitata in modo che la modalità automatica non crei un'interfaccia IPv4 di sola uscita per i pod IPv6. Questo è importante perché l'interfaccia di uscita IPv4 non è soggetta all'applicazione dei criteri di rete. Le politiche di rete vengono applicate solo sull'interfaccia principale del Pod (eth0).

Casi d’uso

Usa enableV4Egress quando devi:

• Usa il cluster IPv6: il traffico in uscita IPv4 è consentito per impostazione predefinita.

• Usa la politica di rete: attualmente EKS Network Policy non supporta il dual stack. La disabilitazione enableV4Egress può impedire la fuoriuscita inaspettata del traffico del pod su IPv4.

Configurazione di esempio

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    enableV4Egress: false

Considerazioni per la disabilitazione di EnableV4egress

• Politica di rete nel cluster IPv6: i cluster IPv6 consentono il traffico IPv4 per impostazione predefinita. L'impostazione enableV4Egress: false blocca il traffico in uscita IPv4, fornendo una maggiore sicurezza soprattutto se utilizzata con i criteri di rete.

Configurazione statica dell'interfaccia di rete

Il networkInterfaces campo sotto advancedNetworking consente di definire staticamente le interfacce di rete collegate alle istanze all'avvio. Viene utilizzato principalmente per configurare i dispositivi Elastic Fabric Adapter (EFA) per comunicazioni tra nodi ad alte prestazioni nei carichi di lavoro di formazione e inferenza distribuiti. Questa funzionalità può essere abbinata a pool di nodi a capacità statica per mantenere i nodi preriscaldati. EFA-ready Per ulteriori informazioni sulla gestione dei dispositivi EFA in EKS, vedere. Gestisci i dispositivi EFA su Amazon EKS Per la configurazione EFA consigliata per tipi di istanze specifici, consulta Massimizzare la larghezza di banda di rete per i tipi di EFA-enabled istanza nella Amazon EC2 User Guide.

Come funziona

Ogni voce in networkInterfaces definisce un'interfaccia di rete collegata all'istanza durante l'avvio. Ogni voce specifica una networkCardIndex (la scheda di rete, dove 0 è la principale), una deviceIndex (la posizione del dispositivo su quella scheda) e una interfaceType (interfaceper il IP-based traffico standard o efa-only per le interfacce EFA dedicate al traffico RDMA senza indirizzi IP). L'ENI primario (networkCardIndex: 0,deviceIndex: 0) deve essere utilizzato interfaceType: interface per supportare la comunicazione tra i nodi. IP-based Le efa-only interfacce supportano solo le funzionalità dei dispositivi EFA per RDMA e non possono essere configurate con indirizzi IP.

È possibile assegnare la capacità IP alle interfacce sulla scheda di rete primaria (networkCardIndex: 0) utilizzando secondaryIPv4Count (ogni unità fornisce 1 indirizzo IP) o secondaryIPv4PrefixCount (ogni unità fornisce un prefisso /28 con 16 indirizzi IP). È possibile utilizzarne solo uno per interfaccia e sono supportati solo su. networkCardIndex: 0 Non possono essere utilizzati sulle efa-only interfacce.

Importante

Quando networkInterfaces è configurato, EKS Auto Mode non allega IP, prefissi o ENI aggiuntivi dopo l'avvio dell'istanza. Solo le interfacce e gli indirizzi IP configurati all'avvio sono disponibili per Pods. È necessario pianificare la densità dei pod in base al numero di IP configurati.

Considerazioni

L'IPv6 non è supportato con interfacce di rete definite staticamente. associatePublicIPAddressnon è compatibile quando è definita più di un'interfaccia di rete, quindi i nodi che utilizzano più interfacce non possono avere IP pubblici (sia in cluster solo pubblici che in cluster misti). public/private

Quando si utilizzano podSubnetSelectorTerms e podSecurityGroupSelectorTerms con interfacce di rete statiche, configura l'ENI primario con 0 IP secondari. L'ENI primario utilizza la sottorete del nodo e i gruppi di sicurezza, mentre il traffico Pod utilizza la configurazione della sottorete pod sugli ENI secondari.

Esempio: EFA-only interfacce per l'addestramento delle GPU

L'esempio seguente mostra una NodeClass configurazione con EFA-only interfacce per un'istanza GPU utilizzata nell'addestramento distribuito. L'interfaccia principale ha un prefisso /28 (16 IP pod) e 4 EFA-only interfacce aggiuntive forniscono la connettività RDMA. Questa configurazione può essere associata a un pool di nodi con capacità statica per mantenere i nodi preriscaldati. EFA-ready

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: efa-training
spec:
  role: MyNodeRole
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
  securityGroupSelectorTerms:
    - tags:
        Name: "efa-security-group"
  placementGroupSelector:
    name: "ml-training-pg"
  advancedNetworking:
    networkInterfaces:
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 1
    - deviceIndex: 1
      interfaceType: efa-only
      networkCardIndex: 0
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 2
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 3

Configura enormi pagine sui nodi

Con il advancedCompute.hugepages campo, puoi configurare hugepages sui nodi in. NodeClass Hugepages migliora le prestazioni di accesso alla memoria per carichi di lavoro sensibili alla latenza come l'elaborazione ad alte prestazioni (HPC), i database e le applicazioni ad alta intensità di rete. Puoi utilizzare due configurazioni di hugepages indipendenti separatamente o insieme:

• Pagine enormi statiche: utilizza il pages campo per preallocare un numero fisso di o 1Gi enormi pagine su ciascun nodo 2Mi o una combinazione di entrambe le dimensioni. Le hugepages statiche sono una risorsa nodale programmabile. Per consumarle, configura i tuoi Pod per richiedere esplicitamente risorse di grandi dimensioni come o. hugepages-2Mi hugepages-1Gi Per ulteriori informazioni, consulta Manage HugePages nella documentazione di Kubernetes.

• Transparent hugepages (THP): usa il transparent campo per configurare la policy THP del kernel. THP è una policy a livello di kernel piuttosto che una risorsa allocabile. Non influisce sulla pianificazione o sulla capacità dei nodi e i Pods non lo richiedono. Per ulteriori informazioni, consulta Transparent Hugepage Support nella documentazione del kernel Linux.

Configurazione di esempio

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: hugepages-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    hugepages:
      # Static hugepage reservations: up to one entry for each size
      pages:
        - size: "2Mi"
          count: 512
        - size: "1Gi"
          count: 2
      # Transparent hugepages (THP) kernel policy
      transparent:
        enabled: always  # or madvise, never
        defrag: defer    # or always, defer+madvise, madvise, never

Impostazioni trasparenti per hugepage

Entrambe transparent le impostazioni sono opzionali. Se si omette un'impostazione, il nodo utilizza il kernel default ()madvise.

• enabled— Utilizzato enabled per controllare la politica di allocazione THP. Imposta questa opzione per applicare il always THP a livello di sistema. Impostalo in modo che applichi madvise il THP solo alle aree di memoria che lo accettano. madvise(MADV_HUGEPAGE) Impostalo su per never disabilitare THP.

• defrag— Si usa defrag per controllare l'aggressività con cui il kernel compatta la memoria per soddisfare un'allocazione di THP. I valori validi sono always, defer, defer+madvise, madvise e never.

Per disabilitare THP, ad esempio per i carichi di lavoro del database che consigliano di disattivarlo, imposta. enabled: never Quando lo enabled ènever, lascialo defrag non impostato o impostalo sunever; la NodeClass convalida rifiuta qualsiasi altra combinazione.

Considerazioni su Hugepages

Considera quanto segue quando configuri hugepages su un: NodeClass

• Dimensioni statiche delle pagine enormi: utilizza il pages campo per specificare fino a una voce per ogni dimensione (e) delle pagine enormi. 2Mi 1Gi Puoi prenotare entrambe le dimensioni sugli stessi nodi.

• Prenotazione della memoria: le enormi pagine statiche vengono conteggiate nella memoria totale dell'istanza. Amazon EKS contrassegna i tipi di istanza come incompatibili NodeClass quando la prenotazione combinata di enormi pagine su tutte le dimensioni di pagina supererebbe l'80% della memoria totale.

• Mutua esclusione EFA: Elastic Fabric Adapter (EFA) e pagine enormi statiche non possono coesistere sullo stesso. NodeClass Se si imposta interfaceType: efa-only insieme a, la convalida ha esito negativo. pages NodeClass Amazon EKS non fornisce pod la cui richiesta viene effettuata vpc.amazonaws.com/efa da un utente NodeClass con enormi pagine statiche. Usane uno separato NodeClass per i carichi di lavoro EFA. Le enormi pagine trasparenti non sono in conflitto con EFA; puoi configurarle transparent su una NodeClass che utilizza interfacce EFA.

Configura le impostazioni kubelet sui nodi

Usa il advancedCompute.kubelet campo per sovrascrivere le impostazioni di kubelet sui nodi in. NodeClass Con queste sostituzioni, puoi regolare la densità del Pod, l'eliminazione della pressione delle risorse, la rotazione del log del contenitore e il comportamento dell'esaurimento della memoria (OOM). Amazon EKS applica le impostazioni kubelet predefinite ai nodi Auto Mode, quindi configura questo campo solo quando i carichi di lavoro richiedono un comportamento diverso. Per ulteriori informazioni sulle impostazioni sottostanti, consulta la configurazione di Kubelet nella documentazione di Kubernetes.

Sono disponibili le seguenti impostazioni kubelet:

• maxPods: Il numero massimo di Pod che possono essere eseguiti su un nodo.

• podPidsLimit: il numero massimo di ID di processo (PID) per Pod.

• idsPerPod: il numero di UID e GID che il kubelet assegna allo spazio dei nomi utente di ogni Pod.

• singleProcessOOMKill: se il kubelet OOM elimina i processi in un contenitore singolarmente anziché come gruppo.

• eviction: Soglie di sfratto rigide e morbide per i segnali relativi alla pressione delle risorse.

• logging: dimensione di rotazione del log del contenitore e numero di file.

• allowedUnsafeSysctls: un elenco di sysctls non sicuri, o pattern con namespace che terminano con*, che i Pod programmati sul nodo possono impostare.

Configurazione di esempio

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: kubelet-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    kubelet:
      # Range: 1-110
      maxPods: 60
      # -1 disables the limit, or specify 100 or greater
      podPidsLimit: 4096
      # Multiple of 65536, range: 65536-4294967295. Requires
      # advancedCompute.kernel.sysctl.user.max_user_namespaces > 0.
      idsPerPod: 65536
      singleProcessOOMKill: false
      eviction:
        # Valid signals: memory.available, nodefs.available, nodefs.inodesFree,
        # imagefs.available, imagefs.inodesFree, pid.available
        hard:
          memory.available: "100Mi"
          nodefs.available: "10%"
        soft:
          memory.available: "500Mi"
          nodefs.available: "15%"
        # Required when soft thresholds are set
        softGracePeriod:
          memory.available: "1m30s"
          nodefs.available: "2m"
        # 0 uses each Pod's terminationGracePeriodSeconds
        maxPodGracePeriod: 60
      logging:
        containerLogMaxSize: "10Mi"
        # Minimum: 2
        containerLogMaxFiles: 5
      # Up to 64 entries. Allowed patterns: kernel.shm*, kernel.msg*,
      # kernel.sem, fs.mqueue.*, net.*
      allowedUnsafeSysctls:
        - "net.core.somaxconn"
        - "kernel.shm*"

Considerazioni sulle impostazioni di Kubelet

Considera quanto segue quando configuri le impostazioni di Kubelet su un: NodeClass

• Sostituzione di un nodo: la modifica delle impostazioni del kubelet su un nodo esistente NodeClass contrassegna i nodi che lo utilizzano come deviati. Amazon EKS sostituisce tali nodi con nuovi nodi che utilizzano la configurazione aggiornata. Amazon EKS non applica le impostazioni kubelet ai nodi in esecuzione sul posto.

• maxPodsbloccaggio: il valore impostato è un limite massimo, non una garanzia. In fase di esecuzione, Amazon EKS applica il più basso dei tre valori. Questi sono il tuo maxPods valore, gli indirizzi IP disponibili per il tipo di istanza e il limite della modalità automatica di 110 pod per nodo. Per ulteriori informazioni, consulta Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale.

• podPidsLimitvalori: specificate -1 di disattivare il limite o un valore pari 100 o superiore. NodeClassla convalida rifiuta i valori compresi tra e0. 99

• idsPerPodrequisiti: il valore deve essere un multiplo 65536 tra e65536. 4294967295 L'impostazione idsPerPod richiede advancedCompute.kernel.sysctl.user.max_user_namespaces di essere impostata su un valore positivo sulla stessaNodeClass; l'NodeClassammissione rifiuta le configurazioni impostate idsPerPod senza user.max_user_namespaces impostare anche un valore maggiore di. 0 Per ulteriori informazioni su user.max_user_namespaces, consultare Sysctls supportato.

• Soglie di sfratto graduale: una soglia morbida deve essere meno aggressiva della soglia rigida per lo stesso segnale, vale a dire che si attiva prima. Se imposti delle soglie morbide, devi impostarle anche per ogni segnale. softGracePeriod Una soglia morbida e una soglia rigida possono utilizzare unità diverse, ad esempio una percentuale e una quantità assoluta. In tal caso, Amazon EKS risolve entrambi i valori per ogni tipo di istanza. Amazon EKS contrassegna quindi i tipi di istanza che violano il confronto come incompatibili con. NodeClass

• singleProcessOOMKillrequisiti di versione: questa impostazione richiede Kubernetes versione 1.32 o successiva. Nelle versioni precedenti, Amazon EKS emette un evento di avviso su NodeClass e l'impostazione non ha effetto.

• allowedUnsafeSysctlsrestrizioni: puoi specificare fino a 64 voci e ciascuna voce deve corrispondere a uno dei modelli consentiti:kernel.shm*,kernel.msg*, kernel.semfs.mqueue. , onet.. Consentire un sysctl non sicuro sul nodo consente solo ai Pods di richiederlo. Ogni Pod deve comunque elencare il sysctl nel suo. securityContext.sysctls Per ulteriori informazioni, consulta Usare sysctls in un cluster Kubernetes nella documentazione di Kubernetes.

Configura sysctls del kernel sui nodi

Usa il advancedCompute.kernel.sysctl campo per impostare sysctls del kernel Linux sui nodi in. NodeClass Sysctls ottimizza il comportamento del kernel di runtime per i carichi di lavoro che richiedono limiti di rete più elevati, politiche di gestione della memoria diverse o impostazioni TCP specifiche. I nomi delle proprietà sul sysctl campo corrispondono esattamente al nome sysctl del kernel sottostante (ad esempio, e). vm.swappiness net.core.somaxconn Amazon EKS applica i valori sysctl all'avvio del nodo. Se modifichi un sysctl su un sistema esistente NodeClass, Amazon EKS inizia a sostituire i nodi per rendere effettivi i nuovi valori.

Configurazione di esempio

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: tuned-compute
spec:
  role: MyNodeRole

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  advancedCompute:
    kernel:
      sysctl:
        vm.swappiness: 30
        net.core.somaxconn: 4096
        net.ipv4.tcp_congestion_control: "cubic"
        vm.dirty_background_ratio: 10
        vm.dirty_ratio: 20

Sysctls supportato

Amazon EKS supporta solo i sysctls indicati nella tabella seguente. Ogni sysctl numerico impone il minimo e il massimo visualizzati e l'ammissione rifiuta i valori al di fuori di tale intervallo. NodeClass Le stringhe sysctls accettano solo i valori elencati.

Sysctl	Description	Valori consentiti
fs.aio-max-nr	Il numero massimo di richieste I/O asincrone.	65536–4194304
fs.inotify.max_user_instances	Il numero massimo di istanze inotify per ID utente reale.	8192–1048576
fs.inotify.max_user_watches	Il numero massimo di orologi inotify per ID utente reale.	8192–1048576
fs.nr_open	Il numero massimo di file handle che un processo può allocare.	1048576–2147483584
kernel.perf_event_paranoid	Controlla l'accesso non privilegiato ai sistemi di eventi prestazionali.	-1–2
net.core.netdev_max_backlog	Il numero massimo di pacchetti in coda sul lato INPUT per CPU.	1000–3240000
net.core.rmem_max	La dimensione massima del buffer del socket di ricezione, in byte.	212992–134217728
net.core.somaxconn	Il valore massimo per l'argomento backlog nella syscall di ascolto.	4096–3240000
net.core.wmem_max	La dimensione massima del buffer del socket di invio, in byte.	212992–134217728
net.ipv4.neigh.default.gc_thresh1	Numero minimo di ARP-cache voci prima dell'esecuzione di Garbage Collection.	0–262144
net.ipv4.neigh.default.gc_thresh2	Numero massimo minimo di voci. ARP-cache	512–524288
net.ipv4.neigh.default.gc_thresh3	Numero massimo fisso di ARP-cache iscrizioni.	1024–1048576
net.ipv4.tcp_congestion_control	L'algoritmo di controllo della congestione TCP per nuove connessioni.	cubic, reno
net.ipv4.tcp_fin_timeout	Il periodo di tempo, in secondi, in cui una connessione orfana rimane nello stato FIN_WAIT_2 prima di essere interrotta all'estremità locale.	5–120
net.ipv4.tcp_keepalive_time	Con che frequenza, in secondi, TCP invia messaggi keepalive quando keepalive è abilitato.	30–432000
net.ipv4.tcp_max_syn_backlog	Il numero massimo di richieste SYN in sospeso consentite. Le richieste oltre questo valore vengono eliminate dal kernel.	128–3240000
net.ipv4.tcp_tw_reuse	Abilita il riutilizzo dei TIME-WAIT socket per nuove connessioni quando è sicuro dal punto di vista del protocollo. 0disabilita, abilita globalmente, 1 abilita solo per il 2 loopback.	0–2
user.max_user_namespaces	Il numero massimo di namespace utente creabili da un utente. Il valore di disabilita i namespace 0 utente.	0–2147483647
vm.dirty_background_ratio	Percentuale di memoria disponibile a partire dalla quale i thread del kernel flusher iniziano a riscrivere le pagine sporche sul disco.	1–20
vm.dirty_expire_centisecs	Centesimi di secondo prima che una pagina sporca diventi idonea per la riscrittura.	0–6000
vm.dirty_ratio	Percentuale della memoria disponibile in cui i programmi di scrittura sono costretti a bloccare le scritture.	5–40
vm.dirty_writeback_centisecs	Centesimi di secondo tra le invocazioni flusher-thread.	0–1000
vm.max_map_count	Il numero massimo di aree della mappa di memoria che un singolo processo può avere.	65530–2147483647
vm.swappiness	Costo I/O relativo dello scambio rispetto al paging del file system.	0–200
vm.watermark_scale_factor	Rapporto di recupero della filigrana da parte della memoria in frazioni di 10.000.	10–3000

Considerazioni su Sysctls

Considerate quanto segue quando configurate il kernel sysctls su un: NodeClass

• Sysctls supportati: sono supportati solo i sysctls elencati in. Sysctls supportato Ogni campo impone un minimo e un massimo documentati e l'ammissione rifiuta i valori al di fuori di tale intervallo. NodeClass

• Applicato all'avvio: i sysctls vengono scritti su Bottlerocket all'avvio del nodo. [settings.kernel.sysctl] Modifiche in fase di esecuzione per spec.advancedCompute.kernel.sysctl contrassegnare i nodi esistenti come deviati; i nuovi valori hanno effetto solo sui nodi sostitutivi.

• vm.dirty_background_ratioe vm.dirty_ratio: questi due campi devono essere entrambi impostati o entrambi omessi e vm.dirty_background_ratio devono essere rigorosamente inferiori a. vm.dirty_ratio NodeClass admission rifiuta le configurazioni che violano una delle due regole.

• net.ipv4.neigh.default.gc_thresh1gc_thresh2, e gc_thresh3 — Le tre ARP-cache soglie devono essere tutte impostate insieme o tutte omesse e i relativi valori devono essere soddisfatti. gc_thresh1 < gc_thresh2 < gc_thresh3 NodeClass admission rifiuta le configurazioni che violano una delle due regole.

• net.ipv4.tcp_congestion_control— Solo cubic e sono accettati. reno