From cf86480431fc7fd05ac0276b4dc20c30560e5033 Mon Sep 17 00:00:00 2001 From: Roy Lenferink Date: Thu, 11 Apr 2019 19:44:47 +0200 Subject: [PATCH] Improved markdown for Italian translation (#13785) --- content/it/_index.html | 24 +-- content/it/docs/concepts/_index.md | 4 +- .../concepts/architecture/cloud-controller.md | 2 +- .../it/docs/concepts/architecture/nodes.md | 18 +- .../concepts/cluster-administration/addons.md | 33 ++-- .../cluster-administration/cloud-providers.md | 92 +++++---- .../cluster-administration-overview.md | 19 +- .../controller-metrics.md | 19 +- .../cluster-administration/federation.md | 34 ++-- .../kubelet-garbage-collection.md | 26 ++- .../cluster-administration/logging.md | 18 +- .../manage-deployment.md | 120 ++++++++---- .../cluster-administration/networking.md | 185 +++++++++++------- .../cluster-administration/proxies.md | 6 +- .../concepts/overview/what-is-kubernetes.md | 2 +- .../federation-deprecation-warning-note.md | 6 +- 16 files changed, 359 insertions(+), 249 deletions(-) diff --git a/content/it/_index.html b/content/it/_index.html index 5d5e7fadf2..38840cb037 100644 --- a/content/it/_index.html +++ b/content/it/_index.html @@ -38,18 +38,18 @@ Kubernetes è open source e ti offre la libertà di trarre vantaggio dall'infras {{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}
-

Le sfide della migrazione di oltre 150 microservizi a Kubernetes

-

By Sarah Wells, Technical Director for Operations and Reliability, Financial Times

- -
-
-
- Attend KubeCon in Barcelona on May 20-23, 2019 -
-
-
-
- Attend KubeCon in Shanghai on June 24-26, 2019 +

Le sfide della migrazione di oltre 150 microservizi a Kubernetes

+

By Sarah Wells, Technical Director for Operations and Reliability, Financial Times

+ +
+
+
+ Attend KubeCon in Barcelona on May 20-23, 2019 +
+
+
+
+ Attend KubeCon in Shanghai on June 24-26, 2019
diff --git a/content/it/docs/concepts/_index.md b/content/it/docs/concepts/_index.md index 7c6f286317..5acaec055e 100644 --- a/content/it/docs/concepts/_index.md +++ b/content/it/docs/concepts/_index.md @@ -19,7 +19,7 @@ Per lavorare con Kubernetes, usi *gli oggetti API Kubernetes* per descrivere lo Una volta impostato lo stato desiderato, il *Kubernetes Control Plane* funziona per fare in modo che lo stato corrente del cluster corrisponda allo stato desiderato. Per fare ciò, Kubernetes esegue automaticamente una serie di attività, come l'avvio o il riavvio dei contenitori, il ridimensionamento del numero di repliche di una determinata applicazione e altro ancora. Il piano di controllo di Kubernetes è costituito da una raccolta di processi in esecuzione sul cluster: -* Il **Kubernetes Master** è una raccolta di tre processi che vengono eseguiti su un singolo nodo nel cluster, che è designato come nodo principale. Questi processi sono: [kube-apiserver] (/docs/admin/kube-apiserver/), [kube-controller-manager] (/docs/admin/kube-controller-manager/) e [kube-scheduler] (/docs/admin/kube-scheduler/). +* Il **Kubernetes Master** è una raccolta di tre processi che vengono eseguiti su un singolo nodo nel cluster, che è designato come nodo principale. Questi processi sono: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) e [kube-scheduler](/docs/admin/kube-scheduler/). * Ogni singolo nodo non principale nel cluster esegue due processi:   * **[kubelet](/docs/admin/kubelet/)**, che comunica con il master di Kubernetes.   * **[kube-proxy](/docs/admin/kube-proxy/)**, un proxy di rete che riflette i servizi di rete di Kubernetes su ciascun nodo. @@ -71,7 +71,7 @@ I nodi di un cluster sono le macchine (VM, server fisici, ecc.) Che eseguono i f {{% capture whatsnext %}} Se vuoi scrivere una pagina concettuale, vedi -[Uso dei modelli di pagina] (/docs/home/contribute/page-templates/) +[Uso dei modelli di pagina](/docs/home/contribute/page-templates/) per informazioni sul tipo di pagina di concetto e il modello di concetto. {{% /capture %}} diff --git a/content/it/docs/concepts/architecture/cloud-controller.md b/content/it/docs/concepts/architecture/cloud-controller.md index a3032c74e7..bac2e7a654 100644 --- a/content/it/docs/concepts/architecture/cloud-controller.md +++ b/content/it/docs/concepts/architecture/cloud-controller.md @@ -111,7 +111,7 @@ Il controller Persistent Volume Labels sposta la funzionalità dipendente dal cl ## Plugin mechanism -Il gestore del controller cloud utilizza le interfacce Go per consentire l'implementazione di implementazioni da qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui] (https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud. go # L42-L62). +Il gestore del controller cloud utilizza le interfacce Go per consentire l'implementazione di implementazioni da qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62). L'implementazione dei quattro controller condivisi evidenziati sopra e alcuni scaffolding con l'interfaccia cloudprovider condivisa rimarranno nel core di Kubernetes. Le implementazioni specifiche per i fornitori di cloud saranno costruite al di fuori del core e implementeranno le interfacce definite nel core. diff --git a/content/it/docs/concepts/architecture/nodes.md b/content/it/docs/concepts/architecture/nodes.md index c9e33ed9b5..bba9a7bf74 100644 --- a/content/it/docs/concepts/architecture/nodes.md +++ b/content/it/docs/concepts/architecture/nodes.md @@ -63,9 +63,9 @@ 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) +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 @@ -74,7 +74,7 @@ Kubernetes fa sì che tutti gli oggetti Pod in esecuzione sul nodo vengano elimi Nella versione 1.12, la funzione `TaintNodesByCondition` è promossa in versione beta, quindi il controller del ciclo di vita del nodo crea automaticamente -[taints] (/ docs / concepts / configuration / taint-and-toleration /) che rappresentano le condizioni. +[taints](/docs/concepts/configuration/taint-and-toleration/) che rappresentano le condizioni. Allo stesso modo lo schedulatore ignora le condizioni quando si considera un nodo; anziché guarda le tinte del Nodo e le tolleranze di un Pod. @@ -161,7 +161,7 @@ controlla lo stato di ogni nodo ogni `--node-monitor-period` secondi. Nelle versioni di Kubernetes precedenti alla 1.13, NodeStatus è l'heartbeat di nodo. A partire da Kubernetes 1.13, la funzionalità di lease del nodo viene introdotta come un funzione alfa (porta caratteristica `NodeLease`, -[KEP-0009] (https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). +[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). Quando la funzione di lease del nodo è abilitata, ogni nodo ha un oggetto `Lease` associato in spazio dei nomi `kube-node-lease` che viene rinnovato periodicamente dal nodo ed entrambi NodeStatus e lease del nodo vengono considerati heartbeat dal nodo. Locazioni di nodi @@ -208,7 +208,7 @@ A partire da Kubernetes 1.6, il NodeController è anche responsabile della rimoz i pod che sono in esecuzione sui nodi con `NoExecute`, quando i pod non tollerano i taints. Inoltre, come caratteristica alfa che è disabilitata per impostazione predefinita, il NodeController è responsabile per l'aggiunta di taints corrispondenti ai problemi del nodo come -nodo irraggiungibile o non pronto. Vedi [questa documentazione] (/docs/concepts/configuration/taint-and-toleration/) +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. @@ -226,7 +226,7 @@ Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni: - `--register-node` - Si registra automaticamente con il server API. - `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola` = : `). 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-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 @@ -265,15 +265,15 @@ la macchina anche se viene scaricata dalle applicazioni mentre si prepara per un La capacità del nodo (numero di cpu e quantità di memoria) è parte dell'oggetto nodo. Normalmente, i nodi si registrano e segnalano la loro capacità durante la creazione dell'oggetto nodo. Se -stai facendo [amministrazione manuale del nodo] (# manual-node-administration), quindi devi impostare il nodo +stai facendo [amministrazione manuale del nodo](#manual-node-administration), quindi devi impostare il nodo capacità quando si aggiunge un nodo. Lo scheduler di Kubernetes garantisce che ci siano risorse sufficienti per tutti i pod su un nodo. esso controlla che la somma delle richieste di container sul nodo non sia maggiore della capacità del nodo. esso -include tutti i contenitori avviati da kubelet, ma non i contenitori avviati direttamente dal [contenitore runtime] (/docs/concepts/overview/components/ # node-components) né qualsiasi processo eseguito all'esterno dei contenitori. +include tutti i contenitori avviati da kubelet, ma non i contenitori avviati direttamente dal [contenitore runtime](/docs/concepts/overview/components/#node-components) né qualsiasi processo eseguito all'esterno dei contenitori. Se si desidera riservare esplicitamente risorse per processi non Pod, seguire questo tutorial su -[riserva risorse per i demoni di sistema] (/docs/tasks/administration-cluster/reserve-compute-resources/ # system-reserved). +[riserva risorse per i demoni di sistema](/docs/tasks/administration-cluster/reserve-compute-resources/#system-reserved). ## API Object diff --git a/content/it/docs/concepts/cluster-administration/addons.md b/content/it/docs/concepts/cluster-administration/addons.md index 8eb2a1bc5e..67571124ce 100644 --- a/content/it/docs/concepts/cluster-administration/addons.md +++ b/content/it/docs/concepts/cluster-administration/addons.md @@ -19,33 +19,32 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine ## Networking and Network Policy - -* [ACI] (https://www.github.com/noironetworks/aci-containers) fornisce funzionalità integrate di networking e sicurezza di rete con Cisco ACI. -* [Calico] (https://docs.projectcalico.org/latest/getting-started/kubernetes/) è un provider di sicurezza e rete L3 sicuro. -* [Canal] (https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete. -* [Cilium] (https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento. -* [CNI-Genie] (https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave. -* [Contiv] (http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source] (http://github.com/contiv). Il [programma di installazione] (http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm. -* [Flanella] (https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes. -* [Knitter] (https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. -* [Multus] (https://github.com/Intel-Corp/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes. -* [NSX-T] (https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. -* [Nuage] (https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1/docs/kubernetes-1-installation.rst) è una piattaforma SDN che fornisce una rete basata su policy tra i pod di Kubernetes e non Kubernetes con visibilità e monitoraggio della sicurezza. -* [Romana] (http://romana.io) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy] (/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui] (https://github.com/romana/romana/tree/master/containerize). -* [Weave Net] (https://www.weave.works/docs/net/latest/kube-addon/) fornisce i criteri di rete e di rete, continuerà a funzionare su entrambi i lati di una partizione di rete e non richiede un database esterno. +* [ACI](https://www.github.com/noironetworks/aci-containers) fornisce funzionalità integrate di networking e sicurezza di rete con Cisco ACI. +* [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) è un provider di sicurezza e rete L3 sicuro. +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete. +* [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento. +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave. +* [Contiv](http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm. +* [Flanella](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes. +* [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. +* [Multus](https://github.com/Intel-Corp/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1/docs/kubernetes-1-installation.rst) è una piattaforma SDN che fornisce una rete basata su policy tra i pod di Kubernetes e non Kubernetes con visibilità e monitoraggio della sicurezza. +* [Romana](http://romana.io) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui](https://github.com/romana/romana/tree/master/containerize). +* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornisce i criteri di rete e di rete, continuerà a funzionare su entrambi i lati di una partizione di rete e non richiede un database esterno. ## Service Discovery -* [CoreDNS] (https://coredns.io) è un server DNS flessibile ed estensibile che può essere [installato] (https://github.com/coredns/deployment/tree/master/kubernetes) come in-cluster DNS per pod. +* [CoreDNS](https://coredns.io) è un server DNS flessibile ed estensibile che può essere [installato](https://github.com/coredns/deployment/tree/master/kubernetes) come in-cluster DNS per pod. ## Visualization & Control [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) è un'interfaccia web dashboard per Kubernetes. -* [Weave Scope] (https://www.weave.works/documentation/scope-latest-installing/#k8s) è uno strumento per la visualizzazione grafica di contenitori, pod, servizi, ecc. Utilizzalo in combinazione con un [Weave Cloud account] (https://cloud.weave.works/) o ospitali tu stesso. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) è uno strumento per la visualizzazione grafica di contenitori, pod, servizi, ecc. Utilizzalo in combinazione con un [Weave Cloud account](https://cloud.weave.works/) o ospitali tu stesso. ## Legacy Add-ons -qui ci sono molti altri componenti aggiuntivi documentati nella directory deprecata [cluster / addons] (https://git.k8s.io/kubernetes/cluster/addons). +qui ci sono molti altri componenti aggiuntivi documentati nella directory deprecata [cluster / addons](https://git.k8s.io/kubernetes/cluster/addons). Quelli ben mantenuti dovrebbero essere collegati qui. diff --git a/content/it/docs/concepts/cluster-administration/cloud-providers.md b/content/it/docs/concepts/cluster-administration/cloud-providers.md index f21d8e1ea1..ea2c49533a 100644 --- a/content/it/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/it/docs/concepts/cluster-administration/cloud-providers.md @@ -11,10 +11,11 @@ fornitore di servizi cloud. {{% capture body %}} + ### 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 un tipico -il provider cloud in-tree può essere configurato utilizzando kubeadm come mostrato di seguito: +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 apiVersion: kubeadm.k8s.io/v1beta1 @@ -45,22 +46,22 @@ controllerManager: mountPath: "/etc/kubernetes/cloud.conf" ``` -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. +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. 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 Kubernetes su Amazon Web Services. +Questa sezione descrive tutte le possibili configurazioni che possono essere utilizzato durante l'esecuzione di +Kubernetes su Amazon Web Services. ### Node Name - Il provider cloud AWS utilizza il nome DNS privato dell'istanza AWS come nome dell'oggetto Nodo Kubernetes. ### Load Balancers -È possibile impostare [bilanciamento del carico esterno] (/docs/tasks/access-application-cluster/create-external-load-balancer/) +È possibile impostare [bilanciamento del carico esterno](/docs/tasks/access-application-cluster/create-external-load-balancer/) per utilizzare funzionalità specifiche in AWS configurando le annotazioni come mostrato di seguito. ```yaml @@ -91,7 +92,7 @@ spec: * `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-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-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. * `service.beta.kubernetes.io / aws-load-balancer-connection-idle-timeout`: utilizzato sul servizio per specificare il timeout della connessione inattiva. @@ -101,43 +102,41 @@ spec: * `service.beta.kubernetes.io / aws-load-balancer-proxy-protocol`: utilizzato sul servizio per abilitare il protocollo proxy su un ELB. Al momento accettiamo solo il valore `*` che significa abilitare il protocollo proxy su tutti i backend ELB. In futuro potremmo regolarlo per consentire l'impostazione del protocollo proxy solo su determinati backend. * `service.beta.kubernetes.io / aws-load-balancer-ssl-ports`: utilizzato sul servizio per specificare un elenco di porte separate da virgole che utilizzeranno listener SSL / HTTPS. Il valore predefinito è `*` (tutto) -Le informazioni per le annotazioni per AWS sono tratte dai commenti su [aws.go] (https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go) +Le informazioni per le annotazioni per AWS sono tratte dai commenti su [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/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 corrispondere al nome VM di Azure. +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 corrispondere al nome VM di CloudStack. +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 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`) . +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`) . ## OpenStack Questa sezione descrive tutte le possibili configurazioni che possono essere utilizzato quando si utilizza OpenStack con Kubernetes. ### Node Name - Il provider cloud OpenStack utilizza il nome dell'istanza (come determinato dai metadati OpenStack) come nome dell'oggetto Nodo Kubernetes. 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 sottostante, ove disponibile: +Il provider cloud OpenStack implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da la nuvola +sottostante, ove disponibile: | Servizio | Versioni API | Richiesto | | -------------------------- | ---------------- | ----- ----- | @@ -253,7 +252,8 @@ 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 valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h" +  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   valore. Assicurati di specificare un'unità di tempo valida. Le unità di tempo valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h" @@ -346,42 +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 +corrispondere al FQDN del VM (riportato da OVirt in ` ... `) -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 deve corrispondere all'indirizzo IP della macchina virtuale Photon). +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 Nodo Kubernetes. +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, consultare [Pianificazione dell'installazione di cluster e nodo di lavoro] (https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). +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 informazioni, vedere [Pianificazione in-cluster e rete privata] (https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster). +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 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). +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 informazioni, vedere [Pianificazione dell'archiviazione persistente altamente disponibile] (https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning). +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 corrispondere all'IP privato VM di Baidu. +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 5b0d5e87ce..0a10020fb0 100644 --- a/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -6,36 +6,37 @@ weight: 10 {{% capture overview %}} La panoramica dell'amministrazione del cluster è per chiunque crei o gestisca un cluster Kubernetes. -Presuppone una certa dimestichezza con i core Kubernetes [concetti] (/docs/concepts/). +Presuppone una certa dimestichezza con i core Kubernetes [concetti](/docs/concepts/). {{% /capture %}} {{% capture body %}} ## Planning a cluster -Consulta le guide in [Scelta della soluzione giusta] (/docs/setup/pick-right-solution/) per esempio su come pianificare, impostare e configurare i cluster di Kubernetes. Le soluzioni elencate in questo articolo sono chiamate *distros*. +Consulta le guide in [Scelta della soluzione giusta](/docs/setup/pick-right-solution/) per esempio su come pianificare, +impostare e configurare i cluster di Kubernetes. Le soluzioni elencate in questo articolo sono chiamate *distros*. Prima di scegliere una guida, ecco alcune considerazioni:  - Vuoi provare Kubernetes sul tuo computer o vuoi creare un cluster multi-nodo ad alta disponibilità? Scegli le distro più adatte alle tue esigenze. - - **Se si sta progettando per l'alta disponibilità**, imparare 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**? + - **Se si sta progettando per l'alta disponibilità**, imparare 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 si sta configurando Kubernetes on-premises**, considerare quale [modello di rete] (/docs/concepts/cluster-administration/networking/) si adatta meglio. + - **Se si sta configurando Kubernetes on-premises**, considerare quale [modello di rete](/docs/concepts/cluster-administration/networking/) si adatta meglio.  - Avvierai 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**? Se la    Quest'ultimo, scegliere una distribuzione attivamente sviluppata. Alcune distribuzioni usano solo versioni binarie, ma    offrire una maggiore varietà di scelte. - - Familiarizzare con i [componenti] (/docs/admin/cluster-components/) necessari per eseguire un cluster. + - Familiarizzare con i [componenti](/docs/admin/cluster-components/) necessari per eseguire un cluster. Nota: non tutte le distro vengono mantenute attivamente. Scegli le distro che sono state testate con una versione recente di Kubernetes. ## Managing a cluster -* [Gestione di un cluster] (/docs/tasks/administration-cluster/cluster-management/) descrive diversi argomenti relativi al ciclo di vita di un cluster: creazione di un nuovo cluster, aggiornamento dei nodi master e worker del cluster, esecuzione della manutenzione del nodo (ad esempio kernel aggiornamenti) e aggiornamento della versione dell'API di Kubernetes di un cluster in esecuzione. +* [Gestione di un cluster](/docs/tasks/administration-cluster/cluster-management/) descrive diversi argomenti relativi al ciclo di vita di un cluster: creazione di un nuovo cluster, aggiornamento dei nodi master e worker del cluster, esecuzione della manutenzione del nodo (ad esempio kernel aggiornamenti) e aggiornamento della versione dell'API di Kubernetes di un cluster in esecuzione. -* Scopri come [gestire i nodi] (/docs/concepts/nodi/node/). +* Scopri come [gestire i nodi](/docs/concepts/nodi/node/). -* Scopri come impostare e gestire la [quota di risorse] (/docs/concepts/policy/resource-quote/) per i cluster condivisi. +* Scopri come impostare e gestire la [quota di risorse](/docs/concepts/policy/resource-quote/) per i cluster condivisi. ## Proteggere 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 9cffd87f77..c38d0840cd 100644 --- a/content/it/docs/concepts/cluster-administration/controller-metrics.md +++ b/content/it/docs/concepts/cluster-administration/controller-metrics.md @@ -7,19 +7,20 @@ weight: 100 {{% capture overview %}} Le metriche del controller controller forniscono informazioni importanti sulle prestazioni e la salute di il responsabile del controller. - {{% /capture %}} {{% capture body %}} + ## 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 utilizzate -per valutare la salute di un cluster. +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 di volume persistenti. +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: @@ -32,16 +33,14 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` - ## Configurazione In un cluster, le metriche di controller-manager sono disponibili da `http://localhost:10252/metrics` dall'host su cui è in esecuzione il controller-manager. -Le metriche sono emesse in [formato prometheus] (https://prometheus.io/docs/instrumenting/exposition_formats/). +Le metriche sono emesse in [formato prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/). In un ambiente di produzione è possibile configurare prometheus o altri strumenti di misurazione delle metriche per raccogliere periodicamente queste metriche e renderle disponibili in una sorta di database di serie temporali. {{% /capture %}} - diff --git a/content/it/docs/concepts/cluster-administration/federation.md b/content/it/docs/concepts/cluster-administration/federation.md index 2783cfd3d0..187d231f9a 100644 --- a/content/it/docs/concepts/cluster-administration/federation.md +++ b/content/it/docs/concepts/cluster-administration/federation.md @@ -42,8 +42,8 @@ perché potresti volere che più cluster siano:   cluster in diverse zone di disponibilità di un provider cloud). * Scalabilità: esistono limiti di scalabilità per un singolo cluster di kubernetes (questo   non dovrebbe essere il caso per la maggior parte degli utenti. Per ulteriori dettagli: -  [Scaling di Kubernetes e obiettivi di rendimento] (https://git.k8s.io/community/sig-scalability/goals.md)). -* [Hybrid cloud] (# hybrid-cloud-capabilities): è possibile avere più cluster su diversi provider cloud o +  [Scaling di Kubernetes e obiettivi di rendimento](https://git.k8s.io/community/sig-scalability/goals.md)). +* [Hybrid cloud](#hybrid-cloud-capabilities): è possibile avere più cluster su diversi provider cloud o   data center locali. ### Caveats @@ -62,7 +62,7 @@ alcuni avvertimenti:   dal lato della sicurezza ed evitare l'interruzione del multi-cluster. * Maturità: il progetto di federazione è relativamente nuovo e non è molto maturo.   Non tutte le risorse sono disponibili e molte sono ancora alfa. [Problema -  88] (https://github.com/kubernetes/federation/issues/88) enumera +  88](https://github.com/kubernetes/federation/issues/88) enumera   problemi noti con il sistema che il team è impegnato a risolvere. ### Hybrid cloud capabilities @@ -78,7 +78,7 @@ e fornitori di cloud. Per poter federare più cluster, è necessario prima impostare una federazione piano di controllo. -Seguire la [guida di installazione] (/docs/tutorial/federazione/set-up-cluster-federation-kubefed/) per configurare il +Seguire la [guida di installazione](/docs/tutorial/federazione/set-up-cluster-federation-kubefed/) per configurare il piano di controllo della federazione. ## API resources @@ -100,7 +100,7 @@ Le seguenti guide illustrano alcune delle risorse in dettaglio: * [Secrets](/docs/tasks/administer-federation/secret/) * [Services](/docs/concepts/cluster-administration/federation-service-discovery/) -I [documenti di riferimento API] (/docs/reference/federation/) elencano tutti i +I [documenti di riferimento API](/docs/reference/federation/) elencano tutti i risorse supportate da apiserver della federazione. ## Cascading deletion @@ -121,8 +121,8 @@ risorse federative. ## Ambito di un singolo cluster Sui provider IaaS come Google Compute Engine o Amazon Web Services, esiste una VM in a -[zona] (https://cloud.google.com/compute/docs/zones) o [disponibilità -zona] (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). +[zona](https://cloud.google.com/compute/docs/zones) o [disponibilità +zona](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). Suggeriamo che tutte le VM in un cluster Kubernetes debbano essere nella stessa zona di disponibilità, perché:   - Rispetto ad un singolo cluster globale di Kubernetes, ci sono meno punti singoli di errore. @@ -167,20 +167,16 @@ utenti in caso di guasto di un cluster), quindi è necessario disporre di cluste 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 -cluster fino a 5000 nodi. Vedi [Costruire cluster di grandi dimensioni] (/docs/setup/cluster-large/) per maggiori informazioni. +cluster fino a 5000 nodi. Vedi [Costruire cluster di grandi dimensioni](/docs/setup/cluster-large/) per maggiori informazioni. {{% /capture %}} {{% capture whatsnext %}} -* Ulteriori informazioni sulla [Federazione -   proposta] (https://github.com/kubernetes/community/blob/{{}}/contributors/design-proposal/multicluster/federation.md). -* Vedi questo [guida alla configurazione] (/ docs / tutorial / federazione / set-up-cluster-federation-kubefed /) per la federazione dei cluster. -* Vedi questo [Kubecon2016 talk on federation] (https://www.youtube.com/watch?v=pq9lbkmxpS8) -* Vedi questo [Kubecon2017 aggiornamento Europa sulla federazione] (https://www.youtube.com/watch?v=kwOvOLnFYck) -* Vedi questo [Kubecon2018 aggiornamento Europa su sig-multicluster] (https://www.youtube.com/watch?v=vGZo5DaThQU) -* Vedi questo [Kubecon2018 Europe Federation-v2 presentazione prototipo] (https://youtu.be/q27rbaX5Jis?t=7m20s) -* Vedi questo [Federation-v2 Userguide] (https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) +* Ulteriori informazioni sulla [Federazione proposta](https://github.com/kubernetes/community/blob/{{}}/contributors/design-proposal/multicluster/federation.md). +* Vedi questo [guida alla configurazione](/docs/tutorial/federazione/set-up-cluster-federation-kubefed/) per la federazione dei cluster. +* Vedi questo [Kubecon2016 talk on federation](https://www.youtube.com/watch?v=pq9lbkmxpS8) +* Vedi questo [Kubecon2017 aggiornamento Europa sulla federazione](https://www.youtube.com/watch?v=kwOvOLnFYck) +* Vedi questo [Kubecon2018 aggiornamento Europa su sig-multicluster](https://www.youtube.com/watch?v=vGZo5DaThQU) +* Vedi questo [Kubecon2018 Europe Federation-v2 presentazione prototipo](https://youtu.be/q27rbaX5Jis?t=7m20s) +* Vedi questo [Federation-v2 Userguide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) {{% /capture %}} - - - 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 3afda3c2bf..f787519141 100644 --- a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -6,10 +6,12 @@ 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 +ogni cinque minuti. -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 interrompere il comportamento di kubelet rimuovendo i contenitori che si prevede esistano. +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 %}} @@ -32,10 +34,19 @@ 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` e `MaxContainers` rispettivamente a meno di zero. +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 contenitori di proprietà dei pod che sono stati cancellati vengono rimossi una volta che sono più vecchi di "MinAge". +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. @@ -61,8 +72,7 @@ I contenitori possono potenzialmente essere raccolti prima che la loro utilità può contenere log e altri dati che possono essere utili per la risoluzione dei problemi. Un valore sufficientemente grande per `maximum-dead-containers-per-container` è altamente raccomandato per consentire almeno un contenitore morto mantenuto per contenitore previsto. Un valore più grande per "massimo-dead-containers" è anche raccomandato per a -motivo simile. -Vedi [questo problema] (https://github.com/kubernetes/kubernetes/issues/13287) per maggiori dettagli. +motivo simile. Vedi [questo problema](https://github.com/kubernetes/kubernetes/issues/13287) per maggiori dettagli. ## Deprecation diff --git a/content/it/docs/concepts/cluster-administration/logging.md b/content/it/docs/concepts/cluster-administration/logging.md index b576bf0f52..6c584d8978 100644 --- a/content/it/docs/concepts/cluster-administration/logging.md +++ b/content/it/docs/concepts/cluster-administration/logging.md @@ -24,7 +24,7 @@ la descrizione di come i registri sono memorizzati e gestiti sul nodo per essere In questa sezione, puoi vedere un esempio di registrazione di base in Kubernetes emette i dati sul flusso di output standard. Utilizza questa dimostrazione -una [specifica pod] (/esempi/debug/counter-pod.yaml) con +una [specifica pod](/esempi/debug/counter-pod.yaml) con un contenitore che scrive del testo sullo standard output una volta al secondo. {{< codenew file="debug/counter-pod.yaml" >}} @@ -46,13 +46,13 @@ $ kubectl logs counter ... ``` -You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag` --previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`] (/docs/reference/generated/kubectl/kubectl-commands # logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details. +You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag` --previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details. ## Logging at the node level -! [Node level logging] (/images/docs/user-guide/logging/logging-node-level.png) +! [Node level logging](/images/docs/user-guide/logging/logging-node-level.png) -Tutto ciò che una applicazione containerizzata scrive su `stdout` e` stderr` viene gestito e reindirizzato da qualche parte da un motore contenitore. Ad esempio, il motore del contenitore Docker reindirizza questi due flussi a [un driver di registrazione] (https://docs.docker.com/engine/admin/logging/overview), che è configurato in Kubernetes per scrivere su un file in formato json . +Tutto ciò che una applicazione containerizzata scrive su `stdout` e` stderr` viene gestito e reindirizzato da qualche parte da un motore contenitore. Ad esempio, il motore del contenitore Docker reindirizza questi due flussi a [un driver di registrazione](https://docs.docker.com/engine/admin/logging/overview), che è configurato in Kubernetes per scrivere su un file in formato json . {{}} Il driver di registrazione di Docker json considera ogni riga come un messaggio separato. Quando si utilizza il driver di registrazione di Docker, non esiste un supporto diretto per i messaggi su più righe. È necessario gestire i messaggi multilinea a livello di agente di registrazione o superiore. @@ -65,7 +65,7 @@ in modo che i registri non consumino tutta la memoria disponibile sul nodo. kube al momento non è responsabile della rotazione dei registri, ma piuttosto di uno strumento di distribuzione dovrebbe creare una soluzione per affrontarlo. Ad esempio, nei cluster di Kubernetes, implementato dallo script `kube-up.sh`, -c'è un [`logrotate`] (https://linux.die.net/man/8/logrotate) +c'è un [`logrotate`](https://linux.die.net/man/8/logrotate) strumento configurato per funzionare ogni ora. È anche possibile impostare un runtime del contenitore su ruotare automaticamente i registri dell'applicazione, ad es. usando il `log-opt` di Docker. Nello script `kube-up.sh`, quest'ultimo approccio viene utilizzato per l'immagine COS su GCP, @@ -75,7 +75,7 @@ la rotazione predefinita è configurata per essere eseguita quando il file di re Ad esempio, puoi trovare informazioni dettagliate su come `kube-up.sh` imposta up logging per l'immagine COS su GCP nello [script] [cosConfigureHelper] corrispondente. -Quando esegui [`kubectl logs`] (/docs/reference/generated/kubectl/kubectl-commands#logs) come in +Quando esegui [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) come in l'esempio di registrazione di base, il kubelet sul nodo gestisce la richiesta e legge direttamente dal file di log, restituendo il contenuto nella risposta. @@ -223,17 +223,17 @@ quei log usando il comando `kubectl logs`, perché non sono controllati dal kubelet. {{}} -Ad esempio, è possibile utilizzare [Stackdriver] (/docs/tasks/debug-application-cluster/logging-stackdriver/), +Ad esempio, è possibile utilizzare [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/), che utilizza fluentd come agente di registrazione. Qui ci sono due file di configurazione puoi usare per implementare questo approccio. Il primo file contiene -a [ConfigMap] (/docs/tasks/configure-pod-container/configure-pod-configmap/) per configurare fluentd. +a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) per configurare fluentd. {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} {{< note >}} La configurazione di fluentd esula dallo scopo di questo articolo. Per informazioni sulla configurazione di fluentd, vedere il -[documentazione fluentd ufficiale] (http://docs.fluentd.org/). +[documentazione fluentd ufficiale](http://docs.fluentd.org/). {{< /note >}} Il secondo file descrive un pod con un contenitore sidecar in esecuzione fluentd. diff --git a/content/it/docs/concepts/cluster-administration/manage-deployment.md b/content/it/docs/concepts/cluster-administration/manage-deployment.md index 35ca237dbe..33f3cb7ec2 100644 --- a/content/it/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/it/docs/concepts/cluster-administration/manage-deployment.md @@ -6,7 +6,10 @@ 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/) e [labels] (/docs/concepts/overview/working-with-objects/labels/). +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 %}} @@ -130,13 +133,14 @@ deployment.apps/my-deployment created persistentvolumeclaim/my-pvc created ``` -Se sei interessato a saperne di più su `kubectl`, vai avanti e leggi [Panoramica di kubectl] (/docs/reference/kubectl/overview/). +Se sei interessato a saperne di più su `kubectl`, vai avanti e leggi [Panoramica di kubectl](/docs/reference/kubectl/overview/). ## Usare le etichette in modo efficace Gli esempi che abbiamo utilizzato fino ad ora si applicano al massimo una singola etichetta a qualsiasi risorsa. Esistono molti scenari in cui è necessario utilizzare più etichette per distinguere i set l'uno dall'altro. -Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook] (https://github.com/kubernetes/examples/tree/ {{}} / guestbook /), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette: +Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette: + ```yaml labels: app: guestbook @@ -183,7 +187,10 @@ 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 modo che la nuova versione possa ricevere il traffico di produzione in tempo reale prima di distribuirlo completamente. +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. @@ -201,7 +208,8 @@ 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 (ad esempio` canary`), in modo che due gruppi di pod non si sovrappongano: +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 name: frontend-canary @@ -215,8 +223,9 @@ 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 applicazioni: +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 selector: @@ -225,15 +234,17 @@ Il servizio di frontend coprirebbe entrambe le serie di repliche selezionando il ``` 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 la traccia stabile alla nuova versione dell'applicazione e rimuovere quella canarino. +È 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). +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 semplicemente: +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 $ kubectl label pods -l app=nginx tier=fe @@ -242,8 +253,8 @@ 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 appena etichettati, esegui: +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 $ kubectl get pods -l app=nginx -L tier @@ -253,13 +264,17 @@ my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe 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`). +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 [kubectl label] (/docs/reference/generated/kubectl/kubectl-commands/ # label). +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 esempio: +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 $ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' @@ -272,11 +287,13 @@ metadata: ... ``` -Per ulteriori informazioni, consultare il documento [annotazioni] (/docs/concepts/overview/working-with-objects/annotations/) e [kubectl annotate] (/docs/reference/generated/kubectl/kubectl-commands/ # annotate). +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 repliche nginx da 3 a 1, fare: +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 $ kubectl scale deployment/my-nginx --replicas=1 @@ -285,7 +302,6 @@ deployment.extensions/my-nginx scaled Ora hai solo un pod gestito dalla distribuzione - ```shell $ kubectl get pods -l app=nginx NAME READY STATUS RESTARTS AGE @@ -301,7 +317,9 @@ 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 [orizzontale pod autoscaler] (/docs/tasks/run-application/horizontal-pod-autoscale/). +Per maggiori informazioni, vedi [scala kubectl](/docs/reference/generated/kubectl/kubectl-commands/#scale), +[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 @@ -309,22 +327,33 @@ 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 [`kubectl apply`] (/docs/reference/generated/kubectl/kubectl-commands/#apply) per inviare le modifiche alla configurazione nel cluster. +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à le modifiche che hai apportato, senza sovrascrivere le modifiche automatiche alle proprietà che non hai specificato. +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 $ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml 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 risorsa. +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 motivo, non li rimuoverà. +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 eseguire cancellazioni usando un tre via diff. +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 >}} To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`. @@ -338,7 +367,8 @@ 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 versione aggiornata: +Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la +versione aggiornata: ```shell $ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml @@ -349,9 +379,10 @@ 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 variabili di ambiente `EDITOR` o` KUBE_EDITOR`. +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). +Per ulteriori informazioni, consultare il documento [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit). ### kubectl patch @@ -364,9 +395,11 @@ 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 risorsa. In questo caso, puoi semplicemente modificare il tuo file di configurazione originale: +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 $ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force @@ -376,10 +409,13 @@ 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 operazioni di aggiornamento, ognuna delle quali è applicabile a diversi scenari. +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 [come usare `kubectl rolling-update`] (/docs/tasks/run-application/rolling-update-replication-controller/). +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: @@ -388,19 +424,23 @@ $ 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` a `nginx: 1.9.1`, con i comandi kubectl che abbiamo imparato sopra. +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 informazioni su di esso, visitare [Pagina di distribuzione] (/ docs / concepts / workloads / controller / deployment /). +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 %}} {{% capture whatsnext %}} -- [[Scopri come usare `kubectl` per l'introspezione e il debug delle applicazioni.] (/Docs/tasks/debug-application-cluster/debug-application-introspection/) -- [Best practice e suggerimenti sulla configurazione] (/docs/concepts/configuration/overview/) +- [[Scopri come usare `kubectl` per l'introspezione e il debug delle applicazioni.](/Docs/tasks/debug-application-cluster/debug-application-introspection/) +- [Best practice e suggerimenti sulla configurazione](/docs/concepts/configuration/overview/) {{% /capture %}} diff --git a/content/it/docs/concepts/cluster-administration/networking.md b/content/it/docs/concepts/cluster-administration/networking.md index c9c49d5707..697328535f 100644 --- a/content/it/docs/concepts/cluster-administration/networking.md +++ b/content/it/docs/concepts/cluster-administration/networking.md @@ -1,20 +1,18 @@ --- - title: Cluster Networking content_template: templates/concept weight: 50 --- {{% capture overview %}} -Il networking è una parte centrale di Kubernetes, ma può essere difficile -capire esattamente come dovrebbe funzionare. Ci sono 4 reti distinte -problemi da affrontare: +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 -    [pod] (/docs/concepts/workloads/pods/pod/) e comunicazioni `localhost`. +    [pod](/docs/concepts/workloads/pods/pod/) e comunicazioni `localhost`. 2. Comunicazioni Pod-to-Pod: questo è l'obiettivo principale di questo documento. -3. Comunicazioni Pod-to-Service: questo è coperto da [servizi] (/docs/concepts/services-networking/service/). -4. Comunicazioni da esterno a servizio: questo è coperto da [servizi] (/docs/concepts/services-networking/service/). +3. Comunicazioni Pod-to-Service: questo è coperto da [servizi](/docs/concepts/services-networking/service/). +4. Comunicazioni da esterno a servizio: questo è coperto da [servizi](/docs/concepts/services-networking/service/). {{% /capture %}} @@ -73,36 +71,46 @@ 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 esaustivo dei vari metodi, ma si spera che serva -come introduzione a varie tecnologie e serve da punto di partenza. +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. +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) 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. 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). +[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. +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 eliminare le interruzioni di rete riducendo al minimo i costi. +[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 controllo a grana fine sulle iniezioni di integrità del percorso (RHI) comuni in una distribuzione di Kubernetes. +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 cloud privati ​​e pubblici. +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 e un gran numero di sistemi white-box e sistemi operativi di rete aperti come Microsoft SONiC, Dell OPX e Cumulus Linux. +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/ ### Big Cloud Fabric da Big Switch Networks -[Big Cloud Fabric] (https://www.bigswitch.com/container-network-automation) è un'architettura di rete nativa cloud, progettata per eseguire Kubernetes in ambienti cloud privati ​​/ on-premise. Utilizzando un SDN fisico e virtuale unificato, Big Cloud Fabric affronta problemi intrinseci di rete di container come bilanciamento del carico, visibilità, risoluzione dei problemi, politiche di sicurezza e monitoraggio del traffico container. +[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) è un'architettura di rete nativa cloud, progettata per eseguire Kubernetes in ambienti cloud privati ​​/ on-premise. Utilizzando un SDN fisico e virtuale unificato, Big Cloud Fabric affronta problemi intrinseci di rete di container come bilanciamento del carico, visibilità, risoluzione dei problemi, politiche di sicurezza e monitoraggio del traffico container. Con l'aiuto dell'architettura multi-tenant del pod virtuale di Big Cloud Fabric, i sistemi di orchestrazione di container come Kubernetes, RedHat OpenShift, Mesosphere DC / OS e Docker Swarm saranno integrati nativamente con i sistemi di orchestrazione VM come VMware, OpenStack e Nutanix. I clienti saranno in grado di interconnettere in modo sicuro qualsiasi numero di questi cluster e abilitare la comunicazione tra i titolari, se necessario. -BCF è stato riconosciuto da Gartner come un visionario nell'ultimo [Magic Quadrant] (http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). Viene anche fatto riferimento a una delle distribuzioni on-premises BCF Kubernetes (che include Kubernetes, DC / OS e VMware in esecuzione su più DC in diverse regioni geografiche) [https://portworx.com/architects-corner-kubernetes-satya -komala-nio /). +BCF è stato riconosciuto da Gartner come un visionario nell'ultimo [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). Viene anche fatto riferimento a una delle distribuzioni on-premises BCF Kubernetes (che include Kubernetes, DC / OS e VMware in esecuzione su più DC in diverse regioni geografiche) [https://portworx.com/architects-corner-kubernetes-satya -komala-nio /). ### Cilium [Cilium](https://github.com/cilium/cilium) è un software open source per @@ -113,9 +121,14 @@ 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/), [Romana] (http://romana.io), [Weave-net] (https://www.weave.works/products/ tessere-net /). +[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. +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. ### cni-ipvlan-vpc-k8s [cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contiene un set @@ -138,15 +151,20 @@ 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, overlay usando vxlan, classic l2 o Cisco-SDN / ACI) per vari casi d'uso. [Contiv] (http://contiv.io) è tutto aperto. +[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 per macchine virtuali, contenitori / pod e carichi di lavoro bare metal. +[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 -[DANM] (https://github.com/nokia/danm) è una soluzione di rete per carichi di lavoro di telco in esecuzione in un cluster Kubernetes. È costituito dai seguenti componenti: +[DANM](https://github.com/nokia/danm) è una soluzione di rete per carichi di lavoro di telco in esecuzione in un cluster Kubernetes. È costituito dai seguenti componenti: * Un plugin CNI in grado di fornire interfacce IPVLAN con funzionalità avanzate     * Un modulo IPAM integrato con la capacità di gestire reti L3 multiple, a livello di cluster e discontinue e fornire uno schema di allocazione IP dinamico, statico o nullo su richiesta @@ -155,20 +173,19 @@ complessità della rete richiesta per implementare Kubernetes su larga scala all     * Un altro controller di Kubernetes che estende il concetto di rilevamento dei servizi basato sui servizi di Kubernetes per funzionare su tutte le interfacce di rete di un pod Con questo set di strumenti DANM è in grado di fornire più interfacce di rete separate, la possibilità di utilizzare diversi back-end di rete e funzionalità IPAM avanzate per i pod. + ### Flannel -[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. +[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 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 +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. Docker è avviato con: @@ -177,18 +194,14 @@ Docker è avviato con: 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`. +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 ponte` cbr0`. Questi IP sono tutti instradabili -all'interno della rete del progetto GCE. +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) traffico che è vincolato per IP al di fuori della rete del progetto GCE -(10.0.0.0/8). +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 iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE @@ -206,17 +219,26 @@ 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 IP per pod. +[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, la migrazione degli indirizzi IP, ecc. +[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 della politica di rete basato su iptables / ipset. +[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 @@ -227,29 +249,51 @@ lavoro, ma non è stato testato a fondo. Se usi questa tecnica e perfezionare il processo, fatecelo sapere. Segui la sezione "Con dispositivi Linux Bridge" di [questo molto bello -tutorial] (http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) da +tutorial](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) da 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 Networking in Kubernetes utilizzando oggetti di rete basati su CRD in Kubernetes. +[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 +cloud native e basate su NFV 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 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 agli hypervisor vSphere, questi ambienti includono altri hypervisor come KVM, container e bare metal. +[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 CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. +[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 funzionalità basato su standard aperti. +[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 sicurezza per le applicazioni Kubernetes. +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 -[OpenVSwitch] (https://www.openvswitch.org/) è un po 'più maturo ma anche +[OpenVSwitch](https://www.openvswitch.org/) è un po 'più maturo ma anche modo complicato per costruire una rete di sovrapposizione. Questo è approvato da molti dei "Grandi negozi" per il networking. @@ -259,34 +303,41 @@ OVN è una soluzione di virtualizzazione della rete opensource sviluppata da Apri la community di vSwitch. Permette di creare switch logici, router logici, ACL di stato, bilanciamento del carico ecc. per costruire reti virtuali diverse topologie. Il progetto ha un plugin e una documentazione specifici per Kubernetes -a [ovn-kubernetes] (https://github.com/openvswitch/ovn-kubernetes). +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 motore di criteri di rete. +[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 rete basata su intere grane per i pod Kubernetes tramite il firewall distribuito. +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 Flannel, alias [canal] (https://github.com/tigera/canal) o native GCE, AWS o networking Azure. +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 di rete. +[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 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 entrambi i casi, la rete fornisce un indirizzo IP per pod, come è standard per Kubernetes. +[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 +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 dettaglio nella [progettazione della rete -documento] (https://git.k8s.io/community/contributors/design-proposals/network/networking.md). +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/docs/concepts/cluster-administration/proxies.md b/content/it/docs/concepts/cluster-administration/proxies.md index 5789de393a..62a097d096 100644 --- a/content/it/docs/concepts/cluster-administration/proxies.md +++ b/content/it/docs/concepts/cluster-administration/proxies.md @@ -15,7 +15,7 @@ Questa pagina spiega i proxy utilizzati con Kubernetes. Esistono diversi proxy che puoi incontrare quando usi Kubernetes: -1. Il [proxy kubectl] (/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api): +1. Il [proxy kubectl](/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api):     - Funziona sul desktop di un utente o in un pod     - proxy da un indirizzo localhost all'apiserver di Kubernetes @@ -24,7 +24,7 @@ Esistono diversi proxy che puoi incontrare quando usi Kubernetes:     - individua l'apiserver     - Aggiunge le intestazioni di autenticazione -1. Il [proxy apiserver] (/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): +1. Il [proxy apiserver](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):     - è un bastione costruito nell'apiserver     - collega un utente al di fuori del cluster agli IP del cluster che altrimenti potrebbero non essere raggiungibili @@ -34,7 +34,7 @@ Esistono diversi proxy che puoi incontrare quando usi Kubernetes:     - può essere utilizzato per raggiungere un nodo, un pod o un servizio     - esegue il bilanciamento del carico quando viene utilizzato per raggiungere un servizio -1. Il [kube proxy] (/docs/concepts/services-networking/service/#ips-and-vips): +1. Il [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):     - Funziona su ciascun nodo     - proxy UDP, TCP e SCTP diff --git a/content/it/docs/concepts/overview/what-is-kubernetes.md b/content/it/docs/concepts/overview/what-is-kubernetes.md index a330045dc4..e4c5a1c6dc 100644 --- a/content/it/docs/concepts/overview/what-is-kubernetes.md +++ b/content/it/docs/concepts/overview/what-is-kubernetes.md @@ -144,7 +144,7 @@ Riepilogo dei vantaggi del contenitore: ## Cosa significa Kubernetes? K8S? Il nome **Kubernetes** deriva dal greco, che significa *timoniere* o *pilota*, ed è la radice del *governatore* -e del [cibernetico] (http://www.etymonline.com/index.php?term=cybernetics). *K8s* +e del [cibernetico](http://www.etymonline.com/index.php?term=cybernetics). *K8s* è un'abbreviazione derivata sostituendo le 8 lettere "ubernete" con "8". {{% /capture %}} diff --git a/content/it/includes/federation-deprecation-warning-note.md b/content/it/includes/federation-deprecation-warning-note.md index 65c54ca01c..96793fafe1 100644 --- a/content/it/includes/federation-deprecation-warning-note.md +++ b/content/it/includes/federation-deprecation-warning-note.md @@ -1,3 +1,5 @@ -L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` mai raggiunto lo stato GA e non è più in fase di sviluppo attivo. La documentazione è solo per scopi storici. +L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` mai raggiunto lo stato GA e non è più in +fase di sviluppo attivo. La documentazione è solo per scopi storici. -Per ulteriori informazioni, consultare la sostituzione prevista, [Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2). +Per ulteriori informazioni, consultare la sostituzione prevista, +[Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2).