Add IT localization for overview/components/ (#18368)

* begin the real work

* rollback set of changes

* translate components and required glossary items

* improve many aspects thanks to the comments in the pr thread
This commit is contained in:
Fabio Alessandro Locati
2020-01-21 11:07:37 +01:00
committed by Kubernetes Prow Robot
parent 54bf3977fe
commit a0325251ab
12 changed files with 344 additions and 3 deletions
+17
View File
@@ -0,0 +1,17 @@
---
title: Cluster
id: cluster
date: 2019-06-15
full_link:
short_description: >
Un'insieme di macchine, chiamate nodi, che eseguono container e gestite da Kubernetes. Un cluster ha almeno un Worker Node e un Control Plane Node.
aka:
tags:
- fundamental
- operation
---
Un'insieme di macchine, chiamate nodi, che eseguono container e gestite da Kubernetes. Un cluster ha almeno un Worker Node e un Control Plane Node.
<!--more-->
Il/I Worker Node ospitano i Pod che eseguono i workload dell'utente. Il/I Control Plane Node gestiscono i Worker Node e tutto quanto accade all'interno del cluster. Per garantire la high-availability e la possibilità di failover del cluster, vengono utilizzati più Control Plane Node.
@@ -0,0 +1,21 @@
---
title: Container Runtime
id: container-runtime
date: 2019-06-05
full_link: /docs/reference/generated/container-runtime
short_description: >
Il container runtime è il software che è responsabile per l'esecuzione dei container.
aka:
tags:
- fundamental
- workload
---
Il container runtime è il software che è responsabile per l'esecuzione dei container.
<!--more-->
Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com),
[containerd](https://containerd.io), [cri-o](https://cri-o.io/),
[rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di
[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
+21
View File
@@ -0,0 +1,21 @@
---
title: etcd
id: etcd
date: 2018-04-12
full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
short_description: >
È un database key-value altamente disponibile che è usato da Kubernetes per salvare tutte le informazioni del cluster.
aka:
tags:
- architecture
- storage
---
È un database key-value ridondato, che è usato da Kubernetes per salvare tutte le informazioni del cluster.
<!--more-->
Se il tuo cluster utilizza etcd per salvare le informazioni, assicurati di
avere una strategia di [backup](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) per questi dati.
Puoi trovare informazioni dettagliate su etcd sulla [documentazione](https://etcd.io/docs/) ufficiale.
+23
View File
@@ -0,0 +1,23 @@
---
title: API server
id: kube-apiserver
date: 2018-04-12
full_link: /docs/reference/generated/kube-apiserver/
short_description: >
Componente della Control plane che serve le Kubernetes API.
aka:
- kube-apiserver
tags:
- architecture
- fundamental
---
L'API server è un componente di Kubernetes
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} che espone le Kubernetes API.
L'API server è il front end del control plane di Kubernetes.
<!--more-->
La principale implementazione di un server Kubernetes API è [kube-apiserver](/docs/reference/generated/kube-apiserver/).
kube-apiserver è progettato per scalare orizzontalmente, cioè scala aumentando il numero di istanze.
Puoi eseguire multiple istanze di kube-apiserver e bilanciare il traffico tra queste istanze.
@@ -0,0 +1,18 @@
---
title: kube-controller-manager
id: kube-controller-manager
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
short_description: >
Componente della Control Plane che gestisce i controller.
aka:
tags:
- architecture
- fundamental
---
Componente della Control Plane che gestisce {{< glossary_tooltip text="controllers" term_id="controller" >}}.
<!--more-->
Da un punto di vista logico, ogni {{< glossary_tooltip text="controller" term_id="controller" >}} è un processo separato, ma per ridurre la complessità, tutti i principali controller di Kubernetes vengono raggruppati in un unico container ed eseguiti in un singolo processo.
+23
View File
@@ -0,0 +1,23 @@
---
title: kube-proxy
id: kube-proxy
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
short_description: >
`kube-proxy` è un proxy eseguito su ogni nodo del cluster.
aka:
tags:
- fundamental
- networking
---
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) è un
proxy eseguito su ogni nodo del cluster, responsabile della gestione dei
Kubernetes {{< glossary_tooltip term_id="service">}}.
<!--more-->
I kube-proxy mantengono le regole di networking sui nodi.
Queste regole permettono la comunicazione verso gli altri nodi del cluster o l'esterno.
Il kube-proxy usa le librerie del sistema operativo quando possible; in caso contrario il kube-proxy gestisce il traffico direttamente.
+18
View File
@@ -0,0 +1,18 @@
---
title: kube-scheduler
id: kube-scheduler
date: 2018-04-12
full_link: /docs/reference/generated/kube-scheduler/
short_description: >
Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna.
aka:
tags:
- architecture
---
Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna.
<!--more-->
I fattori presi in considerazioni nell'individuare un nodo a cui assegnare l'esecuzione di un Pod includono la richiesta di risorse del Pod stesso e degli altri workload presenti nel sistema, i vincoli delle hardware/software/policy, le indicazioni di affinity e di anti-affinity, requisiti relativi alla disponibilità di dati/Volumes, le interferenze tra diversi workload e le scadenze.
+19
View File
@@ -0,0 +1,19 @@
---
title: Kubelet
id: kubelet
date: 2018-04-12
full_link: /docs/reference/generated/kubelet
short_description: >
Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.
aka:
tags:
- fundamental
- core-object
---
Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.
<!--more-->
La kubelet riceve un set di PodSpecs che vengono forniti attraverso vari meccanismi, e si assicura che i container descritti in questi PodSpecs funzionino correttamente e siano sani. La kubelet non gestisce i container che non sono stati creati da Kubernetes.