Merge pull request #32908 from Sea-n/fix-it

[it] Fix Markdown format

Author: k8s-ci-robot

content/it/docs/concepts/architecture/nodes.md

@@ -41,13 +41,13 @@ L'utilizzo di questi campi varia a seconda del provider cloud o della configuraz
 
 ### Condition
 
-l campo `conditions` descrive lo stato di tutti i nodi` Running`.
+l campo `conditions` descrive lo stato di tutti i nodi `Running`.
 
 
 | Condizione del nodo | Descrizione |
 | ---------------- | ------------- |
 | `OutOfDisk` | `True` se lo spazio disponibile sul nodo non è sufficiente per aggiungere nuovi pod, altrimenti` False` |
-| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod,` False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
+| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod, `False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
 | `MemoryPressure` | `Vero` se la pressione esiste sulla memoria del nodo, ovvero se la memoria del nodo è bassa; altrimenti `False` |
     | `PIDPressure` | `True` se la pressione esiste sui processi, ovvero se ci sono troppi processi sul nodo; altrimenti `False` |
 | `DiskPressure` | `True` se esiste una pressione sulla dimensione del disco, ovvero se la capacità del disco è bassa; altrimenti `False` |
@@ -64,12 +64,12 @@ La condizione del nodo è rappresentata come un oggetto JSON. Ad esempio, la seg
 ]
 ```
 
-Se lo stato della condizione Ready rimane `Unknown` o` False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
+Se lo stato della condizione Ready rimane `Unknown` o `False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
 
 Nelle versioni di Kubernetes precedenti alla 1.5, il controllore del nodo [forzerebbe la cancellazione](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
 questi pod non raggiungibili dall'apiserver. Tuttavia, in 1.5 e versioni successive, il controller del nodo non impone l'eliminazione dei pod finché non lo è
 confermato che hanno smesso di funzionare nel cluster. Puoi vedere i pod che potrebbero essere in esecuzione su un nodo irraggiungibile
-lo stato `Terminating` o` Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
+lo stato `Terminating` o `Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
 lasciato permanentemente un cluster, potrebbe essere necessario che l'amministratore del cluster elimini manualmente l'oggetto nodo. Cancellare l'oggetto nodo da
 Kubernetes fa sì che tutti gli oggetti Pod in esecuzione sul nodo vengano eliminati dal server apis e libera i loro nomi.
 
@@ -227,7 +227,7 @@ Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni:
   - `--kubeconfig` - Percorso delle credenziali per autenticarsi sull'apiserver.
   - `--cloud-provider` - Come parlare con un provider cloud per leggere i metadati su se stesso.
   - `--register-node` - Si registra automaticamente con il server API.
-  - `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola` <chiave> = <valore>: <effetto> `). No-op se `register-node` è falso.
+  - `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola `<chiave> = <valore>: <effetto>`). No-op se `register-node` è falso.
   - `--node-ip` - Indirizzo IP del nodo.
   - `--node-labels` - Etichette da aggiungere quando si registra il nodo nel cluster (vedere le restrizioni dell'etichetta applicate dal [plugin di accesso NodeRestriction](/docs/reference/access-authn-authz/admission-controller/#noderestriction) in 1.13+).
   - `--node-status-update-frequency` - Specifica la frequenza con cui kubelet invia lo stato del nodo al master

content/it/docs/concepts/cluster-administration/certificates.md

@@ -9,7 +9,7 @@ weight: 20
 <!-- overview -->
 
 Quando si utilizza l'autenticazione del certificato client, è possibile generare certificati
-manualmente tramite `easyrsa`,` openssl` o `cfssl`.
+manualmente tramite `easyrsa`, `openssl` o `cfssl`.
 
 
 

content/it/docs/concepts/cluster-administration/cloud-providers.md

@@ -47,7 +47,7 @@ controllerManager:
     mountPath: "/etc/kubernetes/cloud.conf"
 ```
 
