Remove trailing spaces from it documents(kubernetes#16742)

Author: Yushiro FURUKAWA

content/it/community/code-of-conduct.md

@@ -8,16 +8,16 @@ css: /css/community.css
 <div class="community_main">
 <h1>Codice di condotta della comunità di Kubernetes</h1>
 
-Kubernetes segue il 
+Kubernetes segue il
 <a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">codice di condotta CNCF</a>.
-Il testo del CNC CoC è replicato di seguito a partire dal 
+Il testo del CNC CoC è replicato di seguito a partire dal
 <a href="https://github.com/cncf/foundation/blob/0ce4694e5103c0c24ca90c189da81e5408a46632/code-of-conduct.md">commit 0ce4694</a>.
 Se noti che questo non è aggiornato, ti preghiamo di far presente questo problema.
 <a href="https://github.com/kubernetes/website/issues/new">file an issue</a>.
 
-Se noti una violazione del Codice di condotta in occasione di un evento o una riunione, in Slack o in un altro meccanismo di comunicazione, 
-contatta il Comitato per  
-<a href="https://git.k8s.io/community/committee-code-of-conduct">il codice di condotta di Kubernetes/a>. 
+Se noti una violazione del Codice di condotta in occasione di un evento o una riunione, in Slack o in un altro meccanismo di comunicazione,
+contatta il Comitato per
+<a href="https://git.k8s.io/community/committee-code-of-conduct">il codice di condotta di Kubernetes/a>.
 Potete raggiungerci via email all'indirizzo <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
  Il tuo anonimato sarà protetto.
 

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

@@ -97,7 +97,7 @@ numero di pod che possono essere programmati sul nodo.
 
 Informazioni generali sul nodo, come la versione del kernel, la versione di Kubernetes
 (versione kubelet e kube-proxy), versione Docker (se utilizzata), nome del sistema operativo.
-Le informazioni sono raccolte da Kubelet dal nodo. 
+Le informazioni sono raccolte da Kubelet dal nodo.
 
 ## Management
 
@@ -211,7 +211,7 @@ NodeController è responsabile per l'aggiunta di taints corrispondenti ai proble
 nodo irraggiungibile o non pronto. Vedi [questa documentazione](/docs/concepts/configuration/taint-and-toleration/)
 per i dettagli su `NoExecute` taints e la funzione alpha.
 
-partire dalla versione 1.8, il controller del nodo può essere reso responsabile della creazione di taints che rappresentano le condizioni del nodo. 
+partire dalla versione 1.8, il controller del nodo può essere reso responsabile della creazione di taints che rappresentano le condizioni del nodo.
 Questa è una caratteristica alfa della versione 1.8.
 
 ### Self-Registration of Nodes
@@ -229,7 +229,7 @@ Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni:
   - `--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
 
-Quando [Node authorization mode](/docs/reference/access-authn-authz/node/) e 
+Quando [Node authorization mode](/docs/reference/access-authn-authz/node/) e
 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) sono abilitati,
 kubelets è autorizzato solo a creare / modificare la propria risorsa nodo.
 

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

@@ -14,7 +14,7 @@ fornitore di servizi cloud.
 
 ### kubeadm
 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) è un'opzione popolare per la creazione di cluster di kuberneti.
-kubeadm ha opzioni di configurazione per specificare le informazioni di configurazione per i provider cloud. Ad esempio 
+kubeadm ha opzioni di configurazione per specificare le informazioni di configurazione per i provider cloud. Ad esempio
 un tipico il provider cloud in-tree può essere configurato utilizzando kubeadm come mostrato di seguito:
 
 ```yaml
@@ -46,15 +46,15 @@ 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 
+e il [Kubelet](/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider
 è documentato di seguito.
 
 Per tutti i fornitori di servizi cloud esterni, seguire le istruzioni sui singoli repository.
 
 ## AWS
-Questa sezione descrive tutte le possibili configurazioni che possono essere utilizzato durante l'esecuzione di 
+Questa sezione descrive tutte le possibili configurazioni che possono essere utilizzato durante l'esecuzione di
 Kubernetes su Amazon Web Services.
 
 ### Node Name
@@ -107,23 +107,23 @@ Le informazioni per le annotazioni per AWS sono tratte dai commenti su [aws.go](
 ## Azure
 
 ### Node Name
-Il provider cloud di Azure 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 nome del nodo Kubernetes deve 
+Il provider cloud di Azure 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 nome del nodo Kubernetes deve
 corrispondere al nome VM di Azure.
 
 ## CloudStack
 
 ### Node Name
-Il provider cloud CloudStack 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 nome del nodo Kubernetes deve 
+Il provider cloud CloudStack 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 nome del nodo Kubernetes deve
 corrispondere al nome VM di CloudStack.
 
 ## GCE
 
 ### Node Name
-Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto 
+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` 
+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`) .
 
 ## OpenStack
@@ -135,7 +135,7 @@ Il provider cloud OpenStack utilizza il nome dell'istanza (come determinato dai
 Si noti che il nome dell'istanza deve essere un nome nodo Kubernetes valido affinché kubelet registri correttamente il suo oggetto Node.
 
 ### Services
-Il provider cloud OpenStack implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da la nuvola 
+Il provider cloud OpenStack implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da la nuvola
 sottostante, ove disponibile:
 
 | Servizio | Versioni API | Richiesto |
@@ -252,7 +252,7 @@ file:
   L'impostazione predefinita è `false`. Quando è specificato `true` quindi` monitor-delay`,
   `monitor-timeout`, e` monitor-max-retries` deve essere impostato.
 * `monitor-delay` (Opzionale): il tempo tra l'invio delle sonde a
-  membri del servizio di bilanciamento del carico. Assicurati di specificare un'unità di tempo valida. Le unità di tempo 
+  membri del servizio di bilanciamento del carico. Assicurati di specificare un'unità di tempo valida. Le unità di tempo
   valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h"
 * `monitor-timeout` (Opzionale): tempo massimo di attesa per un monitor
   per una risposta ping prima che scada. Il valore deve essere inferiore al ritardo
@@ -346,54 +346,54 @@ File `cloud.conf`:
 ## OVirt
 
 ### Node Name
-Il provider di cloud OVirt 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 nome del nodo Kubernetes deve 
+Il provider di cloud OVirt 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 nome del nodo Kubernetes deve
 corrispondere al FQDN del VM (riportato da OVirt in `<vm> <guest_info> <fqdn> ... </fqdn> </guest_info> </vm>`)
 
 ## Photon
 
 ### Node Name
-Il provider cloud Photon 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 nome del nodo Kubernetes deve 
-corrispondere al nome VM Photon (o se "overrideIP` è impostato su true in` --cloud-config`, il nome del nodo Kubernetes 
+Il provider cloud Photon 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 nome del nodo Kubernetes deve
+corrispondere al nome VM Photon (o se "overrideIP` è impostato su true in` --cloud-config`, il nome del nodo Kubernetes
 deve corrispondere all'indirizzo IP della macchina virtuale Photon).
 
 ## VSphere
 
 ### Node Name
-Il provider cloud VSphere utilizza il nome host rilevato del nodo (come determinato dal kubelet) come nome dell'oggetto 
+Il provider cloud VSphere utilizza il nome host rilevato del nodo (come determinato dal kubelet) come nome dell'oggetto
 Nodo Kubernetes.
 
 Il parametro `--hostname-override` viene ignorato dal fornitore di cloud VSphere.
 
 ## IBM Cloud Kubernetes Service
 
 ### Compute nodes
-Utilizzando il provider di servizi IBM Cloud Kubernetes, è possibile creare cluster con una combinazione di nodi 
-virtuali e fisici (bare metal) in una singola zona o su più zone in una regione. Per ulteriori informazioni, 
+Utilizzando il provider di servizi IBM Cloud Kubernetes, è possibile creare cluster con una combinazione di nodi
+virtuali e fisici (bare metal) in una singola zona o su più zone in una regione. Per ulteriori informazioni,
 consultare [Pianificazione dell'installazione di cluster e nodo di lavoro](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters).
 
 Il nome dell'oggetto Nodo Kubernetes è l'indirizzo IP privato dell'istanza del nodo di lavoro IBM Cloud Kubernetes Service.
 
 ### Networking
-Il fornitore di servizi IBM Cloud Kubernetes fornisce VLAN per le prestazioni di rete di qualità e l'isolamento della 
-rete per i nodi. È possibile configurare firewall personalizzati e criteri di rete Calico per aggiungere un ulteriore 
-livello di sicurezza per il cluster o per connettere il cluster al data center on-prem tramite VPN. Per ulteriori 
+Il fornitore di servizi IBM Cloud Kubernetes fornisce VLAN per le prestazioni di rete di qualità e l'isolamento della
+rete per i nodi. È possibile configurare firewall personalizzati e criteri di rete Calico per aggiungere un ulteriore
+livello di sicurezza per il cluster o per connettere il cluster al data center on-prem tramite VPN. Per ulteriori
 informazioni, vedere [Pianificazione in-cluster e rete privata](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster).
 
-Per esporre le app al pubblico o all'interno del cluster, è possibile sfruttare i servizi NodePort, LoadBalancer o 
-Ingress. È anche possibile personalizzare il bilanciamento del carico dell'applicazione Ingress con le annotazioni. 
+Per esporre le app al pubblico o all'interno del cluster, è possibile sfruttare i servizi NodePort, LoadBalancer o
+Ingress. È anche possibile personalizzare il bilanciamento del carico dell'applicazione Ingress con le annotazioni.
 Per ulteriori informazioni, vedere [Pianificazione per esporre le app con reti esterne](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).
 
 ### Storage
-Il fornitore di servizi IBM Cloud Kubernetes sfrutta i volumi persistenti nativi di Kubernetes per consentire agli 
-utenti di montare archiviazione di file, blocchi e oggetti cloud nelle loro app. È inoltre possibile utilizzare il 
-componente aggiuntivo database-as-a-service e di terze parti per la memorizzazione permanente dei dati. Per ulteriori 
+Il fornitore di servizi IBM Cloud Kubernetes sfrutta i volumi persistenti nativi di Kubernetes per consentire agli
+utenti di montare archiviazione di file, blocchi e oggetti cloud nelle loro app. È inoltre possibile utilizzare il
+componente aggiuntivo database-as-a-service e di terze parti per la memorizzazione permanente dei dati. Per ulteriori
 informazioni, vedere [Pianificazione dell'archiviazione persistente altamente disponibile](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning).
 
 ## Baidu Cloud Container Engine
 
 ### Node Name
-Il provider di cloud Baidu utilizza l'indirizzo IP privato del nodo (come determinato dal kubelet o sovrascritto 
-con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve 
+Il provider di cloud Baidu utilizza l'indirizzo IP privato del nodo (come determinato dal kubelet o sovrascritto
+con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
 corrispondere all'IP privato VM di Baidu.

content/it/docs/concepts/cluster-administration/controller-metrics.md

@@ -13,13 +13,13 @@ il responsabile del controller.
 
 ## Cosa sono le metriche del controller
 
-Le metriche del controller forniscono informazioni importanti sulle prestazioni del controller. Queste metriche 
-includono le comuni metriche di runtime del linguaggio Go, come il conteggio go_routine e le metriche specifiche del 
-controller come latenze delle richieste etcd o latenze API Cloudprovider (AWS, GCE, OpenStack) che possono essere 
+Le metriche del controller forniscono informazioni importanti sulle prestazioni del controller. Queste metriche
+includono le comuni metriche di runtime del linguaggio Go, come il conteggio go_routine e le metriche specifiche del
+controller come latenze delle richieste etcd o latenze API Cloudprovider (AWS, GCE, OpenStack) che possono essere
 utilizzate per valutare la salute di un cluster.
 
-A partire da Kubernetes 1.7, le metriche dettagliate di Cloudprovider sono disponibili per le operazioni di archiviazione 
-per GCE, AWS, Vsphere e OpenStack. Queste metriche possono essere utilizzate per monitorare lo stato delle operazioni 
+A partire da Kubernetes 1.7, le metriche dettagliate di Cloudprovider sono disponibili per le operazioni di archiviazione
+per GCE, AWS, Vsphere e OpenStack. Queste metriche possono essere utilizzate per monitorare lo stato delle operazioni
 di volume persistenti.
 
 Ad esempio, per GCE queste metriche sono chiamate:

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

@@ -6,11 +6,11 @@ weight: 70
 ---
 
 {{% capture overview %}}
-La garbage collection è una funzione utile di kubelet che pulisce le immagini inutilizzate e i contenitori inutilizzati. 
-Kubelet eseguirà la raccolta dei rifiuti per i contenitori ogni minuto e la raccolta dei dati inutili per le immagini 
+La garbage collection è una funzione utile di kubelet che pulisce le immagini inutilizzate e i contenitori inutilizzati.
+Kubelet eseguirà la raccolta dei rifiuti per i contenitori ogni minuto e la raccolta dei dati inutili per le immagini
 ogni cinque minuti.
 
-Gli strumenti di garbage collection esterni non sono raccomandati in quanto questi strumenti possono potenzialmente 
+Gli strumenti di garbage collection esterni non sono raccomandati in quanto questi strumenti possono potenzialmente
 interrompere il comportamento di kubelet rimuovendo i contenitori che si prevede esistano.
 {{% /capture %}}
 
@@ -34,18 +34,18 @@ soglia è stata soddisfatta.
 
 ## Container Collection
 
-La politica per i contenitori di garbage collection considera tre variabili definite dall'utente. `MinAge` è l'età minima 
-in cui un contenitore può essere raccolto dalla spazzatura. `MaxPerPodContainer` è il numero massimo di contenitori morti 
-ogni singolo la coppia pod (UID, nome contenitore) può avere. `MaxContainers` è il numero massimo di contenitori morti 
-totali. Queste variabili possono essere disabilitate individualmente impostando `MinAge` a zero e impostando `MaxPerPodContainer` 
+La politica per i contenitori di garbage collection considera tre variabili definite dall'utente. `MinAge` è l'età minima
+in cui un contenitore può essere raccolto dalla spazzatura. `MaxPerPodContainer` è il numero massimo di contenitori morti
+ogni singolo la coppia pod (UID, nome contenitore) può avere. `MaxContainers` è il numero massimo di contenitori morti
+totali. Queste variabili possono essere disabilitate individualmente impostando `MinAge` a zero e impostando `MaxPerPodContainer`
 e `MaxContainers` rispettivamente a meno di zero.
 
-Kubelet agirà su contenitori non identificati, cancellati o al di fuori dei limiti impostati dalle bandiere 
-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 
+Kubelet agirà su contenitori non identificati, cancellati o al di fuori dei limiti impostati dalle bandiere
+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
 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.