**Contribuisci 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à.
# Configurazione delle impostazioni della modalità automatica EKS
Questo capitolo descrive come configurare aspetti specifici dei cluster in modalità automatica Amazon Elastic Kubernetes Service (EKS). Sebbene la modalità automatica EKS gestisca automaticamente la maggior parte dei componenti dell’infrastruttura, è possibile personalizzare alcune funzionalità per soddisfare i requisiti del tuo carico di lavoro.
Utilizzando le opzioni di configurazione descritte in questo argomento, è possibile modificare le impostazioni di rete, le risorse di calcolo e i comportamenti di bilanciamento del carico, mantenendo al contempo i vantaggi della gestione automatizzata dell’infrastruttura. Prima di apportare modifiche alla configurazione, esamina le opzioni disponibili nelle sezioni seguenti per determinare l’approccio più adatto alle tue esigenze.
| Quali funzionalità vuoi configurare? | Opzione di configurazione |
| --- | --- |
| **Rete e archiviazione dei nodi** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Creazione di una classe di nodi per Amazon EKS](create-node-class.md) |
| **Risorse di calcolo dei nodi** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md) |
| **Pool di nodi a capacità statica** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Pool di nodi a capacità statica in modalità EKS Auto](auto-static-capacity.md) |
| **Impostazioni Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Creare e IngressClass configurare un Application Load Balancer](auto-configure-alb.md) |
| **Impostazioni Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Usa Annotazioni del servizio per configurare Network Load Balancer](auto-configure-nlb.md) |
| **Impostazioni della classe di archiviazione** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Crea una classe di archiviazione](create-storage-class.md) |
| **Controlla l’utilizzo dell’ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS](auto-odcr.md) |
| **Sicurezza avanzata del nodo** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Configurare le impostazioni di sicurezza avanzate per i nodi](auto-advanced-security.md) |
# 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.
## 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
1. Applica la configurazione al cluster utilizzando `kubectl`
1. 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](create-node-pool.md).
`kubectl` deve essere installato e configurato. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
### 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 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](create-node-pool.md).
## 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](access-entries.md).
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 \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Crea un ingresso 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:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
[Per informazioni sulla distribuzione degli CloudFormation stack, consulta Guida introduttiva a CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## 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
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: 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 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 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](access-entries.md).
+ **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](choosing-instance-type.md).
+ **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](auto-learn-iam.md).
+ **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 della funzionalità integrata NodePools](set-builtin-node-pools.md).
+ **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à diverse (AZs), puoi utilizzare le funzionalità di Kubernetes come i [vincoli di diffusione della topologia Pod e il routing con riconoscimento della topologia per distribuire rispettivamente i pod](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) e il traffico tra le zone.](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)
+ 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 pod](#pod-subnet-selector).
## Sottoreti e gruppi di sicurezza separati per i pod
I `podSecurityGroupSelectorTerms` campi `podSubnetSelectorTerms` and consentono configurazioni di rete avanzate consentendo ai Pod 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](security-groups-for-pods.md) (SGPP) utilizzata con AWS VPC CNI per il calcolo in modalità automatica non EKS. SGPP non è supportato in modalità automatica EKS. Utilizza invece `podSecurityGroupSelectorTerms` in `NodeClass` per applicare gruppi di sicurezza separati al traffico Pod. I gruppi di sicurezza si applicano a `NodeClass` livello, vale a dire tutti i Pod sui nodi che li utilizzano `NodeClass` condividono gli stessi gruppi di sicurezza Pod.
### Come funziona
Quando configuri `podSubnetSelectorTerms` e`podSecurityGroupSelectorTerms`:
1. L'ENI principale 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.
1. EKS Auto Mode crea sottoreti secondarie ENIs corrispondenti`podSubnetSelectorTerms`, con i gruppi di sicurezza allegati`podSecurityGroupSelectorTerms`. Gli indirizzi IP dei pod vengono allocati da questi secondari ENIs utilizzando i prefissi /28 per impostazione predefinita, con fallback automatico sul secondario IPs (/32) quando non è disponibile un blocco di prefisso contiguo. Se `ipv4PrefixSize` è impostato su in, vengono utilizzati solo quelli secondari. `"32"` `advancedNetworking` IPs
1. 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 Pod utilizzano l'ENI principale 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. È possibile modificare questo comportamento con il campo in. `snatPolicy` `NodeClass`
### Casi d’uso
Usa `podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms` quando ne hai bisogno:
+ Applica diversi gruppi di sicurezza per controllare il traffico per nodi e Pod separatamente.
+ Separa il traffico dell'infrastruttura (node-to-node comunicazione) dal traffico delle applicazioni (Pod-to-Pod comunicazione).
+ 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 relative a sottoreti Pod e gruppi di sicurezza separati
+ **Ambito del gruppo** di sicurezza: i gruppi di sicurezza di `podSecurityGroupSelectorTerms` sono collegati al secondario ENIs e si applicano al traffico Pod all'interno del VPC. Quando SNAT è abilitato (impostazione predefinita`snatPolicy: Random`), il traffico in uscita dal VPC viene tradotto nell'indirizzo IP ENI primario del nodo, quindi i gruppi di sicurezza del nodo si applicano `securityGroupSelectorTerms` invece a quel traffico. Se lo imposti`snatPolicy: Disabled`, i Pod utilizzano i propri indirizzi IP per tutto il traffico e devi assicurarti che i gruppi di routing e sicurezza siano configurati di conseguenza.
+ **NodeClassgranularità a livello** di. I gruppi di sicurezza Pod si applicano a tutti i Pod programmati sui nodi che utilizzano il. `NodeClass` Per applicare gruppi di sicurezza diversi a carichi di lavoro diversi, crea `NodePool` risorse `NodeClass` e strumenti separati e utilizza contaminazioni, tolleranze o selettori di nodi per pianificare i carichi di lavoro sui nodi appropriati.
+ **Densità di pod ridotta**: è possibile eseguire un minor numero di pod su ciascun 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 Pod o del gruppo di sicurezza.
+ **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 Pod su più sottoreti. AZs Se utilizzi una sottorete Pod specifica, deve trovarsi nella stessa AZ della sottorete di nodi AZ.
## Modalità IP secondaria per Pod
Il `ipv4PrefixSize` campo consente configurazioni di rete avanzate allocando solo indirizzi IP secondari ai nodi. Questa funzionalità non assegna prefissi (/28) ai nodi e mantiene un solo IP secondario come minimo. IPTarget
### Casi d’uso
Usa `ipv4PrefixSize` quando devi:
+ **Utilizzo IP ridotto**: verrà riscaldato solo un indirizzo IP in ogni nodo.
+ **Riduzione del tasso di produzione dei pod**: la velocità di creazione dei pod non è una delle principali preoccupazioni.
+ **Nessuna frammentazione del prefisso: la frammentazione** causata dal prefisso è una delle principali preoccupazioni o ostacola l'utilizzo della modalità automatica.
### 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 il provisioning IPs quando vengono creati più pod.
## Disabilita l' IPv4 uscita dai pod nei cluster. IPv6 IPv6
Il `enableV4Egress` campo è `true` di default. Per IPv6 i cluster Auto Mode, la funzione può essere disabilitata in modo che Auto Mode non crei un'interfaccia di sola uscita per i pod IPv4 . IPv6 Questo è importante perché l'interfaccia di IPv4 uscita non è soggetta all'applicazione delle politiche di rete. Le politiche di rete vengono applicate solo sull'interfaccia principale del Pod (eth0).
### Casi d’uso
Usa `enableV4Egress` quando devi:
+ **Usa IPv6 Cluster**: il traffico IPv4 in uscita è consentito per impostazione predefinita.
+ **Usa la politica di rete**: attualmente la politica di rete EKS non supporta il dual stack. La disabilitazione `enableV4Egress` può impedire al traffico dei pod di uscire in modo imprevisto. IPv4
### Configurazione di esempio
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Considerazioni sulla disabilitazione di EnableV4Egress
+ **Politica di rete nel cluster: i IPv6 cluster** consentono il traffico per impostazione predefinita. IPv6 IPv4 L'impostazione `enableV4Egress: false` blocca il traffico in IPv4 uscita, fornendo una maggiore sicurezza, specialmente se utilizzata con le politiche di rete.
# Crea un pool di nodi per EKS Auto Mode
I pool di nodi Amazon EKS forniscono un modo flessibile per gestire le risorse di calcolo nel cluster Kubernetes. Questo argomento mostra come creare e configurare pool di nodi usando Karpenter, uno strumento di provisioning dei nodi che aiuta a ottimizzare il dimensionamento dei cluster e l’utilizzo delle risorse. Con la risorsa NodePool di Karpenter, puoi definire requisiti specifici per le tue risorse di calcolo, inclusi i tipi di istanze, le zone di disponibilità, le architetture e i tipi di capacità.
Non è possibile modificare il `system` integrato e i pool di nodi `general-purpose`. È solo possibile abilitarli o disabilitarli. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
La specifica NodePool permette un controllo granulare delle risorse di elaborazione del cluster EKS tramite diverse etichette e requisiti supportati. Queste comprendono opzioni per specificare le categorie di istanze EC2, le configurazioni della CPU, le zone di disponibilità, le architetture (ARM64/AMD64) e i tipi di capacità (spot o on-demand). È inoltre possibile impostare limiti di risorse per l’utilizzo della CPU e della memoria, garantendo che il cluster rimanga entro i limiti operativi richiesti.
EKS Auto Mode sfrutta le note etichette Kubernetes per offrire metodi coerenti e standardizzati di identificazione delle caratteristiche dei nodi. Queste etichette, come `topology.kubernetes.io/zone` per le zone di disponibilità e `kubernetes.io/arch` per l’architettura della CPU, seguono le convenzioni stabilite da Kubernetes. Inoltre, le etichette specifiche EKS (precedute dal prefisso `eks.amazonaws.com/`) estendono questa funzionalità con attributi specifici AWS quali tipi di istanza, produttori di CPU, capacità GPU e specifiche di rete. Questo sistema di etichettatura standardizzato consente un’integrazione ottimale con gli strumenti Kubernetes esistenti, fornendo al tempo stesso una profonda integrazione dell’infrastruttura AWS.
## Creazione di NodePool
Segui i seguenti passaggi per creare un NodePool per il cluster Amazon EKS:
1. Crea un file YAML denominato `nodepool.yaml` con la configurazione NodePool richiesta. Puoi utilizzare la configurazione di esempio seguente.
1. Applica il NodePool al cluster:
```
kubectl apply -f nodepool.yaml
```
1. Verificare che il NodePool sia stato creato correttamente:
```
kubectl get nodepools
```
1. (Facoltativo) Monitora lo stato del NodePool:
```
kubectl describe nodepool default
```
Assicurati che il NodePool faccia riferimento a una NodeClass valida ed esistente nel tuo cluster. NodeClass definisce configurazioni specifiche AWS per le risorse di calcolo. Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
## NodePool di esempio
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Etichette supportate da EKS Auto Mode
EKS Auto Mode supporta le seguenti etichette note.
**Nota**
EKS Auto Mode utilizza etichette diverse rispetto a Karpenter. Le etichette relative alle istanze gestite da EC2 iniziano con `eks.amazonaws.com`.
| Etichetta | Esempio | Descrizione |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | Regione AWS |
| node.kubernetes.io/instance-type | g4dn.8xlarge | Tipo di istanza AWS |
| kubernetes.io/arch | amd64 | Le architetture sono definite dai [valori GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) sull’istanza |
| karpenter.sh/capacity-type | spot | I tipi di capacità includono `spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Tipi di istanze che usano un hypervisor specifico |
| eks.amazonaws.com/compute-type | auto | Identifica i nodi gestiti da EKS Auto Mode |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Tipi di istanza che supportano (o non supportano) la crittografia in transito |
| eks.amazonaws.com/instance-category | g | Tipi di istanza della stessa categoria, in genere la stringa che precede il numero di generazione |
| eks.amazonaws.com/instance-generation | 4 | Numero di generazione del tipo di istanza in una categoria di istanza |
| eks.amazonaws.com/instance-family | g4dn | Tipi di istanza con proprietà simili ma quantità di risorse differenti |
| eks.amazonaws.com/instance-size | 8xlarge | Tipi di istanza con quantità di risorse simili ma proprietà differenti |
| eks.amazonaws.com/instance-cpu | 32 | Numero di CPU sull’istanza |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Nome del produttore della CPU |
| eks.amazonaws.com/instance-memory | 131072 | Numero di mebibyte di memoria sull’istanza |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | Numero [massimo di megabit](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) di EBS disponibili sull’istanza |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | Numero di [megabit di base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponibili sull’istanza |
| eks.amazonaws.com/instance-gpu-name | t4 | Nome della GPU nell’istanza, se disponibile |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Nome del produttore della GPU |
| eks.amazonaws.com/instance-gpu-count | 1 | Numero di GPU nell’istanza |
| eks.amazonaws.com/instance-gpu-memory | 16384 | Numero di mebibyte di memoria sulla GPU |
| eks.amazonaws.com/instance-local-nvme | 900 | Gibibyte di storage nvme locale nell’istanza |
**Nota**
EKS Auto Mode supporta solo certe istanze e prevede dei requisiti minimi di dimensione. Per ulteriori informazioni, consulta [Riferimento all’istanza supportata dalla modalità automatica EKS](automode-learn-instances.md#auto-supported-instances).
## Etichette non supportate da EKS Auto Mode
EKS Auto Mode non supporta le seguenti etichette.
+ EKS Auto Mode supporta soltanto Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Disattivare i pool di nodi integrati
Se crei pool di nodi personalizzati, puoi disattivare i pool di nodi integrati. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
## Cluster senza pool di nodi integrati
Puoi creare un cluster senza pool di nodi integrati. È utile quando l’organizzazione ha creato pool di nodi personalizzati.
**Nota**
Quando crei un cluster senza pool di nodi integrati, il provisioning di NodeClass `default` non viene eseguito automaticamente. Sarà necessario creare una NodeClass personalizzata. Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
**Panoramica:**
1. Crea un cluster EKS con i valori `nodePools` e `nodeRoleArn` vuoti.
+ Esempio eksctl `autoModeConfig`:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Per ulteriori informazioni, consulta [Crea un cluster di EKS Auto Mode con la CLI di eksctl](automode-get-started-eksctl.md)
1. Crea una classe di nodi personalizzata con un ruolo del nodo ARN
+ Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md)
1. Crea una voce di accesso per la classe di nodi personalizzata
+ Per ulteriori informazioni, consulta [Creazione di una voce di accesso alla classe di nodi](create-node-class.md#auto-node-access-entry)
1. Crea un pool di nodi personalizzato come descritto sopra.
## Interruzione
Puoi configurare EKS Auto Mode in modo che interrompa i nodi tramite NodePool in diversi modi. Puoi usare `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` o `spec.template.spec.expireAfter`. Puoi anche limitare l’interruzione di EKS Auto Mode tramite il `spec.disruption.budgets` del NodePool. Puoi inoltre controllare le finestre temporali e il numero di nodi simultanei interrotti. Per istruzioni sulla configurazione di questo comportamento, consulta la pagina [Disruption](https://karpenter.sh/docs/concepts/disruption/) nella documentazione di Karpenter.
Puoi configurare l’interruzione per i pool di nodi per:
+ Identifica le istanze sottoutilizzate e consolida i carichi di lavoro.
+ Crea un budget per le interruzioni dei pool di nodi per limitare le interruzioni dei nodi causate da deviazioni, vuoto e consolidamento.
Per impostazione predefinita, EKS Auto Mode:
+ Consolida le istanze sottoutilizzate.
+ Termina le istanze dopo 336 ore.
+ Imposta un budget unico per le interruzioni pari al 10% dei nodi.
+ Permette la sostituzione dei nodi a causa della deriva quando viene rilasciata una nuova AMI in Auto Mode, cosa che avviene circa una volta alla settimana.
## Periodo di tolleranza della terminazione
Quando un `terminationGracePeriod` non è definito esplicitamente su un EKS Auto NodePool, il sistema applica automaticamente un periodo di tolleranza della terminazione predefinito di 24 ore al NodeClaim associato. Sebbene i clienti EKS Auto non vedranno un termine `terminationGracePeriod` predefinito nelle loro configurazioni NodePool personalizzate, osserveranno questo valore predefinito su NodeClaim. La funzionalità rimane coerente sia che il periodo di tolleranza sia impostato esplicitamente sul NodePool sia che sia predefinito sul NodeClaim, garantendo così un comportamento prevedibile di terminazione dei nodi in tutto il cluster.
# Pool di nodi a capacità statica in modalità EKS Auto
La modalità automatica di Amazon EKS supporta pool di nodi a capacità statica che mantengono un numero fisso di nodi indipendentemente dalla domanda del pod. I pool di nodi con capacità statica sono utili per carichi di lavoro che richiedono capacità prevedibile, istanze riservate o requisiti di conformità specifici in cui è necessario mantenere un ingombro dell'infrastruttura coerente.
A differenza dei pool di nodi dinamici che si ridimensionano in base alle richieste di pianificazione dei pod, i pool di nodi con capacità statica mantengono il numero di nodi configurati.
## Configurare un pool di nodi con capacità statica
Per creare un pool di nodi con capacità statica, imposta il `replicas` campo nelle tue NodePool specifiche. Il `replicas` campo definisce il numero esatto di nodi che il pool di nodi manterrà. Scopri [Esempi](#static-capacity-examples) come configurare`replicas`.
## Considerazioni sulla capacità statica del pool di nodi
I pool di nodi con capacità statica presentano diversi vincoli e comportamenti importanti:
**Vincoli di configurazione:**
+ **Impossibile cambiare modalità**: una volta impostato `replicas` un pool di nodi, non è possibile rimuoverlo. Il pool di nodi non può passare dalla modalità statica a quella dinamica.
+ **Limiti di risorse limitati**: nella sezione dei limiti è supportato solo il `limits.nodes` campo. I limiti di CPU e memoria non sono applicabili.
+ **Nessun campo di peso**: il `weight` campo non può essere impostato su pool di nodi con capacità statica poiché la selezione dei nodi non si basa sulla priorità.
**Comportamento operativo:**
+ **Nessun consolidamento**: i nodi nei pool di capacità statici non vengono presi in considerazione per il consolidamento.
+ **Operazioni di scalabilità: le operazioni di scalabilità** evitano i budget relativi alle interruzioni dei nodi, ma rispettano comunque i requisiti. PodDisruptionBudgets
+ **Sostituzione** dei nodi: i nodi vengono comunque sostituiti per eventuali variazioni (come gli aggiornamenti AMI) e per scadenza in base alla configurazione.
## Best practice
**Pianificazione della capacità:**
+ Impostato su un `limits.nodes` valore superiore `replicas` a per consentire il ridimensionamento temporaneo durante le operazioni di sostituzione dei nodi.
+ Quando imposti i limiti, considera la capacità massima necessaria durante la deriva dei nodi o gli aggiornamenti AMI.
**Selezione dell'istanza:**
+ Utilizza tipi di istanze specifici quando hai istanze riservate o requisiti hardware specifici.
+ Evita requisiti eccessivamente restrittivi che potrebbero limitare la disponibilità delle istanze durante la scalabilità.
**Gestione delle interruzioni:**
+ Configura i budget appropriati per le interruzioni per bilanciare la disponibilità con le operazioni di manutenzione.
+ Considerate la tolleranza della vostra applicazione per la sostituzione dei nodi quando impostate le percentuali di budget.
**Monitoraggio:**
+ Monitora regolarmente il `status.nodes` campo per garantire il mantenimento della capacità desiderata.
+ Imposta avvisi per quando il numero effettivo di nodi si discosta dalle repliche desiderate.
**Distribuzione delle zone:**
+ Per un'elevata disponibilità, distribuisci la capacità statica su più zone di disponibilità.
+ Quando si crea un pool di nodi con capacità statica che si estende su più zone di disponibilità, EKS Auto Mode distribuisce i nodi tra le zone specificate, ma non è garantito che la distribuzione sia uniforme.
+ Per una distribuzione prevedibile e uniforme tra le zone di disponibilità, crea pool di nodi con capacità statica separati, ciascuno collegato a una zona di disponibilità specifica utilizzando il requisito. `topology.kubernetes.io/zone`
+ Se hai bisogno di 12 nodi distribuiti uniformemente su tre zone, crea tre pool di nodi con 4 repliche ciascuno, anziché un pool di nodi con 12 repliche su tre zone.
## Scalabilità di un pool di nodi con capacità statica
È possibile modificare il numero di repliche in un pool di nodi con capacità statica utilizzando il `kubectl scale` comando:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
In caso di ridimensionamento, EKS Auto Mode terminerà i nodi in modo corretto, rispettando PodDisruptionBudgets e consentendo la riprogrammazione dei pod in esecuzione sui nodi rimanenti.
## Monitora i pool di nodi con capacità statica
Utilizzate i seguenti comandi per monitorare i pool di nodi con capacità statica:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
Il `status.nodes` campo mostra il numero attuale di nodi gestiti dal pool di nodi, che dovrebbe corrispondere al `replicas` numero desiderato in condizioni normali.
## Risoluzione dei problemi
**I nodi non raggiungono le repliche desiderate:**
+ Controlla se il `limits.nodes` valore è sufficiente
+ Verifica che i requisiti non limitino eccessivamente la selezione delle istanze
+ Controlla le quote AWS di servizio per i tipi di istanze e le regioni che stai utilizzando
**La sostituzione dei nodi richiede troppo tempo:**
+ Modifica i budget per le interruzioni per consentire più sostituzioni simultanee
+ Controlla se PodDisruptionBudgets stanno impedendo la chiusura del nodo
**Chiusura imprevista del nodo:**
+ Rivedi le impostazioni `expireAfter` e `terminationGracePeriod`
+ Verifica la presenza di interruzioni manuali dei nodi o di eventi AWS di manutenzione
## Esempi
### Pool di nodi con capacità statica di base
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Capacità statica con tipi di istanze specifici
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Pool di nodi con capacità statica multizona
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Capacità statica con riserva di capacità
L'esempio seguente mostra come utilizzare un pool di nodi di capacità statica con una prenotazione di capacità EC2. Per ulteriori informazioni sull'utilizzo di EC2 Capacity Reservations con EKS Auto Mode, consulta. [Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS](auto-odcr.md)
`NodeClass`definizione del `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`facendo riferimento a quanto sopra `NodeClass` e utilizzando`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Creare e IngressClass configurare un Application Load Balancer
La modalità automatica di EKS automatizza le attività di routine per il bilanciamento del carico, inclusa l’esposizione delle app del cluster a Internet.
AWS suggerisce di utilizzare Application Load Balancers (ALB) per servire il traffico HTTP e HTTPS. Gli Application Load Balancer possono instradare le richieste in base al contenuto della richiesta. Per ulteriori informazioni sugli Application Load Balancer, consulta [What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
EKS Auto Mode crea e configura Application Load Balancer (). ALBs Ad esempio, modalità automatica di EKS crea un bilanciatore del carico quando crei un oggetto Kubernetes `Ingress` e lo configura per indirizzare il traffico verso il carico di lavoro del cluster.
**Panoramica**
1. Crea un carico di lavoro da esporre a Internet.
1. Crea una `IngressClassParams` risorsa, specificando valori di configurazione AWS specifici come il certificato da utilizzare per le SSL/TLS sottoreti VPC.
1. Creare una risorsa `IngressClass`, specificando che modalità automatica di EKS sarà il controller della risorsa.
1. Crea una risorsa `Ingress` da associare a un percorso e una porta HTTP a un carico di lavoro del cluster.
La modalità automatica di EKS creerà un Application Load Balancer che punta al carico di lavoro specificato nella risorsa `Ingress`, utilizzando la configurazione del bilanciatore del carico specificata nella risorsa `IngressClassParams`.
## Prerequisiti
+ La modalità automatica di EKS su un cluster Amazon EKS
+ Kubectl configurato per connettersi al cluster
+ Puoi usare `kubectl apply -f ` per applicare i file di configurazione di esempio YAML riportati di seguito al cluster.
**Nota**
La modalità automatica di EKS richiede i tag di sottorete per identificare le sottoreti pubbliche e private.
Se hai creato il cluster con `eksctl`, disponi già di questi tag.
Informazioni su come [Assegnazione di tag alle sottoreti per la modalità automatica EKS](tag-subnets-auto.md).
## Fase 1: Creare un carico di lavoro
Per iniziare, crea un carico di lavoro da esporre a Internet. Può trattarsi di qualsiasi risorsa di Kubernetes che serve il traffico HTTP, ad esempio un’implementazione o un servizio.
Questo esempio utilizza un semplice servizio HTTP chiamato `service-2048` che ascolta sulla porta `80`. Creare questo servizio e la sua implementazione applicando il seguente manifesto, `2048-deployment-service.yaml`:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Applica la configurazione al cluster:
```
kubectl apply -f 2048-deployment-service.yaml
```
Le risorse sopra elencate verranno create nel namespace predefinito. Puoi verificarlo eseguendo il comando seguente:
```
kubectl get all -n default
```
## Fase 2: Creare IngressClassParams
Crea un `IngressClassParams` oggetto per specificare opzioni di configurazione AWS specifiche per l'Application Load Balancer. In questo esempio, creiamo una risorsa `IngressClassParams` denominata `alb` (che verrà utilizzata nella fase successiva) che specifica lo schema del bilanciatore del carico come `internet-facing` in un file chiamato `alb-ingressclassparams.yaml`.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Applica la configurazione al cluster:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Fase 3: Creare IngressClass
Crea un file `IngressClass` che faccia riferimento ai valori di configurazione AWS specifici impostati nella `IngressClassParams` risorsa in un file denominato`alb-ingressclass.yaml`. Annotare il nome della `IngressClass`. In questo esempio, sia `IngressClass` che `IngressClassParams` sono denominati `alb`.
Utilizzare l’annotazione `is-default-class` per controllare se le risorse `Ingress` devono utilizzare questa classe per impostazione predefinita.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Per ulteriori informazioni sulle opzioni di configurazione, consultare [IngressClassParams Riferimento](#ingress-reference).
Applica la configurazione al cluster:
```
kubectl apply -f alb-ingressclass.yaml
```
## Fase 4: Creare Ingress
Creare una risorsa `Ingress` in un file denominato `alb-ingress.yaml`. Lo scopo di questa risorsa è associare percorsi e porte sull’Application Load Balancer ai carichi di lavoro del cluster. Per questo esempio, creiamo una risorsa `Ingress` denominata `2048-ingress` che instrada il traffico verso un servizio denominato `service-2048` sulla porta 80.
Per ulteriori informazioni sulla configurazione di questa risorsa, consultare [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) nella documentazione su Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Applica la configurazione al cluster:
```
kubectl apply -f alb-ingress.yaml
```
## Fase 5: Controllare lo stato
Utilizza `kubectl` per trovare lo stato di `Ingress`. Prima che il bilanciatore del carico sia disponibile, potrebbero essere necessari alcuni minuti.
Utilizza il nome della risorsa `Ingress` impostata nella fase precedente. Esempio:
```
kubectl get ingress 2048-ingress
```
Una volta che la risorsa è pronta, recuperare il nome di dominio del bilanciatore del carico.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Per visualizzare il servizio in un browser web, esamina la porta e il percorso specificati nel file di ripristino `Ingress`.
## Fase 6: Eliminazione
Per eliminare il bilanciatore del carico, utilizza il seguente comando:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS Auto Mode eliminerà automaticamente il sistema di bilanciamento del carico associato nel tuo AWS account.
## IngressClassParams Riferimento
La tabella seguente è un riferimento rapido per le opzioni di configurazione più comunemente utilizzate.
| Campo | Description | Valore di esempio |
| --- | --- | --- |
| `scheme` | Definisce se l’ALB è interno o esposto a Internet | `internet-facing` |
| `namespaceSelector` | Limita quali namespace possono utilizzarlo IngressClass | `environment: prod` |
| `group.name` | Raggruppa più ingressi per condividere un singolo ALB | `retail-apps` |
| `ipAddressType` | Imposta il tipo di indirizzo IP per ALB | `dualstack` |
| `subnets.ids` | Elenco di sottoreti per la distribuzione ALB IDs | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Filtri di tag per selezionare le sottoreti per ALB | `Environment: prod` |
| `certificateARNs` | ARNs di certificati SSL da utilizzare | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Tag personalizzati per le risorse AWS | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Attributi specifici del bilanciatore del carico | `idle_timeout.timeout_seconds: 60` |
## Considerazioni
+ Non è possibile utilizzare Annotations su un PC IngressClass per configurare i sistemi di bilanciamento del carico con EKS Auto Mode. IngressClass la configurazione deve essere eseguita tramite. IngressClassParams Tuttavia, è possibile utilizzare le annotazioni sulle singole risorse Ingress per configurare il comportamento del load balancer (ad `alb.ingress.kubernetes.io/security-group-prefix-lists` esempio o). `alb.ingress.kubernetes.io/conditions.*`
+ Non è possibile impostare [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)con EKS Auto Mode.
+ È necessario aggiornare il ruolo Cluster IAM per abilitare la propagazione dei tag dalle risorse Kubernetes alle risorse Load AWS Balancer. Per ulteriori informazioni, consulta [Tag personalizzati per AWS le risorse EKS Auto](auto-learn-iam.md#tag-prop).
+ Per informazioni sull'associazione di risorse a EKS Auto Mode o al Load AWS Balancer Controller autogestito, vedere. [Materiale di riferimento per le migrazioni](migrate-auto.md#migration-reference)
+ Per informazioni sulla risoluzione dei problemi con i bilanciatori del carico, consulta [Risoluzione dei problemi della modalità automatica di EKS](auto-troubleshoot.md).
+ Per ulteriori considerazioni sull’utilizzo della funzionalità di bilanciamento del carico della modalità automatica di EKS, consulta [Sistema di bilanciamento del carico](auto-networking.md#auto-lb-consider).
Le tabelle seguenti forniscono un confronto dettagliato delle modifiche IngressClassParams, delle annotazioni di Ingress e delle TargetGroupBinding configurazioni per EKS Auto Mode. Queste tabelle evidenziano le principali differenze tra la capacità di bilanciamento del carico della modalità automatica di EKS e il controller del bilanciatore del carico open source, comprese le modifiche alla versione dell’API, le funzionalità obsolete e i nomi dei parametri aggiornati.
### IngressClassParams
| Precedente | Novità | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifica alla versione dell’API |
| `spec.certificateArn` | `spec.certificateARNs` | Support per più certificati ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Schema di corrispondenza delle sottoreti modificato |
| `spec.listeners.listenerAttributes` | Non supportata | Non ancora supportato dalla modalità automatica di EKS |
### Annotazioni di ingresso
| Precedente | Novità | Description |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Non supportata | Utilizzare `spec.ingressClassName` su oggetti di ingresso |
| `alb.ingress.kubernetes.io/group.name` | Non supportata | Specificate i gruppi IngressClass solo in |
| `alb.ingress.kubernetes.io/waf-acl-id` | Non supportata | Usare invece WAF v2 |
| `alb.ingress.kubernetes.io/web-acl-id` | Non supportata | Usare invece WAF v2 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Non supportata | Integrazione Shield disattivata |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Non supportata | Il tipo di autenticazione OIDC non è attualmente supportato |
### TargetGroupBinding
| Precedente | Novità | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifica alla versione dell’API |
| `spec.targetType` facoltativo | `spec.targetType` obbligatorio | Specifica esplicita del tipo di destinazione |
| `spec.networking.ingress.from` | Non supportata | Non supporta più NLB senza gruppi di sicurezza |
Per utilizzare la TargetGroupBinding funzionalità personalizzata, devi etichettare il gruppo target con il tag eks: eks-cluster-name tag with cluster name per concedere al controller le autorizzazioni IAM necessarie. Tieni presente che il controller eliminerà il gruppo di destinazione quando la TargetGroupBinding risorsa o il cluster vengono eliminati.
# Usa Annotazioni del servizio per configurare Network Load Balancer
Scopri come configurare Network Load Balancer (NLB) in Amazon EKS utilizzando le annotazioni del servizio di Kubernetes. Questo argomento spiega le annotazioni supportate da EKS Auto Mode per personalizzare il comportamento NLB, tra cui accessibilità Internet, controlli di integrità, SSL/TLS terminazione e modalità di targeting IP.
Quando crei un servizio Kubernetes di tipo `LoadBalancer` in modalità automatica EKS, EKS effettua automaticamente il provisioning e configura un AWS Network Load Balancer in base alle annotazioni specificate. Questo approccio dichiarativo ti consente di gestire le configurazioni del bilanciatore del carico direttamente tramite i manifesti di Kubernetes, mantenendo l’infrastruttura come pratiche di codice.
EKS Auto Mode gestisce il provisioning di Network Load Balancer per impostazione predefinita per tutti i servizi di tipo LoadBalancer : non è richiesta alcuna installazione o configurazione di controller aggiuntivi. La specifica `loadBalancerClass: eks.amazonaws.com/nlb` viene impostata automaticamente come impostazione predefinita del cluster, semplificando il processo di implementazione e mantenendo la compatibilità con i carichi di lavoro di Kubernetes esistenti.
**Nota**
La modalità automatica di EKS richiede i tag di sottorete per identificare le sottoreti pubbliche e private.
Se hai creato il cluster con `eksctl`, disponi già di questi tag.
Informazioni su come [Assegnazione di tag alle sottoreti per la modalità automatica EKS](tag-subnets-auto.md).
## Servizio di esempio
Per ulteriori informazioni sulla risorsa `Service` di Kubernetes, consulta [Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/service/).
Consulta la risorsa di esempio `Service` riportata di seguito:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Annotazioni di uso comune
La tabella seguente elenca le annotazioni di uso comune supportate dalla modalità automatica di EKS. La modalità automatica di EKS potrebbe non supportare tutte le annotazioni.
**Suggerimento**
Tutte le seguenti annotazioni devono avere il prefisso `service.beta.kubernetes.io/`
| Campo | Description | Esempio |
| --- | --- | --- |
| `aws-load-balancer-type` | Specifica il tipo di bilanciatore del carico. Utilizza `external` per nuove implementazioni. | `external` |
| `aws-load-balancer-nlb-target-type` | Speciifica se indirizzare il traffico verso le istanze del nodo o direttamente verso il pod. IPs Utilizza `instance` per implementazioni standard o `ip` per l’instradamento diretto ai pod. | `instance` |
| `aws-load-balancer-scheme` | Controlla se il bilanciatore del carico è interno o esposto a Internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protocollo di controllo dell’integrità per il gruppo di destinazione. Le opzioni più comuni sono `TCP` (impostazione predefinita) o `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Il percorso HTTP per i controlli di integrità quando si utilizza HTTP/HTTPS il protocollo. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Porta utilizzata per i controlli dell’integrità. Può essere un numero di porta specifico o `traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Specifica in quali sottoreti creare il bilanciatore del carico. Può usare sottoreti IDs o nomi. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN del certificato SSL di Certificate Manager for AWS HTTPS/TLS. | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Specifica quali porte devono utilizzare SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Intervalli CIDR autorizzati ad accedere al bilanciatore del carico. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | AWS Tag aggiuntivi da applicare al sistema di bilanciamento del carico e alle risorse correlate. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Speciifica se il load balancer utilizza IPv4 o dual-stack (\$1). IPv4 IPv6 | `ipv4` o `dualstack` |
## Considerazioni
+ È necessario aggiornare il ruolo Cluster IAM per abilitare la propagazione dei tag dalle risorse Kubernetes alle risorse Load AWS Balancer. Per ulteriori informazioni, consulta [Tag personalizzati per AWS le risorse EKS Auto](auto-learn-iam.md#tag-prop).
+ Per informazioni sull'associazione di risorse a EKS Auto Mode o al Load AWS Balancer Controller autogestito, vedere. [Materiale di riferimento per le migrazioni](migrate-auto.md#migration-reference)
+ Per informazioni sulla risoluzione dei problemi con i bilanciatori del carico, consulta [Risoluzione dei problemi della modalità automatica di EKS](auto-troubleshoot.md).
+ Per ulteriori considerazioni sull’utilizzo della funzionalità di bilanciamento del carico della modalità automatica di EKS, consulta [Sistema di bilanciamento del carico](auto-networking.md#auto-lb-consider).
Durante la migrazione alla modalità automatica di EKS per il bilanciamento del carico, sono necessarie diverse modifiche nelle annotazioni dei servizi e nelle configurazioni delle risorse. Le tabelle seguenti descrivono le differenze principali tra le implementazioni precedenti e quelle nuove, includendo le opzioni non supportate e le alternative consigliate.
### Annotazioni dei servizi
| Precedente | Novità | Description |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Non supportata | Usa `spec.loadBalancerSourceRanges` sul servizio |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Non supportata | Usa `spec.loadBalancerClass` sul servizio |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Non supportata | Utilizzare `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` |
| Vari attributi del bilanciatore del carico | Non supportata | Utilizzare `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
Per eseguire la migrazione dalle annotazioni obsolete degli attributi del bilanciatore del carico, consolida queste impostazioni nell’annotazione `service.beta.kubernetes.io/aws-load-balancer-attributes`. Questa annotazione accetta un elenco di coppie chiave-valore separato da virgole per vari attributi del bilanciatore del carico. Ad esempio, per specificare la registrazione degli accessi e il bilanciamento del carico tra zone, utilizzate il seguente formato:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Questo formato consolidato offre un modo più coerente e flessibile per configurare gli attributi del bilanciatore del carico riducendo al contempo il numero di singole annotazioni necessarie. Rivedi le configurazioni del servizio esistenti e aggiornale per utilizzare questo formato consolidato.
### TargetGroupBinding
| Precedente | Novità | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifica alla versione dell’API |
| `spec.targetType` facoltativo | `spec.targetType` obbligatorio | Specifica esplicita del tipo di destinazione |
| `spec.networking.ingress.from` | Non supportata | Non supporta più NLB senza gruppi di sicurezza |
Nota: per utilizzare la TargetGroupBinding funzionalità personalizzata, è necessario etichettare il gruppo di destinazione con il tag con il `eks:eks-cluster-name` nome del cluster per concedere al controller le autorizzazioni IAM necessarie. Tieni presente che il controller eliminerà il gruppo di destinazione quando la TargetGroupBinding risorsa o il cluster vengono eliminati.
# Crea una classe di archiviazione
Una `StorageClass` in Amazon EKS Auto Mode definisce come i volumi Amazon EBS vengono forniti automaticamente quando le applicazioni richiedono uno storage persistente. In questa pagina viene spiegato come creare e configurare una `StorageClass` che funzioni con Amazon EKS Auto Mode per il provisioning dei volumi EBS.
Configurando una `StorageClass`, è possibile specificare le impostazioni predefinite per i volumi EBS, inclusi il tipo di volume, la crittografia, gli IOPS e altri parametri di storage. Puoi anche configurare l'utilizzo delle `StorageClass` chiavi AWS KMS per la gestione della crittografia.
EKS Auto Mode non crea una `StorageClass` per te. Devi creare una `StorageClass` che faccia riferimento a `ebs.csi.eks.amazonaws.com` per usare la funzionalità di storage di EKS Auto Mode.
Per prima cosa, crea un file denominato `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Poi applica la classe di archiviazione al cluster.
```
kubectl apply -f storage-class.yaml
```
**Componenti chiave:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: usa EKS Auto Mode
+ `allowedTopologies`: specificando `matchLabelExpressions` in modo che corrisponda con `eks.amazonaws.com/compute-type:auto`, se i pod richiedono un volume su cui effettuare il provisioning automatico usando Auto Mode, i pod non verranno pianificati su nodi non automatici.
+ `volumeBindingMode: WaitForFirstConsumer`: ritarda la creazione del volume fino a quando un pod non ne ha bisogno
+ `type: gp3`: specifica il tipo di volume EBS
+ `encrypted: "true"`: EBS crittograferà tutti i volumi creati usando la `StorageClass`. EBS userà l’alias chiave predefinito `aws/ebs`. Per ulteriori informazioni, consulta [How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) nella Guida per l’utente di Amazon EBS. Questo valore è opzionale ma consigliato.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes userà questa classe di archiviazione per impostazione predefinita, a meno che non venga specificata una classe di volume diversa su una dichiarazione di volume persistente. Questo valore è facoltativo. Presta attenzione quando imposti questo valore se stai effettuando la migrazione da un controller di storage diverso.
## Usa la chiave KMS autogestita per crittografare i volumi EBS
Per usare una chiave KMS autogestita per crittografare i volumi EBS automatizzati da EKS Auto Mode, bisogna:
1. Creare una chiave KMS gestita dal cliente.
+ Per ulteriori informazioni, consulta [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) o [How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) nella Guida per gli utenti di KMS.
1. Creare una nuova policy che consenta l’accesso alla chiave KMS.
+ Usa la policy IAM di esempio riportata di seguito per creare la policy. Inserisci l’ARN della nuova chiave KMS autogestita. Per ulteriori informazioni, consulta [Creazione di ruoli e collegamento di politiche (console) nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) per l'utente AWS IAM.
1. Collegare la policy al ruolo del cluster EKS.
+ Usa la AWS console per trovare l'ARN dell'EKS Cluster Role. Le informazioni relative al ruolo sono visibili nella sezione **Panoramica**. Per ulteriori informazioni, consulta [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md).
1. Aggiornare la `StorageClass` per fare riferimento all’ID della chiave KMS nel campo `parameters.kmsKeyId`.
### Esempio di policy IAM KMS autogestita
Aggiorna i valori seguenti nella policy riportata di seguito:
+ ``— L'ID AWS del tuo account, ad esempio `111122223333`
+ ``— La AWS regione del cluster, ad esempio `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Esempio di `StorageClass` KMS gestita dal cliente
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## Guida di riferimento per i parametri `StorageClass`
Per informazioni generali sulle risorse `StorageClass` di Kubernetes, consulta [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/) nella documentazione di Kubernetes.
THe `parameters`la sezione della `StorageClass` risorsa è specifica per AWS. Utilizza la tabella seguente per esaminare le opzioni disponibili.
| Parameters | Valori | Predefinita | Description |
| --- | --- | --- | --- |
| “csi.storage.k8s.io/fstype” | xfs, ext2, ext3, ext4 | ext4 | Tipo di file system che verrà formattato al momento della creazione del volume. Questo parametro prevede la distinzione tra maiuscole e minuscole. |
| “type” | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | Tipo di volume EBS. |
| “iopsPerGB” | | | Operazioni di I/O al secondo per GiB. Può essere specificato per IO1 IO2, e GP3 volumi. |
| «Consenti automaticamente IOPSPerGBIncrease» | true, false | false | Quando`"true"`, il driver CSI aumenta gli IOPS per un volume troppo basso per rientrare nell'intervallo IOPS supportato da. `iopsPerGB * ` AWS Ciò consente al provisioning dinamico di avere sempre esito positivo, anche quando l’utente specifica una capacità PVC o un valore `iopsPerGB` troppo bassi. D’altra parte, ciò potrebbe comportare costi aggiuntivi, poiché tali volumi hanno un IOPS superiore a quello richiesto in `iopsPerGB`. |
| “iops” | | | Operazioni di I/O al secondo. Può essere specificato per IO1 IO2, e volumi. GP3 |
| “throughput” | | 125 | Velocità di trasmissione effettiva in MiB/S. Efficace solo quando è specificato il tipo di volume gp3. |
| “encrypted” | true, false | false | Se il volume deve essere crittografato o no. I valori validi sono “true” o “false”. |
| “blockExpress” | true, false | false | Permette la creazione di Volumi io2 Block Express. |
| "kmsKeyId" | | | L’ARN completo della chiave da usare per la crittografia del volume. Se non specificato, AWS utilizzerà la chiave KMS predefinita per la regione in cui si trova il volume. Si tratta di una chiave generata automaticamente chiamata `/aws/ebs` se non viene modificata. |
| “blockSize” | | | La dimensione del blocco da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| “inodeSize” | | | La dimensione dell’inode da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| "bytesPerInode" | | | `bytes-per-inode` da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4`. |
| "numberOfInodes" | | | `number-of-inodes` da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4`. |
| «BigAllocext4" | true, false | false | Modifica il filesystem `ext4` per usare l’allocazione di blocchi in cluster abilitando l’opzione di formattazione `bigalloc`. Attenzione: `bigalloc` potrebbe non essere completamente supportato dal kernel Linux del nodo. |
| «ClusterSizeext4» | | | La dimensione del cluster da usare per formattare un filesystem `ext4` quando la funzionalità `bigalloc` è abilitata. Nota: il parametro `ext4BigAlloc` deve essere impostato su true |
Per ulteriori informazioni, consulta [AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md) Driver su. GitHub
## Considerazioni
**Nota**
È possibile distribuire carichi di lavoro solo in base alla modalità EKS Auto Mode sui nodi EKS Auto Mode StorageClasses . Se hai un cluster con tipi misti di nodi, devi configurare i carichi di lavoro in modo che vengano eseguiti solo sui nodi EKS Auto Mode. Per ulteriori informazioni, consulta [Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode](associate-workload.md).
La funzionalità di storage a blocchi di EKS Auto Mode è diversa da quella del driver CSI EBS.
+ Provisioning statico
+ Se desideri utilizzare volumi EBS creati esternamente con EKS Auto Mode, devi aggiungere manualmente un AWS tag con la chiave `eks:eks-cluster-name` e il valore del nome del cluster.
+ Taint startup del nodo
+ Non è possibile usare la funzionalità taint startup del nodo per impedire la pianificazione dei pod prima che la capacità di storage sia pronta
+ Tag personalizzati su volumi con provisioning dinamico
+ Non è possibile usare il flag CLI extra-tag per configurare tag personalizzati su volumi EBS con provisioning dinamico
+ Puoi usare l’assegnazione di tag `StorageClass` per aggiungere tag personalizzati. EKS Auto Mode aggiungerà tag alle risorse associate. AWS Dovrai aggiornare il ruolo del IAM cluster per i tag personalizzati. Per ulteriori informazioni, consulta [Tag personalizzati per AWS le risorse EKS Auto](auto-learn-iam.md#tag-prop).
+ Metriche sulle prestazioni dettagliate di EBS
+ Non puoi accedere alle metriche di Prometheus per le prestazioni dettagliate di EBS
## Installa il componente aggiuntivo CSI Snapshot Controller
EKS Auto Mode è compatibile con il componente aggiuntivo CSI Snapshot Controller di Amazon EKS.
AWS suggerisce di configurare questo componente aggiuntivo per l'esecuzione nel pool di `system` nodi integrato.
Per ulteriori informazioni, consulta:
+ [Eseguire componenti aggiuntivi critici su istanze dedicate](critical-workload.md)
+ [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md)
+ [Abilitare la funzionalità snapshot per i volumi CSI](csi-snapshot-controller.md)
### Per installare il controller di snapshot nel pool di nodi di sistema
1. Apri il tuo cluster EKS nella console AWS
1. Nella scheda **Componenti aggiuntivi**, seleziona **Ottieni altri componenti aggiuntivi**
1. Seleziona il controller **CSI Snapshot** e poi **Avanti**
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, seleziona **Impostazioni di configurazione opzionali** per visualizzare lo **schema di configurazione dei componenti aggiuntivi**
1. Inserisci il seguente yaml per associare il controller di snapshot al pool di nodi `system`. Il controller di snapshot include una tolleranza per il taint `CriticalAddonsOnly`.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Seleziona **Avanti**
1. Esamina la configurazione del componente aggiuntivo, poi seleziona **Crea**
# Disabilita modalità automatica di EKS
Puoi disabilita modalità automatica di EKS su un cluster EKS esistente. Si tratta di un’operazione distruttiva.
+ EKS interromperà tutte le EC2 istanze gestite da EKS Auto Mode.
+ EKS eliminerà tutti i bilanciatori del carico gestiti dalla modalità automatica di EKS.
+ EKS **non** eliminerà i volumi EBS forniti dalla modalità automatica di EKS.
modalità automatica di EKS è progettato per gestire completamente le risorse che crea. Gli interventi manuali potrebbero impedire alla modalità automatica di EKS di ripulire completamente tali risorse quando è disabilitata. Ad esempio, se hai fatto un riferimento a un gruppo di sicurezza gestito da regole esterne del gruppo di sicurezza e ti dimentica di rimuovere quel riferimento prima di disabilitare modalità automatica di EKS per un cluster, il gruppo di sicurezza gestito verrà divulgato (non verrà eliminato). Le fasi seguenti descrivono come rimuovere un gruppo di sicurezza trapelato se ciò dovesse accadere.
## Disattiva la modalità automatica EKS (console)AWS
1. Apri la pagina di panoramica del cluster in Console di gestione AWS.
1. In **modalità automatica di EKS**, seleziona **Gestisci**
1. Attiva **modalità automatica di EKS** su `off`.
Se un gruppo di sicurezza gestito non viene eliminato al termine di questo processo, puoi eliminarlo manualmente utilizzando le descrizioni in [Elimina un gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Disattiva la modalità automatica EKS (AWS CLI)
Utilizza il seguente comando per disabilitare modalità automatica di EKS su un cluster esistente.
Devi aver installato `aws` CLI ed essere connesso con autorizzazioni sufficienti per gestire i cluster EKS. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
**Nota**
Le funzionalità di calcolo, archiviazione a blocchi e bilanciamento del carico devono essere tutte abilitate o disabilitate nella stessa richiesta.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Puoi verificare se non è stato possibile eliminare un gruppo di sicurezza della modalità automatica di EKS divulgato dopo aver disabilitato modalità automatica di EKS nel modo seguente:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Poi, per eliminare il gruppo di sicurezza:
```
aws ec2 delete-security-group --group-name=
```
# Aggiornare la versione Kubernetes di un cluster di Amazon EKS Auto Mode
Questo argomento ti spiega come aggiornare la versione di Kubernetes per il cluster Auto Mode. Auto Mode semplifica il processo di aggiornamento delle versioni gestendo il coordinamento degli aggiornamenti del piano di controllo con la sostituzione dei nodi, mantenendo al contempo la disponibilità del carico di lavoro attraverso i budget relativi all’interruzione dei pod.
Quando si aggiorna un cluster Auto Mode, molti componenti che tradizionalmente richiedevano aggiornamenti manuali vengono ora gestiti come parte del servizio. Comprendere gli aspetti automatizzati del processo di aggiornamento e le proprie responsabilità aiuta a garantire una transizione fluida delle versioni per il cluster.
## Informazioni sugli aggiornamenti con EKS Auto Mode
Dopo che hai avviato un aggiornamento del piano di controllo, EKS Auto Mode aggiornerà i nodi del cluster. Alla scadenza dei nodi, EKS Auto Mode li sostituirà con nuovi nodi. I nuovi nodi hanno la nuova versione di Kubernetes corrispondente. EKS Auto Mode rispetta i budget relativi alle interruzioni dei pod durante l’aggiornamento dei nodi.
Inoltre, non dovrai più aggiornare componenti come:
+ CNI di Amazon VPC
+ Controller del load balancerAWS
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS Driver CSI per EBS
EKS Auto Mode sostituisce questi componenti con funzionalità di servizio.
L’utente è ancora responsabile dell’aggiornamento di:
+ App e carichi di lavoro implementati nel cluster
+ Componenti aggiuntivi e controller autogestiti
+ Componenti aggiuntivi di Amazon EKS
+ Informazioni su come [Aggiornamento di un componente aggiuntivo di Amazon EKS](updating-an-add-on.md)
Informazioni su [Best Practices for Cluster Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Avviare l’aggiornamento del cluster
Per avviare un aggiornamento del cluster, consulta [Aggiornamento del cluster esistente alla nuova versione di Kubernetes](update-cluster.md).
# Attivazione o disattivazione della funzionalità integrata NodePools
La modalità automatica EKS ne ha due integrate NodePools. Puoi abilitarli o disabilitarli NodePools utilizzando la AWS console, la CLI o l'API.
## Riferimento integrato NodePool
+ `system`
+ Questo NodePool ha una `CriticalAddonsOnly` macchia. Molti componenti aggiuntivi EKS, come CoredNS, tollerano questo taint. Utilizza questo pool di nodi di sistema per separare le applicazioni critiche per il cluster.
+ Supporta entrambe le architetture `amd64` e `arm64`.
+ `general-purpose`
+ Ciò NodePool fornisce supporto per l'avvio di nodi per carichi di lavoro generici nel cluster.
+ Utilizza solo l’architettura `amd64`.
Entrambi integrati: NodePools
+ Usa l'EKS predefinito NodeClass
+ Utilizza solo la capacità su richiesta EC2
+ Usa le famiglie di EC2 istanze C, M e R
+ Richiede istanze di quinta generazione o successive EC2
**Nota**
NodePool È necessario abilitare almeno una funzionalità integrata per consentire a EKS di eseguire il provisioning delle impostazioni «predefinite». NodeClass Se disabiliti tutte le funzionalità integrate NodePools, dovrai crearne una personalizzata NodeClass e configurarne una NodePool per utilizzarla. Per ulteriori informazioni su NodeClasses, consulta[Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
## Procedura
### Prerequisiti
+ La versione più recente dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo. Per verificare la versione attuale, usa `aws --version`. Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [configurazione rapida](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) con aws configure nella Guida per l'utente dell'interfaccia a riga di AWS comando.
+ Accedi alla CLI con autorizzazioni IAM sufficienti per creare AWS risorse tra cui politiche IAM, ruoli IAM e cluster EKS.
### Abilita con AWS CLI
Usa il seguente comando per abilitare entrambi i componenti integrati NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
È possibile modificare il comando per abilitare selettivamente il NodePools.
### Disabilita con AWS CLI
Usa il seguente comando per disabilitare entrambi i componenti integrati NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode
Quando si eseguono carichi di lavoro in un cluster EKS con EKS Auto Mode, potresti dover controllare se carichi di lavoro specifici vengono eseguiti su nodi EKS Auto Mode o altri tipi di elaborazione. Questo argomento descrive come utilizzare i selettori di nodi e le regole di affinità per garantire che i carichi di lavoro siano pianificati sull’infrastruttura di elaborazione prevista.
Gli esempi in questo argomento mostrano come utilizzare l’etichetta `eks.amazonaws.com/compute-type` per richiedere o impedire l’implementazione del carico di lavoro sui nodi di EKS Auto Mode. Ciò è particolarmente utile nei cluster a modalità mista in cui è in esecuzione sia EKS Auto Mode che altri tipi di elaborazione, come i provisioner Karpenter autogestiti o i gruppi di nodi gestiti da EKS.
I nodi di EKS Auto Mode hanno impostato il valore dell’etichetta da `eks.amazonaws.com/compute-type` a `auto`. Puoi utilizzare questa etichetta per controllare se un carico di lavoro viene implementato nei nodi gestiti da EKS Auto Mode.
## Richiedono che un carico di lavoro venga implementato ai nodi di EKS Auto Mode
**Nota**
Questo valore `nodeSelector` non è richiesto per EKS Auto Mode. Questo valore `nodeSelector` è rilevante solo se si esegue un cluster in modalità mista, con tipi di nodi non gestiti da EKS Auto Mode. Ad esempio, puoi avere una capacità di elaborazione statica implementata nel cluster con o gruppi di nodi gestiti da EKS e avere una capacità di elaborazione dinamica gestita da EKS Auto Mode.
Puoi aggiungere questo `nodeSelector` alle implementazioni o ad altri carichi di lavoro per richiedere che Kubernetes li pianifichi sui nodi di EKS Auto Mode.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Richiedono che un carico di lavoro non venga implementato ai nodi di EKS Auto Mode
Puoi aggiungere questo `nodeAffinity` alle implementazioni o ad altri carichi di lavoro per richiedere che Kubernetes **non** li pianifichi sui nodi di EKS Auto Mode.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Eseguire componenti aggiuntivi critici su istanze dedicate
Questo argomento illustra come implementare un carico di lavoro con una tolleranza `CriticalAddonsOnly` in modo che la modalità automatica EK lo pianifichi nel pool di nodi `system`.
Il pool di nodi integrato `system` della modalità automatica EKS è progettato per eseguire componenti aggiuntivi critici su istanze dedicate. Questa segregazione garantisce che i componenti essenziali dispongano di risorse dedicate e siano isolati dai carichi di lavoro generali, migliorando la stabilità e le prestazioni complessive del cluster.
Questa guida illustra come implementare componenti aggiuntivi nel pool di nodi `system` utilizzando la tolleranza `CriticalAddonsOnly` e i selettori dei nodi adeguati. Seguendo questa procedura, è possibile garantire che le applicazioni critiche siano pianificate sui nodi `system` dedicati, sfruttando i vantaggi dell’isolamento e dell’allocazione delle risorse offerti dalla struttura specializzata dei pool di nodi della modalità automatica EKS.
La modalità automatica EKS dispone di due pool di nodi integrati: `general-purpose` e `system`. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
Lo scopo del pool di nodi `system` è segregare i componenti aggiuntivi critici su nodi diversi. I nodi con provisioning del pool di nodi `system` hanno un taint Kubernetes `CriticalAddonsOnly`. Kubernetes pianificherà i pod su questi nodi solo se dispongono di una tolleranza corrispondente. Per ulteriori informazioni, consultare [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nella documentazione di Kubernetes.
## Prerequisiti
+ Cluster di modalità automatica EKS con il pool di nodi integrato `system` abilitato. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md)
+ `kubectl` installato e configurato. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Procedura
Rivedere l’esempio yaml riportato di seguito. Tenere presente le configurazioni seguenti:
+ `nodeSelector`: questa configurazione associa il carico di lavoro al pool di nodi integrato `system`. Questo pool di nodi deve essere abilitato con l’API AWS. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
+ `tolerations`: questa tolleranza supera il taint `CriticalAddonsOnly` sui nodi del pool di nodi `system`.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Per aggiornare un carico di lavoro affinché venga eseguito sul pool di nodi `system` è necessario:
1. Aggiornare il carico di lavoro esistenti affinché aggiunga le seguenti configurazioni descritte in precedenza:
+ `nodeSelector`
+ `tolerations`
1. Implementare il carico di lavoro aggiornato nel cluster con `kubectl apply`.
Una volta aggiornato, il carico di lavoro sarà eseguito su nodi dedicati.
# Usa le policy di rete con la modalità automatica di EKS
## Panoramica di
Man mano che i clienti scalano i propri ambienti applicativi utilizzando EKS, l'isolamento del traffico di rete diventa sempre più fondamentale per prevenire l'accesso non autorizzato alle risorse all'interno e all'esterno del cluster. Ciò è particolarmente importante in un ambiente multi-tenant con più carichi di lavoro non correlati che vengono eseguiti fianco a fianco nel cluster. Le policy di rete Kubernetes consentono di migliorare il livello di sicurezza della rete per i carichi di lavoro Kubernetes e le relative integrazioni con endpoint esterni al cluster. EKS Auto Mode supporta diversi tipi di politiche di rete.
### Isolamento di livello 3 e 4
Le policy di rete Kubernetes standard operano ai livelli 3 e 4 del modello di rete OSI e consentono di controllare il flusso di traffico a livello di indirizzo IP o di porta all'interno del cluster Amazon EKS.
#### Casi d’uso
+ Segmenta il traffico di rete tra i carichi di lavoro per garantire che solo le applicazioni correlate possano comunicare tra loro.
+ Isola i tenant a livello di namespace utilizzando policy per imporre la separazione della rete.
### Applicazione basata sul DNS
I clienti in genere implementano carichi di lavoro in EKS che fanno parte di un ambiente distribuito più ampio, alcuni dei quali devono comunicare con sistemi e servizi esterni al cluster (traffico in direzione nord). Questi sistemi e servizi possono essere nel AWS cloud o all'esterno. AWS Le policy basate sul Domain Name System (DNS) consentono di rafforzare il livello di sicurezza adottando un approccio più stabile e prevedibile per impedire l'accesso non autorizzato dai pod a risorse o endpoint esterni al cluster. Questo meccanismo elimina la necessità di tracciare e consentire manualmente l'elenco di indirizzi IP specifici. Proteggendo le risorse con un approccio basato sul DNS, si ha anche una maggiore flessibilità nell'aggiornare l'infrastruttura esterna senza dover allentare il livello di sicurezza o modificare le politiche di rete a causa delle modifiche apportate ai server e agli host upstream. È possibile filtrare il traffico in uscita verso endpoint esterni utilizzando un nome di dominio completo (FQDN) o uno schema corrispondente per un nome di dominio DNS. Ciò offre la maggiore flessibilità di estendere l'accesso a più sottodomini associati a un particolare endpoint esterno al cluster.
#### Casi d’uso
+ Standardizza un approccio basato su DNS per filtrare l'accesso da un ambiente Kubernetes agli endpoint esterni al cluster.
+ Accesso AWS sicuro ai servizi in un ambiente multi-tenant.
+ Gestisci l'accesso alla rete dai pod ai carichi di lavoro on-premise nei tuoi ambienti cloud ibridi.
### Regole amministrative (o con ambito cluster)
In alcuni casi, come negli scenari multi-tenant, i clienti potrebbero avere l'esigenza di applicare uno standard di sicurezza di rete applicabile all'intero cluster. Invece di definire e mantenere ripetutamente una policy distinta per ogni namespace, è possibile utilizzare un'unica policy per gestire centralmente i controlli di accesso alla rete per i diversi carichi di lavoro del cluster, indipendentemente dal relativo namespace. Questi tipi di policy consentono di estendere l'ambito di applicazione delle regole di filtraggio di rete applicate a livello 3, livello 4 e quando si utilizzano regole DNS.
#### Casi d’uso
+ Gestisci centralmente i controlli di accesso alla rete per tutti (o un sottoinsieme di) carichi di lavoro nel tuo cluster EKS.
+ Definisci una posizione di sicurezza di rete predefinita in tutto il cluster.
+ Estendi gli standard di sicurezza organizzativi all'ambito del cluster in un modo più efficiente dal punto di vista operativo.
## Nozioni di base
### Prerequisiti
+ Un cluster Amazon EKS con la modalità automatica di EKS abilitata
+ kubectl configurato per connettersi al cluster
### Fase 1: abilitare il controller della policy di rete
Per utilizzare le politiche di rete con EKS Auto Mode, devi prima abilitare il Network Policy Controller applicando un ConfigMap al tuo cluster.
1. Crea un file denominato `enable-network-policy.yaml` con i seguenti contenuti:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Applica il ConfigMap al tuo cluster:
```
kubectl apply -f enable-network-policy.yaml
```
### Fase 2: Creare e testare le politiche di rete
Il cluster della modalità automatica di EKS è ora configurato per supportare le policy di rete di Kubernetes. Puoi testarlo con la [Demo delle policy di rete con Stars per Amazon EKS](network-policy-stars-demo.md).
### Fase 3: Modifica della configurazione di Network Policy Agent in Node Class (opzionale)
Facoltativamente, è possibile creare una nuova classe di nodi per modificare il comportamento predefinito del Network Policy Agent sui nodi o abilitare la registrazione degli eventi di Network Policy. A tale scopo, seguire queste fasi:
1. Crea o modifica un file YAML di classe del nodo (ad esempio, `nodeclass-network-policy.yaml`) con i seguenti contenuti:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Applica la configurazione di classe del nodo al cluster:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Verifica che la classe del nodo sia stata creata:
```
kubectl get nodeclass network-policy-config
```
1. Aggiorna il pool di nodi per utilizzare questa classe di nodi. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
## Come funziona?
### Politica di rete basata su DNS
![\[Illustrazione del flusso di lavoro quando viene applicata una politica basata su DNS in EKS Auto\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Illustrazione del flusso di lavoro quando una politica basata su DNS viene applicata in EKS Auto\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/apply-dns-policy-2.png)
1. Il team della piattaforma applica una politica basata su DNS al cluster EKS.
1. Il Network Policy Controller è responsabile del monitoraggio della creazione delle politiche all'interno del cluster e della successiva riconciliazione degli endpoint delle politiche. In questo caso d'uso, il network policy controller ordina all'agente del nodo di filtrare le richieste DNS in base ai domini consentiti elencati nella policy creata. I nomi di dominio vengono elencati nell'elenco consentito utilizzando l'FQDN o un nome di dominio che corrisponde a uno schema definito nella configurazione delle risorse Kubernetes.
1. Workload A tenta di risolvere l'IP per un endpoint esterno al cluster. La richiesta DNS passa innanzitutto attraverso un proxy che filtra tali richieste in base all'elenco di autorizzazioni applicato tramite la politica di rete.
1. Una volta che la richiesta DNS passa attraverso l'elenco dei filtri DNS consentiti, viene inoltrata tramite proxy a CoredNS,
1. CoreDNS a sua volta invia la richiesta al Resolver DNS esterno (Amazon Route 53 Resolver) per ottenere l'elenco degli indirizzi IP dietro il nome di dominio.
1. I dati risolti IPs con TTL vengono restituiti nella risposta alla richiesta DNS. Questi IPs vengono quindi scritti in una mappa eBPF che viene utilizzata nella fase successiva per l'applicazione del livello IP.
1. Le sonde eBPF collegate all'interfaccia Pod veth filtreranno quindi il traffico in uscita dal carico di lavoro A all'endpoint esterno del cluster in base alle regole in vigore. Ciò garantisce che i pod possano inviare traffico esterno al cluster solo verso i domini consentiti elencati. IPs La validità di questi si IPs basa sul TTL recuperato dal Resolver DNS esterno (Amazon Route 53 Resolver).
#### Utilizzo della policy di rete dell'applicazione
`ApplicationNetworkPolicy`Combina le funzionalità delle politiche di rete Kubernetes standard con il filtraggio basato su DNS a livello di namespace utilizzando un'unica Custom Resource Definition (CRD). Pertanto, può essere utilizzato per: `ApplicationNetworkPolicy`
1. Definizione delle restrizioni ai livelli 3 e 4 dello stack di rete utilizzando blocchi IP e numeri di porta.
1. Definizione di regole che operano al livello 7 dello stack di rete e consentono di filtrare il traffico in base a. FQDNs
**Importante**
Le regole basate sul DNS definite utilizzando la `ApplicationNetworkPolicy` sono applicabili solo ai carichi di lavoro in esecuzione su istanze EC2 lanciate da EKS Auto Mode. `ApplicationNetworkPolicy`supporta tutti i campi dello standard Kubernetes, con un filtro FQDN aggiuntivo per le regole di `NetworkPolicy` uscita.
**avvertimento**
Non utilizzare lo stesso nome per un `ApplicationNetworkPolicy` e un all'interno dello stesso spazio dei nomi. `NetworkPolicy` Se i nomi entrano in conflitto, gli `PolicyEndpoints` oggetti risultanti potrebbero non riflettere correttamente nessuna delle due politiche. Entrambe le risorse vengono accettate senza errori, il che rende difficile la diagnosi di questo problema.
Per risolvere un conflitto di denominazione, rinomina i `ApplicationNetworkPolicy` o i in `NetworkPolicy` modo che siano univoci all'interno dello spazio dei nomi, quindi verifica che gli oggetti corrispondenti `PolicyEndpoints` siano aggiornati correttamente.
#### Esempio
Nel cluster EKS Auto Mode è presente un carico di lavoro che deve comunicare con un'applicazione locale basata su un sistema di bilanciamento del carico con un nome DNS. È possibile ottenere ciò utilizzando la seguente politica di rete:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
**A livello di rete Kubernetes, ciò consentirebbe l'uscita da qualsiasi pod nello spazio dei nomi «galaxy» etichettato con `role: backend` per connettersi al nome di dominio myapp.mydomain.com sulla porta TCP 8080.** Inoltre, è necessario configurare la connettività di rete per il traffico in uscita dal VPC al data center aziendale.
![\[Illustrazione del carico di lavoro in EKS Auto: comunicazione con le applicazioni in locale\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Politica di rete di amministrazione (o cluster)
![\[Illustrazione dell'ordine di valutazione delle politiche di rete in EKS\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/evaluation-order.png)
#### Utilizzo della politica di rete del cluster
Quando si utilizza a`ClusterNetworkPolicy`, le politiche del livello di amministrazione vengono valutate per prime e non possono essere sostituite. Una volta valutate le politiche di livello amministratore, le politiche standard con ambito dei namespace vengono utilizzate per eseguire le regole di segmentazione della rete applicate. Questa operazione può essere eseguita utilizzando uno dei due o. `ApplicationNetworkPolicy` `NetworkPolicy` Infine, verranno applicate le regole del livello di base che definiscono le restrizioni di rete predefinite per i carichi di lavoro dei cluster. Queste regole del livello di base **possono** essere sostituite dalle policy con ambito dei namespace, se necessario.
#### Esempio
Nel cluster è presente un'applicazione che si desidera isolare dagli altri carichi di lavoro dei tenant. È possibile bloccare in modo esplicito il traffico del cluster proveniente da altri namespace per impedire l'accesso di rete allo spazio dei nomi riservato del carico di lavoro.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Considerazioni
### Comprendi l'ordine di valutazione delle politiche
Le funzionalità relative alle politiche di rete supportate in EKS vengono valutate in un ordine specifico per garantire una gestione del traffico prevedibile e sicura. Pertanto, è importante comprendere il flusso di valutazione per progettare una posizione di sicurezza di rete efficace per il proprio ambiente.
1. **Politiche del livello di amministrazione (valutate per prime)**: tutte le politiche di livello amministratore ClusterNetworkPolicies vengono valutate prima di qualsiasi altra politica. All'interno del livello di amministrazione, le politiche vengono elaborate in ordine di priorità (prima il numero di priorità più basso). Il tipo di azione determina cosa succede dopo.
+ **Nega azione (priorità massima)**: quando una politica di amministrazione con un'azione Rifiuta corrisponde al traffico, tale traffico viene immediatamente bloccato indipendentemente da qualsiasi altra politica. Non vengono elaborate ClusterNetworkPolicy ulteriori NetworkPolicy regole. Ciò garantisce che i controlli di sicurezza a livello di organizzazione non possano essere sostituiti da politiche a livello di namespace.
+ **Consenti azioni**: dopo la valutazione delle regole Deny, le politiche di amministrazione con le azioni Consenti vengono elaborate in ordine di priorità (inizia con il numero di priorità più basso). Quando un'azione Consenti corrisponde, il traffico viene accettato e non viene effettuata alcuna ulteriore valutazione delle politiche. Queste politiche possono concedere l'accesso su più namespace in base a selettori di etichette, fornendo un controllo centralizzato su quali carichi di lavoro possono accedere a risorse specifiche.
+ **Pass action**: le azioni Pass Action nelle policy del livello di amministrazione delegano il processo decisionale ai livelli inferiori. Quando il traffico corrisponde a una regola Pass, la valutazione salta tutte le regole rimanenti del livello di amministratore per quel traffico e passa direttamente al livello. NetworkPolicy Ciò consente agli amministratori di delegare in modo esplicito il controllo di determinati modelli di traffico ai team applicativi. Ad esempio, è possibile utilizzare le regole Pass per delegare la gestione del traffico all'interno del namespace agli amministratori del namespace, mantenendo al contempo controlli rigorosi sull'accesso esterno.
1. **Livello di policy di rete**: se nessuna politica del livello di amministratore corrisponde a Deny o Allow, o se è stata soddisfatta un'azione Pass, vengono successivamente valutate le risorse tradizionali e con ambito namespace. ApplicationNetworkPolicy NetworkPolicy Queste policy forniscono un controllo granulare all'interno dei singoli namespace e sono gestite dai team applicativi. Le politiche con ambito namespace possono essere solo più restrittive delle politiche di amministrazione. Non possono ignorare la decisione di rifiuto di una politica di amministrazione, ma possono limitare ulteriormente il traffico consentito o approvato dalle politiche di amministrazione.
1. **Politiche di amministrazione di livello base**: se nessuna politica di amministrazione o con ambito del namespace corrisponde al traffico, viene valutato il livello di base. ClusterNetworkPolicies Queste forniscono posizioni di sicurezza predefinite che possono essere sostituite da policy con ambito namespace, consentendo agli amministratori di impostare impostazioni predefinite a livello di organizzazione e offrendo al contempo ai team la flessibilità necessaria per personalizzarle in base alle esigenze. Le politiche di base vengono valutate in ordine di priorità (per primo il numero di priorità più basso).
1. **Negazione predefinita (se nessuna policy corrisponde)**: questo deny-by-default comportamento garantisce che siano consentite solo le connessioni esplicitamente consentite, mantenendo un solido livello di sicurezza.
### Applicazione del principio del privilegio minimo
+ **Inizia con politiche restrittive e aggiungi gradualmente le autorizzazioni secondo necessità**. Inizia implementando le deny-by-default politiche a livello di cluster, quindi aggiungi in modo incrementale le regole di autorizzazione man mano che convalidi i requisiti di connettività legittimi. Questo approccio obbliga i team a giustificare esplicitamente ogni connessione esterna, creando un ambiente più sicuro e verificabile.
+ **Verifica e rimuovi regolarmente le regole di policy non utilizzate: le policy** di rete possono accumularsi nel tempo man mano che le applicazioni si evolvono, lasciando dietro di sé regole obsolete che ampliano inutilmente la superficie di attacco. Implementate un processo di revisione regolare per identificare e rimuovere le regole di policy che non sono più necessarie, assicurando che il vostro livello di sicurezza rimanga rigoroso e gestibile.
+ **Se possibile, utilizza nomi di dominio specifici anziché schemi generici. Se** da un lato i modelli wildcard `*.amazonaws.com` offrono maggiore praticità, dall'altro garantiscono l'accesso a un'ampia gamma di servizi. Ove possibile, specifica nomi di dominio esatti, `s3.us-west-2.amazonaws.com` ad esempio per limitare l'accesso solo ai servizi specifici richiesti dalle applicazioni, riducendo il rischio di spostamenti laterali se un carico di lavoro è compromesso.
### Utilizzo di policy basate su DNS in EKS
+ Le regole basate su DNS definite utilizzando `ApplicationNetworkPolicy` sono applicabili solo ai carichi di lavoro in esecuzione su istanze EC2 lanciate in modalità EKS Auto. Se utilizzi un cluster in modalità mista (composto da nodi di lavoro EKS Auto e non EKS Auto), le regole basate sul DNS sono efficaci solo nei nodi di lavoro in modalità EKS Auto (istanze gestite EC2).
### Convalida delle politiche DNS
+ **Utilizzate cluster di staging che rispecchiano la topologia della rete di produzione per i test**: l'ambiente di staging deve replicare l'architettura di rete, le dipendenze esterne e i modelli di connettività di produzione per garantire un test accurato delle politiche. Ciò include configurazioni VPC corrispondenti, comportamento di risoluzione DNS e accesso agli stessi servizi esterni richiesti dai carichi di lavoro di produzione.
+ **Implementa test automatizzati per percorsi di rete critici**: crea test automatizzati che convalidano la connettività ai servizi esterni essenziali come parte della tua pipeline. CI/CD Questi test devono verificare che i flussi di traffico legittimi siano consentiti mentre le connessioni non autorizzate vengono bloccate, in modo da confermare continuamente che le politiche di rete mantengano il corretto livello di sicurezza man mano che l'infrastruttura si evolve.
+ **Monitora il comportamento delle applicazioni dopo le modifiche alle policy**: dopo aver implementato policy di rete nuove o modificate nella produzione, monitorate attentamente i log delle applicazioni, i tassi di errore e le metriche prestazionali per identificare rapidamente eventuali problemi di connettività. Stabilisci procedure di rollback chiare in modo da poter ripristinare rapidamente le modifiche alle policy se causano comportamenti imprevisti delle applicazioni o interruzioni del servizio.
### Interazione con il firewall DNS di Amazon Route 53
Le politiche di amministrazione e di rete di EKS vengono valutate prima a livello di pod quando viene avviato il traffico. Se una policy di rete EKS consente l'uscita verso un dominio specifico, il pod esegue quindi una query DNS che raggiunge il Route 53 Resolver. A questo punto, vengono valutate le regole del firewall DNS Route 53. Se DNS Firewall blocca la query del dominio, la risoluzione DNS fallisce e la connessione non può essere stabilita, anche se la politica di rete EKS lo ha consentito. Ciò crea livelli di sicurezza complementari: le policy di rete basate su EKS DNS forniscono il controllo dell'uscita a livello di pod per i requisiti di accesso specifici delle applicazioni e i limiti di sicurezza multi-tenant, mentre DNS Firewall offre una protezione a livello di VPC contro domini dannosi noti e applica le blocklist a livello di organizzazione.
# Assegnazione di tag alle sottoreti per la modalità automatica EKS
Se utilizzi la funzionalità di bilanciamento del carico di EKS Auto Mode, devi aggiungere AWS tag alle sottoreti VPC.
## Contesto
Questi tag identificano le sottoreti associate al cluster e, soprattutto, se la sottorete è pubblica o privata.
Le sottoreti pubbliche dispongono di un accesso diretto a Internet tramite un gateway Internet. Sono utilizzate per risorse che devono essere accessibili al pubblico, come i bilanciatori del carico.
Le sottoreti private non dispongono di un accesso diretto a Internet e utilizzano gateway NAT per il traffico in uscita. Vengono utilizzati per risorse interne come i nodi EKS che non necessitano di risorse pubbliche. IPs
Per ulteriori informazioni sui gateway NAT e sui gateway Internet, consulta [Connetti il tuo VPC ad altre reti](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) nella Guida per l’utente del cloud privato virtuale (VPC) di Amazon.
## Requisito
Al momento, le sottoreti utilizzate per il bilanciamento del carico tramite la modalità automatica EKS devono avere uno dei seguenti tag.
### Sottoreti pubbliche
Le sottoreti pubbliche sono utilizzate per i bilanciatori del carico connesso a Internet. Queste sottoreti devono avere i tag seguenti:
| Chiave | Valore |
| --- | --- |
| `kubernetes.io/role/elb` | `1` o `` |
### Sottoreti private
Le sottoreti private sono utilizzate per i bilanciatori del carico interni. Queste sottoreti devono avere i tag seguenti:
| Chiave | Valore |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` o `` |
## Procedura
Prima di iniziare, identifica quali sottoreti sono pubbliche (con accesso a gateway Internet) e quali sono private (tramite gateway NAT). Avrai bisogno delle autorizzazioni per modificare le risorse VPC.
### Console di gestione AWS
1. **Apri la console Amazon VPC e accedi alle sottoreti.**
1. Seleziona la sottorete da etichettare.
1. Scegli la scheda **Tag** e seleziona **Aggiungi tag**.
1. Aggiungi il tag appropriato:
+ Per le sottoreti pubbliche: Chiave=`kubernetes.io/role/elb`
+ Per sottoreti private: Chiave=`kubernetes.io/role/internal-elb`
1. Imposta **Valore** su `1` o lascia vuoto.
1. Salva e ripeti per le sottoreti rimanenti.
### AWS CLI
Per le sottoreti pubbliche:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Per le sottoreti private:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Sostituisci `subnet-ID` con l’ID della sottorete corrente.
# Generare report di conformità CIS dai nodi Kubernetes utilizzando kubectl debug
Questo argomento descrive come generare report di conformità CIS (Center for Internet Security) per i nodi Amazon EKS utilizzando il comando `kubectl debug`. Il comando ti consente di creare temporaneamente un container di debug su un nodo di Kubernetes ed eseguire controlli di conformità CIS utilizzando lo strumento `apiclient`. Lo strumento `apiclient` fa parte di Bottlerocket OS, il sistema operativo utilizzato dai nodi della modalità automatica di EKS.
## Prerequisiti
Prima di iniziare, assicurati di disporre di:
+ Accesso a un cluster Amazon EKS con `kubectl` configurato (la versione deve essere almeno v1.32.0; digitare `kubectl version` per verificare).
+ Le autorizzazioni IAM appropriate per il debug dei nodi.
+ Un profilo valido che consente operazioni di debug (ad esempio, `sysadmin`).
Per ulteriori informazioni sull’utilizzo dei profili di debug con `kubectl`, consultare [Debugging a Pod or Node while applying a profile](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) nella documentazione di Kubernetes.
## Procedura
1. Determina l'ID AWS istanza del nodo su cui vuoi eseguire il rapporto. Utilizzare il seguente comando per elencare tutti i nodi nel cluster. L’ID dell’istanza si trova nella colonna del nome e inizia con `i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Esegui il comando seguente, sostituendo `` con l’ID di istanza del nodo su cui si desidera eseguire la query:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
I componenti di questo comando includono:
+ `kubectl debug node/`: crea una sessione di debug sull’ID di istanza EC2 specificato.
+ `-it`: assegna un TTY (shell a riga di comando) e mantiene aperto stdin per un utilizzo interattivo.
+ `--profile=sysadmin`: utilizza il profilo `kubectl` specificato con le autorizzazioni appropriate.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`: utilizza `amazonlinux:2023` come immagine del container per il debug.
+ `bash -c "…"`: esegue i seguenti comandi in una shell bash:
+ `yum install -q -y util-linux-core`: installa in background il pacchetto di utilità richiesto.
+ `nsenter -t 1 -m`: esegue `nsenter` per inserire il namespace del processo host (PID 1).
+ `apiclient report cis --level 1 --format text`: esegue il report di conformità CIS a livello 1 con output di testo.
1. Esaminare l’output del testo del report.
## Interpretazione dell’output
Il comando genera un report basato su testo che mostra lo stato di conformità di vari controlli CIS. L’output include:
+ Controllo CIS individuale IDs
+ Descrizione di ciascun controllo
+ Lo stato Pass, Fail o Skip per ogni controllo
+ Dettagli che spiegano eventuali problemi di conformità
Ecco un esempio di output del report eseguito su un’istanza Bottlerocket:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Per informazioni sul benchmark, consultare [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) dal Center for Internet Security (CIS).
## Risorse correlate
+ [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) nella documentazione del sistema operativo Bottlerocket.
+ [Debug Running Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) nella documentazione di Kubernetes.
+ [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) dal Center for Internet Security (CIS)
# Abilitare la crittografia dei volumi EBS con chiavi KMS gestite dal cliente per la modalità automatica di EKS
Puoi crittografare il volume root temporaneo per le istanze della modalità automatica di EKS con una chiave KMS gestita dal cliente.
La modalità automatica di Amazon EKS utilizza ruoli collegati ai servizi per delegare le autorizzazioni ad altri AWS servizi durante la gestione di volumi EBS crittografati per i cluster Kubernetes. In questo argomento viene descritto come impostare le policy della chiave necessarie quando si specifica una chiave gestita dal cliente per la crittografia Amazon EBS con la modalità automatica di EKS.
Considerazioni:
+ EKS Auto Mode non richiede un'autorizzazione aggiuntiva per utilizzare la chiave AWS gestita predefinita per proteggere i volumi crittografati nel tuo account.
+ Questo argomento tratta la crittografia dei volumi effimeri, i volumi root per le istanze. EC2 Per ulteriori informazioni sulla crittografia dei volumi di dati utilizzati per i carichi di lavoro, consulta [Crea una classe di archiviazione](create-storage-class.md).
## Panoramica di
Le seguenti chiavi AWS KMS possono essere utilizzate per la crittografia dei volumi root di Amazon EBS quando EKS Auto Mode avvia le istanze:
+ **Chiave gestita da AWS **: una chiave di crittografia nell’account che Amazon EBS crea, possiede e gestisce. Questa è la chiave di crittografia di default per un nuovo account.
+ **Chiave gestita dal cliente**: una chiave di crittografia personalizzata che l’utente crea, possiede e gestisce.
**Nota**
La chiave deve essere simmetrica. Amazon EBS non supporta le chiavi gestite dal cliente asimmetriche.
## Fase 1: Configurare la policy della chiave
Le chiavi KMS devono avere una policy della chiave che permetta alla modalità automatica di EKS di avviare istanze con volumi Amazon EBS crittografati con una chiave gestita dal cliente.
Configura la policy della chiave con la seguente struttura:
**Nota**
Questa policy include solo le autorizzazioni per la modalità automatica di EKS. La policy della chiave potrebbe richiedere autorizzazioni aggiuntive se altre identità devono utilizzare la chiave o gestire le concessioni.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Assicurati di sostituirlo `` con l'ID dell'account effettivo. AWS
Durante la configurazione della policy della chiave:
+ Per eseguire le operazioni di crittografia, il `ClusterServiceRole` deve disporre delle autorizzazioni IAM necessarie per usare la chiave KMS.
+ La `kms:GrantIsForAWSResource` condizione garantisce che le sovvenzioni possano essere create solo per i servizi AWS
## Fase 2: Configura NodeClass con la chiave gestita dal cliente
Dopo aver configurato la politica chiave, fai riferimento alla chiave KMS nella configurazione della modalità NodeClass automatica EKS:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
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
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Sostituisci i valori di segnaposto con i valori effettivi:
+ ``con la tua regione AWS
+ ``con l'ID AWS del tuo account
+ `` con ID della chiave KMS
Puoi specificare la chiave KMS utilizzando uno dei seguenti formati:
+ ID della chiave KMS: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN della chiave KMS: ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nome alias della chiave: `alias/eks-auto-mode-key`
+ ARN alias della chiave: ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Applica la NodeClass configurazione usando kubectl:
```
kubectl apply -f nodeclass.yaml
```
## Risorse correlate
+ [Creazione di una classe di nodi per Amazon EKS](create-node-class.md)
+ Visualizza ulteriori informazioni nella AWS Key Management Service Developer Guide
+ [Autorizzazioni per AWS i servizi nelle politiche chiave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Modificare una policy della chiave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Sovvenzioni in KMS AWS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Aggiorna i controlli organizzativi per la modalità automatica di EKS
Alcuni controlli organizzativi possono impedire il corretto funzionamento della modalità automatica di EKS. In tal caso, devi aggiornare questi controlli per consentire alla modalità automatica di EKS di disporre delle autorizzazioni necessarie per gestire le istanze EC2 per conto dell’utente.
modalità automatica di EKS utilizza un ruolo di servizio per l’avvio delle istanze EC2 che supportano i nodi della modalità automatica di EKS. Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) creato nell’account che un servizio assume per eseguire operazioni nell’account. [Le policy di controllo del servizio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) si applicano sempre alle azioni eseguite con i ruoli di servizio. Ciò consente a una SCP di inibire le operazioni di Auto Mode. L'evento più comune si verifica quando viene utilizzato un SCP per limitare le Amazon Machine Images (AMIs) che possono essere lanciate. Per consentire il funzionamento di EKS Auto Mode, modifica l'SCP per consentire l'avvio AMIs dagli account EKS Auto Mode.
Puoi anche utilizzare la AMIs funzione [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) per limitare la visibilità di altri account AMIs . Se utilizzi questa funzionalità, devi espandere i criteri dell’immagine per includere anche gli account AMI della modalità automatica di EKS nelle regioni di interesse.
## Esempio: SCP per bloccare tutti AMIs tranne EKS Auto Mode AMIs
La SCP riportata di seguito impedisce di chiamare `ec2:RunInstances` a meno che l’AMI non appartenga all’account AMI della modalità automatica di EKS per us-west-2 o us-east-1.
**Nota**
È importante **non** usare la chiave di contesto `ec2:Owner`. Amazon possiede gli account AMI della modalità automatica di EKS e il valore di questa chiave sarà sempre `amazon`. La creazione di un SCP che consenta l'avvio AMIs se `ec2:Owner` è `amazon` consentirà il lancio di qualsiasi AMI di proprietà di Amazon, non solo quelle per EKS Auto Mode. \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Account AMI della modalità automatica di EKS
AWS gli account che variano in base alla regione ospitano EKS Auto Mode public AMIs.
| | |
| --- |--- |
| AWS Regione | Account |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Associare un indirizzo IP pubblico
Quando viene chiamato `ec2:RunInstances`, il campo `AssociatePublicIpAddress` per l’avvio di un’istanza viene determinato automaticamente dal tipo di sottorete in cui viene avviata l’istanza. È possibile utilizzare un SCP per far sì che questo valore sia impostato esplicitamente su false, indipendentemente dal tipo di sottorete in cui viene avviato. In questo caso il NodeClass campo `spec.advancedNetworking.associatePublicIPAddress` può anche essere impostato su false per soddisfare i requisiti dell'SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS
Puoi controllare l’implementazione dei carichi di lavoro su [Prenotazioni della capacità](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). La modalità automatica di EKS supporta le prenotazioni della capacità on demand EC2 (ODCR) e i blocchi di capacità EC2 per il machine learning.
**Suggerimento**
Per impostazione predefinita, EKS Auto Mode può essere avviato in open ODCRs tramite open-matching, ma non dà loro la priorità. Le istanze avviate tramite open-matching sono etichettate, non. `karpenter.sh/capacity-type: on-demand` `reserved` Per dare priorità all'utilizzo dell'ODCR e etichettare le istanze, configura nella definizione. `karpenter.sh/capacity-type: reserved` `capacityReservationSelectorTerms` NodeClass I Capacity Blocks for ML richiedono sempre `capacityReservationSelectorTerms` e non vengono utilizzati automaticamente.
## Prenotazioni di capacità su richiesta EC2 () ODCRs
Le prenotazioni della capacità on demand di EC2 (ODCR) permettono di prenotare la capacità di elaborazione per le istanze Amazon EC2 in una zona di disponibilità specifica per qualsiasi durata. Quando si utilizza modalità automatica di EKS, potresti voler controllare se i carichi di lavoro di Kubernetes vengono implementati su queste istanze riservate per massimizzare l’utilizzo della capacità pre-acquistata o per garantire che i carichi di lavoro critici abbiano accesso a risorse garantite.
Per impostazione predefinita, EKS Auto Mode si apre automaticamente. ODCRs Tuttavia, configurando `capacityReservationSelectorTerms` su a NodeClass, puoi controllare in modo esplicito l'utilizzo dei ODCRs tuoi carichi di lavoro. I nodi forniti utilizzando configure ODCRs avranno e avranno priorità rispetto a on-demand `karpenter.sh/capacity-type: reserved` e spot. Una volta abilitata questa funzionalità, EKS Auto Mode non utilizzerà più automaticamente open ODCRs: devono essere selezionati esplicitamente da un NodeClass, in modo da consentire un controllo preciso sull'utilizzo della prenotazione della capacità in tutto il cluster.
**avvertimento**
Se si esegue la configurazione `capacityReservationSelectorTerms` all' NodeClass interno di un cluster, EKS Auto Mode non utilizzerà più automaticamente open ODCRs per *nessuno* NodeClass dei componenti del cluster.
### Esempio NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Questo esempio NodeClass illustra due approcci per la selezione ODCRs. Il primo metodo fa riferimento direttamente a una ODCR specifica tramite il relativo ID (`cr-56fac701cc1951b03`). Il secondo metodo utilizza la selezione basata su tag, mirando ODCRs con il tag. `Name: "targeted-odcr"` Facoltativamente, puoi anche filtrare in base all' AWS account proprietario della prenotazione, il che è particolarmente utile negli scenari tra più account o quando lavori con prenotazioni di capacità condivise.
## Blocchi di capacità EC2 per ML
I blocchi di capacità per ML prenotano istanze a calcolo accelerato basate su GPU in una data futura per supportare carichi di lavoro di machine learning (ML) di breve durata. Le istanze eseguite all'interno di un Capacity Block vengono automaticamente posizionate vicine tra loro all'interno di Amazon UltraClusters EC2, per reti a bassa latenza, su scala petabit e non bloccanti.
Per ulteriori informazioni sulle piattaforme e sui tipi di istanze supportati, consulta [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella Guida per l’utente di EC2.
Puoi creare una modalità automatica EKS NodeClass che utilizza un Capacity Block per ML, simile a un ODCR (descritto in precedenza).
Le seguenti definizioni di esempio creano tre risorse:
1. A NodeClass che fa riferimento alla tua prenotazione Capacity Block
1. A NodePool che utilizza NodeClass e applica una macchia
1. Una specifica per Pod che tollera il taint e richiede risorse GPU
### Esempio NodeClass
Questo NodeClass fa riferimento a uno specifico Capacity Block for ML tramite il relativo ID di prenotazione. Puoi ottenere questo ID dalla console EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
### Esempio NodePool
Questo NodePool fa riferimento `gpu` NodeClass e specifica una configurazione importante:
+ Utilizza **solo** la capacità riservata impostando `karpenter.sh/capacity-type: reserved`
+ Richiede famiglie di istanze GPU specifiche adatte ai carichi di lavoro ML
+ Applica un taint `nvidia.com/gpu` per garantire che solo i carichi di lavoro GPU siano pianificati su questi nodi
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
### Pod di esempio
Questo pod di esempio dimostra come configurare un carico di lavoro da eseguire sui nodi del blocco di capacità:
+ Utilizza un **NodeSelector** per indirizzare tipi di GPU specifici (in questo caso, H200) GPUs
+ Include una **tolleranza** per la macchia applicata dal `nvidia.com/gpu` NodePool
+ **Richiede esplicitamente le risorse GPU** che utilizzano il tipo di risorsa `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Per ulteriori informazioni, consulta [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) nella documentazione Kubernetes.
### Risorse correlate
+ [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella Guida per l’utente di Amazon EC2
+ [Find and purchase Capacity Blocks](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) nella Guida per l’utente di Amazon EC2
+ [Gestisci le risorse di calcolo per i AI/ML carichi di lavoro su Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [GPU Resource Optimization and Cost Management](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) nella Guida alle best practice di EKS
# Implementazione dei nodi EKS Auto Mode su Local Zones
EKS Auto Mode offre una gestione semplificata dei cluster con il provisioning automatico dei nodi. AWS Local Zones estendono l' AWS infrastruttura alle aree geografiche più vicine agli utenti finali, riducendo la latenza per le applicazioni sensibili alla latenza. Questa guida illustra il processo di implementazione dei nodi EKS Auto Mode su AWS Local Zones, consentendoti di eseguire applicazioni containerizzate con latenza inferiore per gli utenti in aree geografiche specifiche.
Questa guida dimostra anche come utilizzare i limiti e le tolleranze di Kubernetes per garantire che sui nodi della zona locale vengano eseguiti solo carichi di lavoro specifici, aiutandoti a controllare i costi e ottimizzare l'utilizzo delle risorse.
## Prerequisiti
Prima di iniziare a distribuire i nodi EKS Auto Mode su Local Zones, assicurati di avere i seguenti prerequisiti:
+ [Un cluster EKS Auto Mode esistente](create-auto.md)
+ [Hai effettuato l'accesso alla zona locale del tuo account AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Fase 1: Creare una sottorete di zona locale
Il primo passo per implementare i nodi EKS Auto Mode in una zona locale consiste nella creazione di una sottorete in quella zona locale. Questa sottorete fornisce l'infrastruttura di rete per i nodi e consente loro di comunicare con il resto del VPC. Segui le istruzioni [Create a Local Zone subnet](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (nella AWS Local Zones User Guide) per creare una sottorete nella Local Zone prescelta.
**Suggerimento**
Prendi nota del nome della sottorete della zona locale.
## Fase 2: Creazione NodeClass per la sottorete della zona locale
Dopo aver creato la sottorete Local Zone, è necessario definire una sottorete NodeClass che faccia riferimento a questa sottorete. NodeClass Si tratta di una risorsa personalizzata Kubernetes che specifica gli attributi di infrastruttura per i nodi, incluse le sottoreti, i gruppi di sicurezza e le configurazioni di archiviazione da utilizzare. Nell'esempio seguente, creiamo una NodeClass chiamata «zona locale» che ha come target una sottorete di zona locale in base al suo nome. È inoltre possibile utilizzare l'ID della sottorete. Dovrai adattare questa configurazione per indirizzare la tua sottorete Local Zone.
Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Fase 3: Crea NodePool con NodeClass e Taint
Una volta NodeClass configurato, ora devi crearne uno NodePool che lo NodeClass utilizzi. A NodePool definisce le caratteristiche di calcolo dei nodi, inclusi i tipi di istanza. NodePool utilizza il NodeClass come riferimento per determinare dove avviare le istanze.
Nell'esempio seguente, creiamo un NodePool riferimento alla nostra «zona locale». NodeClass Aggiungiamo anche una macchia ai nodi per garantire che solo i pod con una tolleranza corrispondente possano essere programmati su questi nodi della Zona Locale. Ciò è particolarmente importante per i nodi della zona locale, che in genere hanno costi più elevati e devono essere utilizzati solo da carichi di lavoro che beneficiano specificamente della latenza ridotta.
Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
La contaminazione tra key `aws.amazon.com/local-zone` ed effect `NoSchedule` assicura che i pod senza una tolleranza corrispondente non vengano programmati su questi nodi. Ciò impedisce l'esecuzione accidentale di carichi di lavoro regolari nella zona locale, il che potrebbe comportare costi imprevisti.
## Fase 4: Implementazione dei carichi di lavoro con tolleranza e affinità tra nodi
Per un controllo ottimale sul posizionamento dei carichi di lavoro sui nodi della zona locale, utilizzate entrambi taints/tolerations e l'affinità dei nodi insieme. Questo approccio combinato offre i seguenti vantaggi:
1. **Controllo dei costi**: The taint garantisce che solo i pod con tolleranze esplicite possano utilizzare risorse potenzialmente costose della Zona Locale.
1. **Posizionamento garantito**: l'affinità dei nodi garantisce che le applicazioni sensibili alla latenza vengano eseguite esclusivamente nella zona locale, non sui normali nodi del cluster.
Ecco un esempio di distribuzione configurata per l'esecuzione specifica sui nodi della zona locale:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Questa distribuzione ha due configurazioni di pianificazione chiave:
1. La **tolleranza** consente di programmare i pod sui nodi con la contaminazione. `aws.amazon.com/local-zone`
1. Il requisito di **affinità dei nodi** garantisce che questi pod funzionino solo sui nodi con l'etichetta. `node-type: local-zone`
Insieme, garantiscono che l'applicazione sensibile alla latenza venga eseguita solo sui nodi della zona locale e che le applicazioni normali non consumino le risorse della zona locale a meno che non siano configurate esplicitamente per farlo.
## Passaggio 5: verifica con la console AWS
Dopo aver configurato le NodeClass distribuzioni e le distribuzioni, è necessario verificare che i nodi vengano forniti nella zona locale come previsto e che i carichi di lavoro vengano eseguiti su di essi. NodePool È possibile utilizzare la console di AWS gestione per verificare che le EC2 istanze vengano avviate nella sottorete della zona locale corretta.
Inoltre, puoi controllare l'elenco dei nodi Kubernetes utilizzando `kubectl get nodes -o wide` per confermare che i nodi si uniscano al cluster con le etichette e le sfumature corrette:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Puoi anche verificare che i pod del carico di lavoro siano pianificati sui nodi della zona locale:
```
kubectl get pods -o wide
```
Questo approccio garantisce che su questi nodi vengano pianificati solo i carichi di lavoro che tollerano specificamente la contaminazione della zona locale, aiutandoti a controllare i costi e a utilizzare nel modo più efficiente le risorse della zona locale.
# Configurare le impostazioni di sicurezza avanzate per i nodi
Questo argomento descrive come configurare le impostazioni di sicurezza avanzate per i nodi Amazon EKS Auto Mode utilizzando le `advancedSecurity` specifiche nella tua classe di nodi.
## Prerequisiti
Prima di iniziare, assicurati di disporre dei seguenti elementi:
+ Un cluster della modalità automatica di Amazon EKS. Per ulteriori informazioni, consulta [Creare un cluster con la modalità automatica Amazon EKS](create-auto.md).
+ `kubectl` installato e configurato. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
+ Comprensione della configurazione della classe di nodi. Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
## Configura le impostazioni di sicurezza avanzate
Per configurare le impostazioni di sicurezza avanzate per i tuoi nodi, imposta i `advancedSecurity` campi nella specifica della tua classe di nodi:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Applica questa configurazione:
```
kubectl apply -f nodeclass.yaml
```
Fai riferimento a questa classe di nodi nella configurazione del tuo pool di nodi. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
## Descrizioni dei campi
+ `fips`(booleano, opzionale): se impostato su`true`, effettua il provisioning dei nodi utilizzando moduli crittografici AMIs convalidati FIPS 140-2. Questa impostazione seleziona la conformità a FIPS; i clienti sono responsabili della gestione dei propri requisiti di conformità AMIs. [Per ulteriori informazioni, consulta Conformità FIPS.AWS](https://aws.amazon.com/compliance/fips/) Default: `false`.
+ `kernelLockdown`(stringa, opzionale): Controlla la modalità del modulo di sicurezza Kernel Lockdown. Valori accettati:
+ `integrity`: blocca i metodi per sovrascrivere la memoria del kernel o modificare il codice del kernel. Impedisce il caricamento dei moduli del kernel non firmati.
+ `none`: disattiva la protezione dal blocco del kernel.
Per ulteriori informazioni, consultate la documentazione relativa al blocco del [kernel Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Considerazioni
+ Gli standard FIPS AMIs sono disponibili nelle regioni Stati Uniti orientali/occidentali, ( AWS Stati Uniti) e Canada ( AWS GovCloud Centro/Ovest). AWS Per ulteriori informazioni[,AWS consulta](https://aws.amazon.com/compliance/fips/) Conformità FIPS.
+ Durante l'utilizzo`kernelLockdown: "integrity"`, assicurati che i tuoi carichi di lavoro non richiedano il caricamento di moduli del kernel non firmati o la modifica della memoria del kernel.
## Risorse correlate
+ [Creazione di una classe di nodi per Amazon EKS](create-node-class.md)- Guida completa alla configurazione della classe di nodi
+ [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md)- Configurazione del pool di nodi