Aiutaci a migliorare questa pagina
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Crea una classe di nodi per Amazon EKS
Le classi di nodi Amazon EKS sono modelli che offrono un controllo granulare sulla configurazione dei nodi gestiti in modalità automatica 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 archiviazione e l'etichettatura delle risorse. Questo argomento spiega come creare e configurare una classe di nodi per soddisfare i requisiti operativi specifici.
Quando è necessario personalizzare il modo in cui EKS Auto Mode effettua il provisioning e configura EC2 le istanze oltre le impostazioni predefinite, la creazione di una classe di nodi offre 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.
Crea una classe di nodi
Per creare unaNodeClass
, procedi nel seguente modo:
-
Crea un file YAML (ad esempio,
nodeclass.yaml
) con la tua configurazione Node Class -
Applica la configurazione al tuo cluster utilizzando
kubectl
-
Fai riferimento alla classe di nodi nella configurazione del tuo pool di nodi. Per ulteriori informazioni, consulta Creare un pool di nodi per la modalità automatica EKS.
È necessario kubectl
installarlo e configurarlo. Per ulteriori informazioni, consulta Configurazione per l'utilizzo di Amazon EKS.
Esempio di classe di nodi di base
Ecco un esempio di Node Class:
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 storage temporaneo sul nodo.
Applica questa configurazione utilizzando:
kubectl apply -f nodeclass.yaml
Successivamente, fai riferimento alla classe di nodi nella configurazione del pool di nodi. Per ulteriori informazioni, consulta Creare un pool di nodi per la modalità automatica EKS.
Crea la voce di accesso alla classe del nodo
Se crei una classe di nodi personalizzata, devi creare un EKS Access Entry per consentire ai nodi di unirsi al cluster. EKS crea automaticamente le voci di accesso quando si utilizzano la classe di nodi e i pool di nodi integrati.
Per informazioni su come funzionano gli Access Entries, consultaConcedi agli utenti IAM l'accesso a Kubernetes con le voci di accesso EKS.
Quando si creano voci di accesso per le classi di nodi EKS Auto Mode, è necessario utilizzare il tipo di EC2
accesso.
Crea un ingresso di accesso con CLI
Per creare una voce di accesso per EC2 i nodi e associare la EKS Auto Node Policy:
Aggiorna i seguenti comandi CLI con il nome del cluster e l'ARN del ruolo del nodo. Il ruolo del nodo ARN è 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 EC2 i nodi e associare la politica EKS Auto Node:
Aggiorna quanto segue CloudFormation con il nome del cluster e l'ARN del ruolo del nodo. Il ruolo del nodo ARN è 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
Specificazione della classe dei 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" # 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 # Optional: Forward proxy, commonly requires certificateBundles as well #for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation advancedNetworking: 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
-
Crittografia del volume: EKS utilizza la chiave KMS personalizzata configurata per crittografare il volume root 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 un nuovo Access Entry. EKS crea automaticamente un Access Entry per il ruolo IAM del nodo durante la creazione del cluster. Il ruolo IAM del nodo richiede la politica di accessoAmazonEKSAutoNodePolicy
EKS. Per ulteriori informazioni, consulta Concedi 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 esistente. Per ulteriori informazioni, consulta Scegli un tipo di istanza Amazon EC2 node ottimale.
-
Tag: se desideri propagare i tag da Kubernetes a EC2, devi configurare autorizzazioni IAM aggiuntive. Per ulteriori informazioni, consulta Scopri l'identità e l'accesso in modalità automatica EKS.
-
Classe di nodo predefinita: non assegnare un nome alla classe di nodo personalizzata.
default
Questo perché la modalità automatica EKS include unaNodeClass
chiamatadefault
che viene assegnata automaticamente quando si abilita almeno una funzionalità integrataNodePool
. Per informazioni sull'attivazione delle funzionalità integrateNodePools
, vedereAttivazione o disattivazione della funzionalità integrata NodePools. -
subnetSelectorTerms
comportamento con più sottoreti: se esistono più sottoreti che soddisfano lesubnetSelectorTerms
condizioni o fornite tramite ID, EKS Auto Mode crea nodi distribuiti tra le sottoreti.-
Se le sottoreti si trovano in zone di disponibilità (AZ) diverse, puoi utilizzare le funzionalità di Kubernetes come i vincoli di diffusione della topologia Pod e il routing basato sulla topologia per distribuire rispettivamente i pod
e il traffico tra le zone. -
Se ci sono più sottoreti nella stessa AZ che corrispondono alla, EKS Auto Mode crea pod su ogni nodo distribuiti tra le
subnetSelectorTerms
sottoreti di quella AZ. EKS Auto Mode crea interfacce di rete secondarie su ciascun nodo nelle altre sottoreti della stessa AZ. Sceglie in base al numero di indirizzi IP disponibili in ciascuna sottorete, per utilizzare le sottoreti in modo più efficiente. Tuttavia, non è possibile specificare quale sottorete EKS Auto Mode utilizza per ogni pod; se avete bisogno di pod per funzionare in sottoreti specifiche, utilizzateli al loro posto. Selezione della sottorete per i pod
-
Selezione della sottorete per i pod
I podSecurityGroupSelectorTerms
campi podSubnetSelectorTerms
and consentono configurazioni di rete avanzate consentendo ai pod di funzionare in sottoreti diverse rispetto ai rispettivi nodi. Questa separazione offre un maggiore controllo sul routing del traffico di rete e sulle politiche di sicurezza. Si noti che podSecurityGroupSelectorTerms
sono obbligatori con. podSubnetSelectorTerms
Casi d'uso
podSubnetSelectorTerms
Usalo quando è necessario:
-
Separare il traffico dell'infrastruttura (node-to-node comunicazione) dal traffico delle applicazioni (pod-to-pod comunicazione)
-
Applica configurazioni di rete diverse alle sottoreti dei nodi rispetto alle sottoreti dei pod.
-
Implementa politiche di sicurezza o regole di routing diverse per nodi e pod.
-
Configura i proxy inversi o il filtraggio di rete in modo specifico per il traffico dei nodi senza influire sul traffico dei pod. Usa
advancedNetworking
e definiscicertificateBundles
il tuo reverse proxy e tutti i certificati autofirmati o privati 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à di pod ridotta: durante l'utilizzo è possibile eseguire meno pod su ciascun nodo
podSubnetSelectorTerms
, poiché l'interfaccia di rete principale del nodo si trova nella sottorete del nodo e non può essere utilizzata per i pod nella sottorete dei pod. -
Limitazioni del selettore di sottorete: lo standard
subnetSelectorTerms
e lesecurityGroupSelectorTerms
configurazioni non si applicano alla selezione delle sottoreti dei pod. -
Pianificazione della rete: assicurate uno spazio adeguato per gli indirizzi IP nelle sottoreti di nodi e pod per supportare i requisiti del carico di lavoro.
-
Configurazione del routing: verificate che la tabella di routing e l'ACL (Network Access Control List) delle sottoreti dei pod siano configurati correttamente per la comunicazione tra le sottoreti dei nodi e dei pod.