diff --git a/content/it/community/code-of-conduct.md b/content/it/community/code-of-conduct.md index 2d0b6959ca3..7c64183ece7 100644 --- a/content/it/community/code-of-conduct.md +++ b/content/it/community/code-of-conduct.md @@ -8,16 +8,16 @@ css: /css/community.css

Codice di condotta della comunità di Kubernetes

-Kubernetes segue il +Kubernetes segue il codice di condotta CNCF. -Il testo del CNC CoC è replicato di seguito a partire dal +Il testo del CNC CoC è replicato di seguito a partire dal commit 0ce4694. Se noti che questo non è aggiornato, ti preghiamo di far presente questo problema. file an issue. -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 -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 +il codice di condotta di Kubernetes/a>. Potete raggiungerci via email all'indirizzo conduct@kubernetes.io. Il tuo anonimato sarà protetto. diff --git a/content/it/docs/concepts/architecture/nodes.md b/content/it/docs/concepts/architecture/nodes.md index c7ca78917b7..4ad016b3275 100644 --- a/content/it/docs/concepts/architecture/nodes.md +++ b/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. diff --git a/content/it/docs/concepts/cluster-administration/cloud-providers.md b/content/it/docs/concepts/cluster-administration/cloud-providers.md index ea2c49533a5..5ea917a9c59 100644 --- a/content/it/docs/concepts/cluster-administration/cloud-providers.md +++ b/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,22 +346,22 @@ 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 ` ... `) ## 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. @@ -369,31 +369,31 @@ 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. diff --git a/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md index c2654fcf454..cd160cbdcc5 100644 --- a/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -20,9 +20,9 @@ Prima di scegliere una guida, ecco alcune considerazioni: - **Se si sta progettando per l'alta disponibilità**, impara a configurare [cluster in più zone](/docs/concepts/cluster-administration/federation/). - Utilizzerai **un cluster di Kubernetes ospitato**, come [Motore di Google Kubernetes](https://cloud.google.com/kubernetes-engine/) o **che ospita il tuo cluster**? - Il tuo cluster sarà **on-premises** o **nel cloud (IaaS)**? Kubernetes non supporta direttamente i cluster ibridi. Invece, puoi impostare più cluster. - - **Se stai configurando Kubernetes on-premises**, considera quale [modello di rete](/docs/concepts/cluster-administration/networking/) si adatti meglio. + - **Se stai configurando Kubernetes on-premises**, considera quale [modello di rete](/docs/concepts/cluster-administration/networking/) si adatti meglio. - Eseguirai Kubernetes su **hardware "bare metal"** o su **macchine virtuali (VM)**? - - Vuoi **solo eseguire un cluster**, oppure ti aspetti di fare **lo sviluppo attivo del codice del progetto di Kubernetes**? + - Vuoi **solo eseguire un cluster**, oppure ti aspetti di fare **lo sviluppo attivo del codice del progetto di Kubernetes**? In quest'ultimo caso, scegli una distribuzione sviluppata attivamente. Alcune distribuzioni utilizzano solo versioni binarie, ma offrono una maggiore varietà di scelte - Familiarizzare con i [componenti](/docs/admin/cluster-components/) necessari per eseguire un cluster. diff --git a/content/it/docs/concepts/cluster-administration/controller-metrics.md b/content/it/docs/concepts/cluster-administration/controller-metrics.md index c38d0840cd0..666b6023ded 100644 --- a/content/it/docs/concepts/cluster-administration/controller-metrics.md +++ b/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: diff --git a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md index f787519141b..976e64cc95e 100644 --- a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/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. diff --git a/content/it/docs/concepts/cluster-administration/manage-deployment.md b/content/it/docs/concepts/cluster-administration/manage-deployment.md index 33f3cb7ec21..4f4d3dae502 100644 --- a/content/it/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/it/docs/concepts/cluster-administration/manage-deployment.md @@ -6,9 +6,9 @@ weight: 40 {{% capture overview %}} -Hai distribuito la tua applicazione e l'hai esposta tramite un servizio. Ora cosa? Kubernetes fornisce una serie di -strumenti per aiutarti a gestire la distribuzione delle applicazioni, compreso il ridimensionamento e l'aggiornamento. -Tra le caratteristiche che discuteremo in modo più approfondito ci sono [file di configurazione](/docs/concepts/configuration/overview/) +Hai distribuito la tua applicazione e l'hai esposta tramite un servizio. Ora cosa? Kubernetes fornisce una serie di +strumenti per aiutarti a gestire la distribuzione delle applicazioni, compreso il ridimensionamento e l'aggiornamento. +Tra le caratteristiche che discuteremo in modo più approfondito ci sono [file di configurazione](/docs/concepts/configuration/overview/) e [labels](/docs/concepts/overview/working-with-objects/labels/). {{% /capture %}} @@ -187,9 +187,9 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m ## Distribuzioni canarie -Un altro scenario in cui sono necessarie più etichette è quello di distinguere distribuzioni di diverse versioni o -configurazioni dello stesso componente. È prassi comune distribuire un * canarino * di una nuova versione -dell'applicazione (specificata tramite il tag immagine nel modello pod) parallelamente alla versione precedente in +Un altro scenario in cui sono necessarie più etichette è quello di distinguere distribuzioni di diverse versioni o +configurazioni dello stesso componente. È prassi comune distribuire un * canarino * di una nuova versione +dell'applicazione (specificata tramite il tag immagine nel modello pod) parallelamente alla versione precedente in modo che la nuova versione possa ricevere il traffico di produzione in tempo reale prima di distribuirlo completamente. Ad esempio, puoi usare un'etichetta `track` per differenziare le diverse versioni. @@ -208,7 +208,7 @@ La versione stabile e primaria avrebbe un'etichetta `track` con valore come` sta image: gb-frontend:v3 ``` -e quindi puoi creare una nuova versione del frontend del guestbook che porta l'etichetta `track` con un valore diverso +e quindi puoi creare una nuova versione del frontend del guestbook che porta l'etichetta `track` con un valore diverso (ad esempio` canary`), in modo che due gruppi di pod non si sovrappongano: ```yaml @@ -223,8 +223,8 @@ e quindi puoi creare una nuova versione del frontend del guestbook che porta l'e image: gb-frontend:v4 ``` -Il servizio di frontend coprirebbe entrambe le serie di repliche selezionando il sottoinsieme comune delle loro -etichette (ad esempio omettendo l'etichetta `track`), in modo che il traffico venga reindirizzato ad entrambe le +Il servizio di frontend coprirebbe entrambe le serie di repliche selezionando il sottoinsieme comune delle loro +etichette (ad esempio omettendo l'etichetta `track`), in modo che il traffico venga reindirizzato ad entrambe le applicazioni: ```yaml @@ -234,16 +234,16 @@ applicazioni: ``` 452/5000 -È possibile modificare il numero di repliche delle versioni stable e canary per determinare il rapporto tra ciascuna -versione che riceverà il traffico di produzione live (in questo caso, 3: 1). Una volta che sei sicuro, puoi aggiornare +È possibile modificare il numero di repliche delle versioni stable e canary per determinare il rapporto tra ciascuna +versione che riceverà il traffico di produzione live (in questo caso, 3: 1). Una volta che sei sicuro, puoi aggiornare la traccia stabile alla nuova versione dell'applicazione e rimuovere quella canarino. Per un esempio più concreto, controlla il [tutorial di distribuzione di Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary). ## Updating labels -A volte i pod esistenti e altre risorse devono essere rinominati prima di creare nuove risorse. Questo può essere fatto -con l'etichetta `kubectl`. Ad esempio, se desideri etichettare tutti i tuoi pod nginx come livello frontend, esegui +A volte i pod esistenti e altre risorse devono essere rinominati prima di creare nuove risorse. Questo può essere fatto +con l'etichetta `kubectl`. Ad esempio, se desideri etichettare tutti i tuoi pod nginx come livello frontend, esegui semplicemente: ```shell @@ -253,7 +253,7 @@ pod/my-nginx-2035384211-u2c7e labeled pod/my-nginx-2035384211-u3t6x labeled ``` -Questo prima filtra tutti i pod con l'etichetta "app = nginx", quindi li etichetta con il "tier = fe". Per vedere i pod +Questo prima filtra tutti i pod con l'etichetta "app = nginx", quindi li etichetta con il "tier = fe". Per vedere i pod appena etichettati, esegui: ```shell @@ -267,13 +267,13 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe questo produce tutti i pod "app = nginx", con un'ulteriore colonna di etichette del livello dei pod (specificata con `-L` o` --label-columns`). -Per ulteriori informazioni, consultare [labels](/docs/concepts/overview/working-with-objects/labels/) e +Per ulteriori informazioni, consultare [labels](/docs/concepts/overview/working-with-objects/labels/) e [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label). ## Aggiornare annotazioni -A volte vorresti allegare annotazioni alle risorse. Le annotazioni sono metadati arbitrari non identificativi per il -recupero da parte di client API come strumenti, librerie, ecc. Questo può essere fatto con `kubectl annotate`. Per +A volte vorresti allegare annotazioni alle risorse. Le annotazioni sono metadati arbitrari non identificativi per il +recupero da parte di client API come strumenti, librerie, ecc. Questo può essere fatto con `kubectl annotate`. Per esempio: ```shell @@ -287,12 +287,12 @@ metadata: ... ``` -Per ulteriori informazioni, consultare il documento [annotazioni](/docs/concepts/overview/working-with-objects/annotations/) +Per ulteriori informazioni, consultare il documento [annotazioni](/docs/concepts/overview/working-with-objects/annotations/) e [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate). ## Ridimensionamento dell'applicazione -Quando si carica o si riduce la richiesta, è facile ridimensionare con `kubectl`. Ad esempio, per ridurre il numero di +Quando si carica o si riduce la richiesta, è facile ridimensionare con `kubectl`. Ad esempio, per ridurre il numero di repliche nginx da 3 a 1, fare: ```shell @@ -318,7 +318,7 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled Ora le repliche di nginx verranno ridimensionate automaticamente in base alle esigenze. Per maggiori informazioni, vedi [scala kubectl](/docs/reference/generated/kubectl/kubectl-commands/#scale), -[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) e documento +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) e documento [orizzontale pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/). ## Aggiornamenti sul posto delle risorse @@ -327,13 +327,13 @@ A volte è necessario apportare aggiornamenti stretti e senza interruzioni alle ### kubectl apply -Si consiglia di mantenere un set di file di configurazione nel controllo del codice sorgente (vedere -[configurazione come codice](http://martinfowler.com/bliki/InfrastructureAsCode.html)), in modo che possano essere -mantenuti e versionati insieme al codice per le risorse che configurano. Quindi, puoi usare +Si consiglia di mantenere un set di file di configurazione nel controllo del codice sorgente (vedere +[configurazione come codice](http://martinfowler.com/bliki/InfrastructureAsCode.html)), in modo che possano essere +mantenuti e versionati insieme al codice per le risorse che configurano. Quindi, puoi usare [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) per inviare le modifiche alla configurazione nel cluster. -Questo comando confronterà la versione della configurazione che stai spingendo con la versione precedente e applicherà +Questo comando confronterà la versione della configurazione che stai spingendo con la versione precedente e applicherà le modifiche che hai apportato, senza sovrascrivere le modifiche automatiche alle proprietà che non hai specificato. ```shell @@ -341,18 +341,18 @@ $ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.ya deployment.apps/my-nginx configured ``` -Si noti che `kubectl apply` allega un'annotazione alla risorsa per determinare le modifiche alla configurazione -dall'invocazione precedente. Quando viene invocato, `kubectl apply` fa una differenza a tre tra la configurazione -precedente, l'input fornito e la configurazione corrente della risorsa, al fine di determinare come modificare la +Si noti che `kubectl apply` allega un'annotazione alla risorsa per determinare le modifiche alla configurazione +dall'invocazione precedente. Quando viene invocato, `kubectl apply` fa una differenza a tre tra la configurazione +precedente, l'input fornito e la configurazione corrente della risorsa, al fine di determinare come modificare la risorsa. -Attualmente, le risorse vengono create senza questa annotazione, quindi la prima chiamata di `kubectl apply` ricadrà su -una differenza a due vie tra l'input fornito e la configurazione corrente della risorsa. Durante questa prima chiamata, -non è in grado di rilevare l'eliminazione delle proprietà impostate al momento della creazione della risorsa. Per questo +Attualmente, le risorse vengono create senza questa annotazione, quindi la prima chiamata di `kubectl apply` ricadrà su +una differenza a due vie tra l'input fornito e la configurazione corrente della risorsa. Durante questa prima chiamata, +non è in grado di rilevare l'eliminazione delle proprietà impostate al momento della creazione della risorsa. Per questo motivo, non li rimuoverà. -Tutte le chiamate successive a `kubectl apply`, e altri comandi che modificano la configurazione, come `kubectl replace` -e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a` kubectl apply` per rilevare ed +Tutte le chiamate successive a `kubectl apply`, e altri comandi che modificano la configurazione, come `kubectl replace` +e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a` kubectl apply` per rilevare ed eseguire cancellazioni usando un tre via diff. {{< note >}} @@ -367,7 +367,7 @@ In alternativa, puoi anche aggiornare le risorse con `kubectl edit`: $ kubectl edit deployment/my-nginx ``` -Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la +Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la versione aggiornata: ```shell @@ -379,7 +379,7 @@ deployment.apps/my-nginx configured $ rm /tmp/nginx.yaml ``` -Questo ti permette di fare più cambiamenti significativi più facilmente. Nota che puoi specificare l'editor con le +Questo ti permette di fare più cambiamenti significativi più facilmente. Nota che puoi specificare l'editor con le variabili di ambiente `EDITOR` o` KUBE_EDITOR`. Per ulteriori informazioni, consultare il documento [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit). @@ -396,9 +396,9 @@ and ## Disruptive updates 375/5000 -In alcuni casi, potrebbe essere necessario aggiornare i campi di risorse che non possono essere aggiornati una volta -inizializzati, oppure si può semplicemente voler fare immediatamente una modifica ricorsiva, come per esempio correggere -i pod spezzati creati da una distribuzione. Per cambiare tali campi, usa `replace --force`, che elimina e ricrea la +In alcuni casi, potrebbe essere necessario aggiornare i campi di risorse che non possono essere aggiornati una volta +inizializzati, oppure si può semplicemente voler fare immediatamente una modifica ricorsiva, come per esempio correggere +i pod spezzati creati da una distribuzione. Per cambiare tali campi, usa `replace --force`, che elimina e ricrea la risorsa. In questo caso, puoi semplicemente modificare il tuo file di configurazione originale: ```shell @@ -409,12 +409,12 @@ deployment.apps/my-nginx replaced ## Aggiornamento dell'applicazione senza un'interruzione del servizio -A un certo punto, alla fine sarà necessario aggiornare l'applicazione distribuita, in genere specificando una nuova -immagine o un tag immagine, come nello scenario di distribuzione canarino precedente. `kubectl` supporta diverse +A un certo punto, alla fine sarà necessario aggiornare l'applicazione distribuita, in genere specificando una nuova +immagine o un tag immagine, come nello scenario di distribuzione canarino precedente. `kubectl` supporta diverse operazioni di aggiornamento, ognuna delle quali è applicabile a diversi scenari. -Ti guideremo attraverso come creare e aggiornare le applicazioni con le distribuzioni. Se l'applicazione distribuita è -gestita dai controller di replica, dovresti leggere +Ti guideremo attraverso come creare e aggiornare le applicazioni con le distribuzioni. Se l'applicazione distribuita è +gestita dai controller di replica, dovresti leggere [come usare `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/). Diciamo che stavi usando la versione 1.7.9 di nginx: @@ -424,16 +424,16 @@ $ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3 deployment.apps/my-nginx created ``` -Per aggiornare alla versione 1.9.1, cambia semplicemente `.spec.template.spec.containers [0] .image` da `nginx: 1.7.9` +Per aggiornare alla versione 1.9.1, cambia semplicemente `.spec.template.spec.containers [0] .image` da `nginx: 1.7.9` a `nginx: 1.9.1`, con i comandi kubectl che abbiamo imparato sopra. ```shell $ kubectl edit deployment/my-nginx ``` -Questo è tutto! La distribuzione aggiornerà in modo dichiarativo l'applicazione nginx distribuita progressivamente -dietro la scena. Garantisce che solo un certo numero di vecchie repliche potrebbe essere inattivo mentre vengono -aggiornate e solo un certo numero di nuove repliche può essere creato sopra il numero desiderato di pod. Per ulteriori +Questo è tutto! La distribuzione aggiornerà in modo dichiarativo l'applicazione nginx distribuita progressivamente +dietro la scena. Garantisce che solo un certo numero di vecchie repliche potrebbe essere inattivo mentre vengono +aggiornate e solo un certo numero di nuove repliche può essere creato sopra il numero desiderato di pod. Per ulteriori informazioni su di esso, visitare [Pagina di distribuzione](/docs/concepts/workloads/controller/deployment/). {{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/networking.md b/content/it/docs/concepts/cluster-administration/networking.md index 697328535f6..28885114894 100644 --- a/content/it/docs/concepts/cluster-administration/networking.md +++ b/content/it/docs/concepts/cluster-administration/networking.md @@ -5,7 +5,7 @@ weight: 50 --- {{% capture overview %}} -Il networking è una parte centrale di Kubernetes, ma può essere difficile capire esattamente come dovrebbe funzionare. +Il networking è una parte centrale di Kubernetes, ma può essere difficile capire esattamente come dovrebbe funzionare. Ci sono 4 reti distinte problemi da affrontare: 1. Comunicazioni container-to-container altamente accoppiate: questo è risolto da @@ -71,35 +71,35 @@ cieco all'esistenza o alla non esistenza dei porti di accoglienza. ## Come implementare il modello di rete di Kubernetes -Ci sono diversi modi in cui questo modello di rete può essere implementato. Questo il documento non è uno studio +Ci sono diversi modi in cui questo modello di rete può essere implementato. Questo il documento non è uno studio esaustivo dei vari metodi, ma si spera che serva come introduzione a varie tecnologie e serve da punto di partenza. Le seguenti opzioni di networking sono ordinate alfabeticamente - l'ordine no implica uno stato preferenziale. ### ACI -[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) +[Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal -servers. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. +servers. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf). ### AOS da Apstra -[AOS](http://www.apstra.com/products/aos/) è un sistema di rete basato sull'intento che crea e gestisce ambienti di -data center complessi da una semplice piattaforma integrata. AOS sfrutta un design distribuito altamente scalabile per +[AOS](http://www.apstra.com/products/aos/) è un sistema di rete basato sull'intento che crea e gestisce ambienti di +data center complessi da una semplice piattaforma integrata. AOS sfrutta un design distribuito altamente scalabile per eliminare le interruzioni di rete riducendo al minimo i costi. -Il progetto di riferimento AOS attualmente supporta gli host connessi Layer-3 che eliminano i problemi di commutazione -Layer-2 legacy. Questi host Layer-3 possono essere server Linux (Debian, Ubuntu, CentOS) che creano relazioni vicine -BGP direttamente con gli switch top of rack (TOR). AOS automatizza le adiacenze di routing e quindi fornisce un +Il progetto di riferimento AOS attualmente supporta gli host connessi Layer-3 che eliminano i problemi di commutazione +Layer-2 legacy. Questi host Layer-3 possono essere server Linux (Debian, Ubuntu, CentOS) che creano relazioni vicine +BGP direttamente con gli switch top of rack (TOR). AOS automatizza le adiacenze di routing e quindi fornisce un controllo a grana fine sulle iniezioni di integrità del percorso (RHI) comuni in una distribuzione di Kubernetes. -AOS dispone di un ricco set di endpoint REST API che consentono a Kubernetes di modificare rapidamente i criteri di -rete in base ai requisiti dell'applicazione. Ulteriori miglioramenti integreranno il modello AOS Graph utilizzato per -la progettazione della rete con il provisioning del carico di lavoro, consentendo un sistema di gestione end-to-end per +AOS dispone di un ricco set di endpoint REST API che consentono a Kubernetes di modificare rapidamente i criteri di +rete in base ai requisiti dell'applicazione. Ulteriori miglioramenti integreranno il modello AOS Graph utilizzato per +la progettazione della rete con il provisioning del carico di lavoro, consentendo un sistema di gestione end-to-end per cloud privati ​​e pubblici. -AOS supporta l'utilizzo di apparecchiature di produttori comuni di produttori quali Cisco, Arista, Dell, Mellanox, HPE +AOS supporta l'utilizzo di apparecchiature di produttori comuni di produttori quali Cisco, Arista, Dell, Mellanox, HPE e un gran numero di sistemi white-box e sistemi operativi di rete aperti come Microsoft SONiC, Dell OPX e Cumulus Linux. I dettagli su come funziona il sistema AOS sono disponibili qui: http://www.apstra.com/products/how-it-works/ @@ -121,11 +121,11 @@ indirizzamento. ### CNI-Genie from Huawei -[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) è un plugin CNI che consente a Kubernetes -di [avere simultaneamente accesso a diverse implementazioni](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) -del [modello di rete Kubernetes](https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime. -Ciò include qualsiasi implementazione che funziona come un [plugin CNI](https://github.com/containernetworking/cni#3rd-party-plugins), -come [Flannel](https://github.com/coreos/flannel#flanella), [Calico](http://docs.projectcalico.org/), +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) è un plugin CNI che consente a Kubernetes +di [avere simultaneamente accesso a diverse implementazioni](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) +del [modello di rete Kubernetes](https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime. +Ciò include qualsiasi implementazione che funziona come un [plugin CNI](https://github.com/containernetworking/cni#3rd-party-plugins), +come [Flannel](https://github.com/coreos/flannel#flanella), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/tessere-net/). CNI-Genie supporta anche [assegnando più indirizzi IP a un pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-indirizzi-per-pod), ciascuno da un diverso plugin CNI. @@ -151,15 +151,15 @@ complessità della rete richiesta per implementare Kubernetes su larga scala all 226/5000 -[Contiv](https://github.com/contiv/netplugin) fornisce un networking configurabile (nativo l3 usando BGP, +[Contiv](https://github.com/contiv/netplugin) fornisce un networking configurabile (nativo l3 usando BGP, overlay usando vxlan, classic l2 o Cisco-SDN / ACI) per vari casi d'uso. [Contiv](http://contiv.io) è tutto aperto. ### Contrail / Tungsten Fabric -[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basato su -[Tungsten Fabric](https://tungsten.io), è un virtualizzazione della rete e piattaforma di gestione delle -policy realmente aperte e multi-cloud. Contrail e Tungsten Fabric sono integrati con vari sistemi di -orchestrazione come Kubernetes, OpenShift, OpenStack e Mesos e forniscono diverse modalità di isolamento +[Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basato su +[Tungsten Fabric](https://tungsten.io), è un virtualizzazione della rete e piattaforma di gestione delle +policy realmente aperte e multi-cloud. Contrail e Tungsten Fabric sono integrati con vari sistemi di +orchestrazione come Kubernetes, OpenShift, OpenStack e Mesos e forniscono diverse modalità di isolamento per macchine virtuali, contenitori / pod e carichi di lavoro bare metal. ### DANM @@ -176,14 +176,14 @@ Con questo set di strumenti DANM è in grado di fornire più interfacce di rete ### Flannel -[Flannel](https://github.com/coreos/flannel#flannel) è un overlay molto semplice rete che soddisfa i requisiti di +[Flannel](https://github.com/coreos/flannel#flannel) è un overlay molto semplice rete che soddisfa i requisiti di Kubernetes. Molti le persone hanno riportato il successo con Flannel e Kubernetes. ### Google Compute Engine (GCE) -Per gli script di configurazione del cluster di Google Compute Engine, -[avanzato routing](https://cloud.google.com/vpc/docs/routes) è usato per assegna a ciascuna VM una sottorete -(l'impostazione predefinita è `/ 24` - 254 IP). Qualsiasi traffico vincolato per questo la sottorete verrà instradata +Per gli script di configurazione del cluster di Google Compute Engine, +[avanzato routing](https://cloud.google.com/vpc/docs/routes) è usato per assegna a ciascuna VM una sottorete +(l'impostazione predefinita è `/ 24` - 254 IP). Qualsiasi traffico vincolato per questo la sottorete verrà instradata direttamente alla VM dal fabric di rete GCE. Questo è dentro aggiunta all'indirizzo IP "principale" assegnato alla VM, a cui è stato assegnato NAT accesso a Internet in uscita. Un bridge linux (chiamato `cbr0`) è configurato per esistere su quella sottorete, e viene passato al flag `--bridge` della finestra mobile. @@ -196,11 +196,11 @@ DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al `Nodo` .spec.podCIDR`. -Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere l'un l'altro e `Nodi` sul +Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere l'un l'altro e `Nodi` sul ponte` cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE. -GCE non sa nulla di questi IP, quindi non lo farà loro per il traffico internet in uscita. Per ottenere ciò viene -utilizzata una regola iptables masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node` stesso) +GCE non sa nulla di questi IP, quindi non lo farà loro per il traffico internet in uscita. Per ottenere ciò viene +utilizzata una regola iptables masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node` stesso) traffico che è vincolato per IP al di fuori della rete del progetto GCE (10.0.0.0/8). ```shell @@ -219,25 +219,25 @@ traffico verso internet. ### Jaguar -[Jaguar](https://gitlab.com/sdnlab/jaguar) è una soluzione open source per la rete di Kubernetes basata -su OpenDaylight. Jaguar fornisce una rete overlay utilizzando vxlan e Jaguar. CNIPlugin fornisce un indirizzo +[Jaguar](https://gitlab.com/sdnlab/jaguar) è una soluzione open source per la rete di Kubernetes basata +su OpenDaylight. Jaguar fornisce una rete overlay utilizzando vxlan e Jaguar. CNIPlugin fornisce un indirizzo IP per pod. ### Knitter 363/5000 -[Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. -Fornisce la capacità di gestione dei titolari e gestione della rete. Knitter include una serie di soluzioni -di rete container NFV end-to-end oltre a più piani di rete, come mantenere l'indirizzo IP per le applicazioni, +[Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. +Fornisce la capacità di gestione dei titolari e gestione della rete. Knitter include una serie di soluzioni +di rete container NFV end-to-end oltre a più piani di rete, come mantenere l'indirizzo IP per le applicazioni, la migrazione degli indirizzi IP, ecc. ### Kube-router 430/5000 -[Kube-router](https://github.com/cloudnativelabs/kube-router) è una soluzione di rete sviluppata appositamente -per Kubernetes che mira a fornire alte prestazioni e semplicità operativa. Kube-router fornisce un proxy di -servizio basato su Linux [LVS / IPVS](http://www.linuxvirtualserver.org/software/ipvs.html), una soluzione di -rete pod-to-pod basata sul kernel di inoltro del kernel Linux senza sovrapposizioni, e il sistema di sicurezza +[Kube-router](https://github.com/cloudnativelabs/kube-router) è una soluzione di rete sviluppata appositamente +per Kubernetes che mira a fornire alte prestazioni e semplicità operativa. Kube-router fornisce un proxy di +servizio basato su Linux [LVS / IPVS](http://www.linuxvirtualserver.org/software/ipvs.html), una soluzione di +rete pod-to-pod basata sul kernel di inoltro del kernel Linux senza sovrapposizioni, e il sistema di sicurezza della politica di rete basato su iptables / ipset. ### L2 networks and linux bridging @@ -254,41 +254,41 @@ Lars Kellogg-Stedman. ### Multus (a Multi Network plugin) -[Multus](https://github.com/Intel-Corp/multus-cni) è un plugin Multi CNI per supportare la funzionalità Multi +[Multus](https://github.com/Intel-Corp/multus-cni) è un plugin Multi CNI per supportare la funzionalità Multi Networking in Kubernetes utilizzando oggetti di rete basati su CRD in Kubernetes. -Multus supporta tutti i [plug-in di riferimento](https://github.com/containernetworking/plugins) -(ad esempio [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), -[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), -[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) che implementano -le specifiche CNI e i plugin di terze parti (ad esempio [Calico](https://github.com/projectcalico/cni-plugin), -[Weave](https://github.com/weaveworks/weave) ), [Cilium](https://github.com/cilium/cilium), -[Contiv](https://github.com/contiv/netplugin)). Oltre a ciò, Multus supporta -[SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), -[OVS- DPDK e VPP](https://github.com/intel/vhost-user-net-plugin) carichi di lavoro in Kubernetes con applicazioni +Multus supporta tutti i [plug-in di riferimento](https://github.com/containernetworking/plugins) +(ad esempio [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), +[DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), +[Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) che implementano +le specifiche CNI e i plugin di terze parti (ad esempio [Calico](https://github.com/projectcalico/cni-plugin), +[Weave](https://github.com/weaveworks/weave) ), [Cilium](https://github.com/cilium/cilium), +[Contiv](https://github.com/contiv/netplugin)). Oltre a ciò, Multus supporta +[SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), +[OVS- DPDK e VPP](https://github.com/intel/vhost-user-net-plugin) carichi di lavoro in Kubernetes con applicazioni cloud native e basate su NFV in Kubernetes. ### NSX-T -[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) è una piattaforma di virtualizzazione e sicurezza -della rete. NSX-T può fornire la virtualizzazione di rete per un ambiente multi-cloud e multi-hypervisor ed è -focalizzato su architetture applicative emergenti e architetture con endpoint eterogenei e stack tecnologici. Oltre +[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) è una piattaforma di virtualizzazione e sicurezza +della rete. NSX-T può fornire la virtualizzazione di rete per un ambiente multi-cloud e multi-hypervisor ed è +focalizzato su architetture applicative emergenti e architetture con endpoint eterogenei e stack tecnologici. Oltre agli hypervisor vSphere, questi ambienti includono altri hypervisor come KVM, container e bare metal. -[Plug-in contenitore NSX-T (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) fornisce -integrazione tra NSX-T e orchestratori di contenitori come Kubernetes, così come l'integrazione tra NSX-T e piattaforme +[Plug-in contenitore NSX-T (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) fornisce +integrazione tra NSX-T e orchestratori di contenitori come Kubernetes, così come l'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. ### Nuage Networks VCS (Servizi cloud virtualizzati) -[Nuage](http://www.nuagenetworks.net) fornisce una piattaforma Software-Defined Networking (SDN) altamente scalabile -basata su policy. Nuage utilizza open source Open vSwitch per il piano dati insieme a un controller SDN ricco di +[Nuage](http://www.nuagenetworks.net) fornisce una piattaforma Software-Defined Networking (SDN) altamente scalabile +basata su policy. Nuage utilizza open source Open vSwitch per il piano dati insieme a un controller SDN ricco di funzionalità basato su standard aperti. -La piattaforma Nuage utilizza gli overlay per fornire una rete basata su policy senza soluzione di continuità tra i -Pod di Kubernetes e gli ambienti non Kubernetes (VM e server bare metal). Il modello di astrazione delle policy di -Nuage è stato progettato pensando alle applicazioni e semplifica la dichiarazione di policy a grana fine per le -applicazioni. Il motore di analisi in tempo reale della piattaforma consente la visibilità e il monitoraggio della +La piattaforma Nuage utilizza gli overlay per fornire una rete basata su policy senza soluzione di continuità tra i +Pod di Kubernetes e gli ambienti non Kubernetes (VM e server bare metal). Il modello di astrazione delle policy di +Nuage è stato progettato pensando alle applicazioni e semplifica la dichiarazione di policy a grana fine per le +applicazioni. Il motore di analisi in tempo reale della piattaforma consente la visibilità e il monitoraggio della sicurezza per le applicazioni Kubernetes. ### OpenVSwitch @@ -307,37 +307,37 @@ a [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). ### Progetto Calico -[Project Calico](http://docs.projectcalico.org/) è un provider di rete contenitore open source e +[Project Calico](http://docs.projectcalico.org/) è un provider di rete contenitore open source e motore di criteri di rete. -Calico offre una soluzione di rete e di rete altamente scalabile per il collegamento di pod Kubernetes basati sugli -stessi principi di rete IP di Internet, sia per Linux (open source) che per Windows (proprietario - disponibile da -[Tigera](https://www.tigera.io/essenziali/)). Calico può essere distribuito senza incapsulamento o sovrapposizioni per -fornire reti di data center ad alte prestazioni e su vasta scala. Calico fornisce inoltre una politica di sicurezza di +Calico offre una soluzione di rete e di rete altamente scalabile per il collegamento di pod Kubernetes basati sugli +stessi principi di rete IP di Internet, sia per Linux (open source) che per Windows (proprietario - disponibile da +[Tigera](https://www.tigera.io/essenziali/)). Calico può essere distribuito senza incapsulamento o sovrapposizioni per +fornire reti di data center ad alte prestazioni e su vasta scala. Calico fornisce inoltre una politica di sicurezza di rete basata su intere grane per i pod Kubernetes tramite il firewall distribuito. -Calico può anche essere eseguito in modalità di applicazione della policy insieme ad altre soluzioni di rete come +Calico può anche essere eseguito in modalità di applicazione della policy insieme ad altre soluzioni di rete come Flannel, alias [canal](https://github.com/tigera/canal) o native GCE, AWS o networking Azure. ### Romana -[Romana](http://romana.io) è una soluzione di automazione della sicurezza e della rete open source che consente di -distribuire Kubernetes senza una rete di overlay. Romana supporta Kubernetes -[Politica di rete](/docs/concepts/services-networking/network-policies/) per fornire isolamento tra gli spazi dei nomi +[Romana](http://romana.io) è una soluzione di automazione della sicurezza e della rete open source che consente di +distribuire Kubernetes senza una rete di overlay. Romana supporta Kubernetes +[Politica di rete](/docs/concepts/services-networking/network-policies/) per fornire isolamento tra gli spazi dei nomi di rete. ### Weave Net di Weaveworks -[Weave Net](https://www.weave.works/products/weave-net/) è un rete resiliente e semplice da usare per Kubernetes e le +[Weave Net](https://www.weave.works/products/weave-net/) è un rete resiliente e semplice da usare per Kubernetes e le sue applicazioni in hosting. Weave Net funziona come un plug-in [CNI](https://www.weave.works/docs/net/latest/cni-plugin/) -o stand-alone. In entrambe le versioni, non richiede alcuna configurazione o codice aggiuntivo per eseguire, e in +o stand-alone. In entrambe le versioni, non richiede alcuna configurazione o codice aggiuntivo per eseguire, e in entrambi i casi, la rete fornisce un indirizzo IP per pod, come è standard per Kubernetes. {{% /capture %}} {{% capture whatsnext %}} -Il progetto iniziale del modello di rete e la sua logica, e un po 'di futuro i piani sono descritti in maggior +Il progetto iniziale del modello di rete e la sua logica, e un po 'di futuro i piani sono descritti in maggior dettaglio nella [progettazione della rete documento](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). {{% /capture %}} diff --git a/content/it/includes/federation-deprecation-warning-note.md b/content/it/includes/federation-deprecation-warning-note.md index 2d53cdaaf1e..27c525642ce 100644 --- a/content/it/includes/federation-deprecation-warning-note.md +++ b/content/it/includes/federation-deprecation-warning-note.md @@ -1,5 +1,5 @@ -L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` ha ormai raggiunto lo stato GA e non è più in +L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` ha ormai raggiunto lo stato GA e non è più in fase di sviluppo attivo. La documentazione è solo per scopi storici. -Per ulteriori informazioni, il seguente link +Per ulteriori informazioni, il seguente link [Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2).