-I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di
+I provider cloud in-tree in genere richiedono sia `--cloud-provider` e `--cloud-config` specificati nelle righe di
 comando per [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
 e il [Kubelet](/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider
 è documentato di seguito.
@@ -91,8 +91,8 @@ spec:
 * `service.beta.kubernetes.io / aws-load-balancer-access-log-enabled`: utilizzato sul servizio per abilitare o disabilitare i log di accesso.
 * `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-name`: usato per specificare il nome del bucket di log degli accessi s3.
 * `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-prefix`: utilizzato per specificare il prefisso del bucket del registro di accesso s3.
-* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: "Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2" `.
-* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o` https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o` tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e` aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
+* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: `"Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2"`.
+* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o `https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o `tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e `aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
 * `service.beta.kubernetes.io / aws-load-balancer-ssl-cert`: utilizzato nel servizio per richiedere un listener sicuro. Il valore è un certificato ARN valido. Per ulteriori informazioni, vedere [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN è un ARN certificato IAM o CM, ad es. `ARN: AWS: ACM: US-est-1: 123456789012: certificato / 12345678-1234-1234-1234-123456789012`.
 * `service.beta.kubernetes.io / aws-load-balancer-connection-draining-enabled`: utilizzato sul servizio per abilitare o disabilitare il drenaggio della connessione.
 * `service.beta.kubernetes.io / aws-load-balancer-connection-draining-timeout`: utilizzato sul servizio per specificare un timeout di drenaggio della connessione.
@@ -125,7 +125,7 @@ corrispondere al nome VM di CloudStack.
 Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
 con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il primo segmento del nome del nodo
 Kubernetes deve corrispondere al nome dell'istanza GCE (ad esempio, un nodo denominato `kubernetes-node-2.c.my-proj.internal`
-deve corrispondere a un'istanza denominata` kubernetes-node-2`) .
+deve corrispondere a un'istanza denominata `kubernetes-node-2`) .
 
 ## OpenStack
 Questa sezione descrive tutte le possibili configurazioni che possono
@@ -243,7 +243,7 @@ file:
   il bilanciamento del carico.
 * `lb-method` (Opzionale): utilizzato per specificare l'algoritmo in base al quale verrà caricato il carico
   distribuito tra i membri del pool di bilanciamento del carico. Il valore può essere
-  `ROUND_ROBIN`,` LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
+  `ROUND_ROBIN`, `LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
   nessuno è specificato è `ROUND_ROBIN`.
 * `lb-provider` (Opzionale): utilizzato per specificare il provider del servizio di bilanciamento del carico.
   Se non specificato, sarà il servizio provider predefinito configurato in neutron
@@ -272,7 +272,7 @@ Queste opzioni di configurazione per il provider OpenStack riguardano lo storage
 e dovrebbe apparire nella sezione `[BlockStorage]` del file `cloud.conf`:
 
 * `bs-version` (Opzionale): usato per sovrascrivere il rilevamento automatico delle versioni. Valido
-  i valori sono `v1`,` v2`, `v3` e` auto`. Quando `auto` è specificato automatico
+  i valori sono `v1`, `v2`, `v3` e `auto`. Quando `auto` è specificato automatico
   il rilevamento selezionerà la versione supportata più alta esposta dal sottostante
   Cloud OpenStack. Il valore predefinito se nessuno è fornito è `auto`.
 * `trust-device-path` (Opzionale): Nella maggior parte degli scenari i nomi dei dispositivi a blocchi

content/it/docs/concepts/cluster-administration/federation.md

@@ -162,9 +162,9 @@ In secondo luogo, decidi quanti cluster dovrebbero essere disponibili allo stess
 il numero che può essere non disponibile `U`. Se non sei sicuro, allora 1 è una buona scelta.
 
 Se è possibile bilanciare il carico per indirizzare il traffico verso qualsiasi regione in caso di guasto di un cluster, allora
-avete bisogno almeno dei grossi `R` o` U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
+avete bisogno almeno dei grossi `R` o `U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
 utenti in caso di guasto di un cluster), quindi è necessario disporre di cluster `R * (U + 1)`
-(`U + 1` in ciascuna delle regioni` R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
+(`U + 1` in ciascuna delle regioni `R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
 
 Infine, se uno qualsiasi dei tuoi cluster richiederebbe più del numero massimo consigliato di nodi per un cluster Kubernetes, allora
 potresti aver bisogno di più cluster. Kubernetes v1.3 supporta cluster di dimensioni fino a 1000 nodi. Supporta Kubernetes v1.8

content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -23,12 +23,12 @@ Kubernetes gestisce il ciclo di vita di tutte le immagini tramite imageManager,
 di consulente.
 
 La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
-`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
+`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
 attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
 soglia è stata soddisfatta.
 
 La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
-`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
+`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
 attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
 soglia è stata soddisfatta.
 
@@ -44,8 +44,8 @@ Kubelet agirà su contenitori non identificati, cancellati o al di fuori dei lim
 precedentemente menzionate. I contenitori più vecchi saranno generalmente rimossi per primi. `MaxPerPodContainer`
 e `MaxContainer` possono potenzialmente entrare in conflitto l'uno con l'altro in situazioni in cui il mantenimento del
 numero massimo di contenitori per pod (`MaxPerPodContainer`) non rientra nell'intervallo consentito di contenitori morti
-globali (` MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
-quello di eseguire il downgrade di` MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
+globali (`MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
+quello di eseguire il downgrade di `MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
 contenitori di proprietà dei pod che sono stati cancellati vengono rimossi una volta che sono più vecchi di "MinAge".
 
 I contenitori che non sono gestiti da Kubelet non sono soggetti alla garbage collection del contenitore.
@@ -83,12 +83,12 @@ Compreso:
 
 | Bandiera esistente | Nuova bandiera | Motivazione
 | ------------- | -------- | --------- |
-| `--image-gc-high-threshold` | `--eviction-hard` o` --eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
+| `--image-gc-high-threshold` | `--eviction-hard` o `--eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
 | `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | i reclami di sfratto ottengono lo stesso comportamento |
 | `--maximum-dead-containers` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
 | `--maximum-dead-containers-per-container` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
 | `--minimum-container-ttl-duration` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
-| `--low-diskspace-threshold-mb` | `--eviction-hard` o` eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
+| `--low-diskspace-threshold-mb` | `--eviction-hard` o `eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
 | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | lo sfratto generalizza la transizione della pressione del disco verso altre risorse |