Contribuisci a migliorare questa pagina
Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.
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 da EKS Auto Mode. 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 di EKS Auto Mode 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.
Creazione di una classe di nodi
Per creare una NodeClass, segui questi passaggi:
-
Crea un file YAML (ad esempio,
nodeclass.yaml) con la configurazione della classe di nodi -
Applica la configurazione al cluster utilizzando
kubectl -
Fai riferimento alla classe di nodi nella configurazione del tuo pool di nodi. Per ulteriori informazioni, consulta Crea un pool di nodi per EKS Auto Mode.
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"
Questa classe di nodi aumenta la quantità di storage 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 EKS Auto Mode.
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 di EKS Auto Mode, è 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
Creazione di un accesso con CloudFormation
Per creare una voce di accesso per i nodi EC2 e associare la policy dei nodi di EKS Auto:
Aggiorna la CloudFormation seguente 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 sull’implementazione degli stack CloudFormation, consulta Getting started with CloudFormation
Specifiche della classe di nodi
apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: my-node-class spec: # Required fields role: MyNodeRole # IAM role 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 # Optional: Custom certificate bundles. certificateBundles: - name: "custom-cert" data: "base64-encoded-cert-data" # 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 del volume: EKS usa la chiave KMS personalizzata configurata per crittografare il volume root di sola lettura dell’istanza e il volume di dati di lettura/scrittura.
-
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 diAmazonEKSAutoNodePolicyEKS. 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 EKS Auto Mode.
-
Classe di nodi predefinita: non assegnare un nome alla classe di nodi
defaultpersonalizzata. Questo perché EKS Auto Mode include unaNodeClassdenominatadefaultche viene fornita automaticamente quando si abilita almeno unNodePoolintegrato. Per informazioni sull’abilitazione deiNodePools, consulta Abilitazione o disabilitazione i NodePools integrati. -
comportamento di
subnetSelectorTermscon più sottoreti: se esistono più sottoreti che soddisfano le condizioni disubnetSelectorTermso che vengono fornite tramite ID, EKS Auto Mode 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, EKS Auto Mode crea pod su ciascun nodo distribuito tra le sottoreti in quella AZ. EKS Auto Mode 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 da EKS Auto Mode per ogni Pod; se hai bisogno che i Pod funzionino in sottoreti specifiche, usa Selezione della sottorete per i pod.
-
Selezione della sottorete per i pod
I campi podSubnetSelectorTerms e podSecurityGroupSelectorTerms permettono configurazioni di rete avanzate consentendo ai Pod di essere eseguiti in sottoreti diverse rispetto ai relativi nodi. Questa separazione offre maggiore controllo sul routing del traffico di rete e sulle policy di sicurezza. Nota che podSecurityGroupSelectorTerms è richiesto con podSubnetSelectorTerms.
Casi d'uso
Usa podSubnetSelectorTerms quando devi:
-
Separare il traffico dell’infrastruttura (comunicazione node-to-node) dal traffico delle applicazioni (comunicazione Pod-to-Pod)
-
Applicare configurazioni di rete diverse alle sottoreti dei nodi rispetto alle sottoreti Pod.
-
Implementare policy di sicurezza o regole di routing diverse per nodi e 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
advancedNetworkingecertificateBundlesper 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 for EC2 instances (nodes) subnetSelectorTerms: - tags: Name: "node-subnet" kubernetes.io/role/internal-elb: "1" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" # Separate subnets for Pods podSubnetSelectorTerms: - tags: Name: "pod-subnet" kubernetes.io/role/pod: "1" podSecurityGroupSelectorTerms: - tags: Name: "eks-pod-sg"
Considerazioni sui selettori di sottorete per i pod
-
Densità dei pod ridotta: Quando si usa
podSubnetSelectorTerms, è possibile eseguire un numero inferiore di pod su ciascun nodo, poiché l’interfaccia di rete primaria del nodo si trova nella sottorete del nodo e non può essere usata per i pod nella sottorete dei pod. -
Limitazioni del selettore della sottorete: le configurazioni standard
subnetSelectorTermsesecurityGroupSelectorTermsnon si applicano alla selezione della sottorete dei 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 la lista di controllo degli accessi (ACL) delle sottoreti del pod siano configurate correttamente per la comunicazione tra il nodo e le sottoreti del pod.
-
Zone di disponibilità: verifica di aver creato sottoreti del pod su più zone di disponibilità. Se usi una sottorete del pod specifica, questa deve trovarsi nella stessa AZ della sottorete del nodo AZ.