**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à.
# 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 la modalità automatica di EKS](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 la modalità automatica di EKS](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: EC2 Placement Group
placementGroupSelector:
name: "targeted-pg"
# Alternative use direct placement group ID
# id: "pg-02465754522cda020"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Considerazioni
+ Se vuoi verificare la quantità di storage locale di cui dispone un’istanza, puoi descrivere il nodo per visualizzare la risorsa di storage temporaneo.
+ **Crittografia dei volumi**: EKS utilizza la chiave KMS personalizzata configurata per crittografare il volume 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à (AZ) diverse, è possibile usare funzionalità di Kubernetes come i [vincoli di distribuzione della topologia dei pod](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) e il [routing basato sulla topologia](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) per distribuire rispettivamente i pod e il traffico tra le zone.
+ Se *nella stessa AZ* sono presenti più sottoreti che corrispondono al `subnetSelectorTerms`, la modalità automatica di EKS crea pod su ciascun nodo distribuito tra le sottoreti in quella AZ. La modalità automatica di EKS crea interfacce di rete secondarie su ogni nodo nelle altre sottoreti della stessa AZ. Decide in base al numero di indirizzi IP disponibili in ciascuna sottorete, per usare le sottoreti in modo più efficiente. Non è tuttavia possibile specificare quale sottorete viene usata dalla modalità automatica di EKS per ogni Pod; se hai bisogno che i Pod funzionino in sottoreti specifiche, usa [Sottoreti e gruppi di sicurezza separati per i Pods](#pod-subnet-selector).
+ **Restrizioni della strategia del gruppo** di posizionamento: ogni strategia del gruppo di posizionamento (cluster, partizione, spread) presenta limitazioni specifiche sui tipi di istanze, sulle AZ e sulla capacità. Per i dettagli, consulta [Strategie per i gruppi di collocamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-strategies.html) nella Guida per l'utente di Amazon EC2.
+ **Gruppo di spread placement: limite di 7 istanze**: un gruppo di spread placement a livello di rack consente un massimo di 7 istanze in esecuzione per zona di disponibilità per gruppo. Ciò crea i seguenti casi limite:
+ **Sostituzione Drift bloccata al massimo della capacità**: EKS Auto Mode avvia un nodo sostitutivo prima di terminare quello precedente. Quando uno spread PG ha 7 istanze in una AZ, l'avvio sostitutivo fallisce e il nodo alla deriva rimane in funzione finché non si libera uno slot.
+ **Tutte le AZ alla massima capacità**: se ogni AZ dello spread PG raggiunge il limite di 7 istanze, non è possibile pianificare sostituzioni. I nodi alla deriva o candidati al consolidamento restano attivi a tempo indeterminato.
+ **Nessun fallback al di fuori del gruppo di collocamento**: EKS Auto Mode non tenta di avviare istanze sostitutive al di fuori del gruppo di collocamento.
+ **Soluzione alternativa**: utilizzare la politica di `WhenEmpty` consolidamento (). `consolidationPolicy: WhenEmpty` I nodi vengono eliminati solo dopo che tutti i pod non daemonset si sono esauriti, liberando così uno slot PG senza bisogno di un avvio sostitutivo. Tieni presente che drift utilizza sempre replace-then-delete indipendentemente dalla politica di consolidamento, quindi drift rimane bloccato a piena capacità.
+ **Pinning AZ del gruppo di posizionamento del cluster**: una volta che la prima istanza viene avviata in un gruppo di posizionamento del cluster, il PG viene bloccato su tale AZ. Se sono NodePool consentite più AZ, i lanci paralleli durante lo scale-up iniziale possono fallire: uno ha successo e aggancia l'AZ, il resto fallisce a causa di errori di capacità. Inserite la AZ tra le vostre NodePool esigenze per evitare guasti temporanei.
+ **Gruppo di posizionamento delle partizioni**: i gruppi di posizionamento delle partizioni sono supportati senza ulteriori vincoli oltre i limiti standard di EC2.
+ **Il consolidamento può spostare i pod fuori da un gruppo di posizionamento: se un** pod non ha vincoli di pianificazione relativi al gruppo di posizionamento (come ad esempio l'attivazione), il consolidamento può spostarlo `nodeSelector` su `eks.amazonaws.com/placement-group-id` un nodo esterno al PG. Le applicazioni che richiedono l'appartenenza a un gruppo di collocamento devono esprimerlo tramite vincoli a livello di pod.
+ Gruppo di **collocamento inesistente o eliminato: se un `NodeClass` fa riferimento a un gruppo** di posizionamenti che non esiste o è stato eliminato, non viene avviata alcuna istanza. Il formato dell'ID del gruppo di collocamento viene convalidato al momento dell'ammissione, ma l'esistenza viene verificata solo al momento del lancio. Se un gruppo di posizionamenti viene eliminato mentre i nodi sono in esecuzione, i nodi esistenti vengono contrassegnati come «alla deriva» e rimangono attivi a tempo indeterminato, poiché anche gli avvii di drift replacement sono bloccati.
## Sottoreti e gruppi di sicurezza separati per i Pods
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 ENI secondari nelle sottoreti corrispondenti`podSubnetSelectorTerms`, con i gruppi di sicurezza allegati. `podSecurityGroupSelectorTerms` Per impostazione predefinita, gli indirizzi IP dei pod vengono allocati da questi ENI secondari utilizzando i prefissi /28, con riserva automatica agli IP secondari (/32) quando non è disponibile un blocco di prefisso contiguo. Se `ipv4PrefixSize` è impostato su in, vengono utilizzati solo gli IP secondari. `"32"` `advancedNetworking`
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 (comunicazione da nodo a nodo) dal traffico delle applicazioni (comunicazione). Pod-to-Pod
+ Applicare configurazioni di rete diverse alle sottoreti dei nodi rispetto alle sottoreti Pod.
+ Configurare i proxy inversi o il filtraggio di rete in modo specifico per il traffico dei nodi senza influire sul traffico dei Pod. Utilizza `advancedNetworking` e `certificateBundles` per definire il tuo proxy inverso e qualsiasi certificato autofirmato o privato per il proxy.
### Configurazione di esempio
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Considerazioni relative a sottoreti Pod e gruppi di sicurezza separati
+ **Ambito del gruppo** di sicurezza: i gruppi di sicurezza di `podSecurityGroupSelectorTerms` sono collegati agli ENI secondari e si applicano al traffico Pod all'interno del VPC. Quando SNAT è abilitato (impostazione 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.
+ **NodeClass-level granularità**: 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 fattori, 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 del pod su più zone di disponibilità. Se si utilizza 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 alloca prefissi (/28) ai nodi e mantiene solo un IP secondario come MinimalIPTarget.
### 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: Prefix-caused la frammentazione** è una delle principali preoccupazioni o un ostacolo all'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 fornire gli IP quando vengono creati più pod.
## Disabilita l'uscita IPv4 dai pod IPv6 nei cluster IPv6.
Il `enableV4Egress` `true` campo è predefinito. Per i cluster IPv6 in modalità automatica, la funzionalità può essere disabilitata in modo che la modalità automatica non crei un'interfaccia IPv4 di sola uscita per i pod IPv6. Questo è importante perché l'interfaccia di uscita IPv4 non è soggetta all'applicazione 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 cluster IPv6**: il traffico in uscita IPv4 è 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 pod di uscire inaspettatamente su 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
+ **Criteri di rete nel cluster IPv6: i cluster IPv6 consentono il traffico IPv4** per impostazione predefinita. L'impostazione `enableV4Egress: false` blocca il traffico in uscita IPv4, fornendo una maggiore sicurezza, specialmente se utilizzata con le politiche di rete.