review componentes page and related overview pages
Michele Buccarello
parent
bcb1e41ac0
commit
96bd525840
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
„---
|
||||
title: I componenti di Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
|
|
@ -9,9 +9,9 @@ card:
|
|||
|
||||
{{% capture overview %}}
|
||||
Facendo il deployment di Kubernetes, ottieni un cluster.
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="Un cluster è">}}
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="Un cluster Kubernetes è">}}
|
||||
|
||||
Questo documento describe i diversi componenti che sono necessari per avere
|
||||
Questo documento descrive i diversi componenti che sono necessari per avere
|
||||
un cluster Kubernetes completo e funzionante.
|
||||
|
||||
Questo è un diagramma di un cluster Kubernetes con tutti i componenti e le loro relazioni.
|
||||
|
|
@ -23,9 +23,9 @@ Questo è un diagramma di un cluster Kubernetes con tutti i componenti e le loro
|
|||
{{% capture body %}}
|
||||
## Componenti della Control Plane
|
||||
|
||||
La Control Plane è responsabile di tutte le decisioni globali sul cluster (ad esempio, lo scheduling), e l'individuazione e la risposta ad eventi derivanti dal cluster (ad esempio, l'avvio di un nuovo {{< glossary_tooltip text="pod" term_id="pod">}} quando il valore `replicas` di un deployment non è soddisfatto).
|
||||
I componenti del Control Plane sono responsabili di tutte le decisioni globali sul cluster (ad esempio, lo scheduling) oltre che a rilevare e rispondere agli eventi del cluster (ad esempio, l'avvio di un nuovo {{< glossary_tooltip text="pod" term_id="pod">}} quando il valore `replicas` di un deployment non è soddisfatto).
|
||||
|
||||
I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster, ma solitamente gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell'utente.
|
||||
I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster stesso. Solitamente, per semplicità, gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell'utente.
|
||||
Vedi [creare un cluster in High-Availability](/docs/admin/high-availability/) per un esempio di un'installazione multi-master.
|
||||
|
||||
### kube-apiserver
|
||||
|
|
@ -53,27 +53,25 @@ Alcuni esempi di controller gestiti dal kube-controller-manager sono:
|
|||
|
||||
### cloud-controller-manager
|
||||
|
||||
Il [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) esegue i controller che interagiscono con i cloud provider responsabili per la gestione dell'infrastruttura sottostante al cluster, in caso di deployment in cloud.
|
||||
Il cloud-controller-manager è una funzionalità alpha introdotta in Kubernetes 1.6.
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
|
||||
|
||||
Il cloud-controller-manager esegue esclusivamente i cicli di controllo specifici dei cloud provider.
|
||||
È possibile disabilitare questi cicli di controllo usando il kube-controller-manager.
|
||||
È inoltre possibile disabilitare i cicli di controllo settando il parametro `--cloud-provider` con il valore `external` durante l'esecuzione del kube-controller-manager.
|
||||
Il cloud-controller-manager esegue dei controller specifici del tuo cloud provider.
|
||||
Se hai una installazione Kubernetes on premises, o un ambiente di laboratorio
|
||||
nel tuo PC, il cluster non ha un cloud-controller-manager.
|
||||
|
||||
Il cloud-controller-manager permette l'evoluzione indipendente al codice di Kubernetes e a quello dei singoli cloud vendor.
|
||||
Precedentemente, il codice core di Kubernetes dipendeva da implementazioni specifiche dei cloud provider.
|
||||
In futuro, implementazioni specifiche per singoli cloud provider devono essere mantenuti dai cloud provider interessati e collegati al cloud-controller-manager.
|
||||
Come nel kube-controller-manager, il cloud-controller-manager combina diversi control loop
|
||||
logicamente indipendenti in un singolo binario che puoi eseguire come un singolo processo. Tu puoi
|
||||
scalare orizzontalmente (eseguire più di una copia) per migliorare la responsività o per migliorare la tolleranza ai fallimenti.
|
||||
|
||||
I seguenti controller hanno dipendenze verso implementazioni di specifici cloud provider:
|
||||
|
||||
* Node Controller: Per controllare se sul cloud provider i nodi che hanno smesso di rispondere sono stati cancellati
|
||||
* Route Controller: Per configurare le regole di route nella sottostante infrastruttura cloud
|
||||
* Service Controller: Per creare, aggiornare ed eliminare i load balancer nella infrastruttura del cloud provider
|
||||
* Volume Controller: Per creare, associare e montare i volumi e per interagire con il cloud provider per orchestrare i volumi
|
||||
|
||||
* Route Controller: Per configurare le network route nella sottostante infrastruttura cloud
|
||||
* Service Controller: Per creare, aggiornare ed eliminare i load balancer del cloud provider
|
||||
|
||||
## Componenti dei Nodi
|
||||
|
||||
I componenti di Kubernetes che girano sui Worker Node sono responsabili dell'esecuzione dei workload degli utenti.
|
||||
I componenti del nodo vengono eseguiti su ogni nodo, mantenendo i pod in esecuzione e fornendo l'ambiente di runtime Kubernetes.
|
||||
|
||||
### kubelet
|
||||
|
||||
|
|
@ -89,10 +87,10 @@ I componenti di Kubernetes che girano sui Worker Node sono responsabili dell'ese
|
|||
|
||||
## Addons
|
||||
|
||||
Gli Addons usano le risorse Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) per implementare nuove funzionalità a livello di cluster.
|
||||
Gli Addons usano le risorse Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) per implementare funzionalità di cluster.
|
||||
Dal momento che gli addons forniscono funzionalità a livello di cluster, le risorse che necessitano di un namespace, vengono collocate nel namespace `kube-system`.
|
||||
|
||||
Alcuni addons sono descritti di seguito; mentre per una più estesa lista di addons, riferirsi ad [Addons](/docs/concepts/cluster-administration/addons/).
|
||||
Alcuni addons sono descritti di seguito; mentre per una più estesa lista di addons, per favore vedere [Addons](/docs/concepts/cluster-administration/addons/).
|
||||
|
||||
### DNS
|
||||
|
||||
|
|
@ -100,7 +98,7 @@ Mentre gli altri addons non sono strettamente richiesti, tutti i cluster Kuberne
|
|||
|
||||
Il DNS del cluster è un server DNS aggiuntivo rispetto ad altri server DNS presenti nella rete, e si occupa specificatamente dei record DNS per i servizi Kubernetes.
|
||||
|
||||
I container eseguiti da Kubernetes possono utilizzare questo server per la risoluzione DNS.
|
||||
I container eseguiti da Kubernetes automaticamente usano questo server per la risoluzione DNS.
|
||||
|
||||
### Interfaccia web (Dashboard)
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
title: Cloud Controller Manager
|
||||
id: cloud-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/cloud-controller/
|
||||
short_description: >
|
||||
Componente della control plane che integra Kubernetes con cloud providers di terze parti.
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- architecture
|
||||
- operation
|
||||
---
|
||||
Un componente della {{< glossary_tooltip text="control plane" term_id="control-plane" >}} di Kubernetes
|
||||
che aggiunge logiche di controllo specifiche per il cloud. Il cloud-controller-manager ti permette di collegare il tuo
|
||||
cluster con le API del cloud provider e separa le componenti che interagiscono
|
||||
con la piattaforma cloud dai componenti che interagiscono solamente col cluster.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Disaccoppiando la logica di interoperabilità tra Kubernetes e l'infrastruttura cloud sottostante,
|
||||
il componente cloud-controller-manager abilità i cloud provider di rilasciare
|
||||
funzionalità a un ritmo diverso rispetto al progetto principale Kubernetes.
|
||||
|
||||
|
|
@ -4,14 +4,14 @@ 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.
|
||||
Un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker 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.
|
||||
Un'insieme di macchine, chiamate nodi, che eseguono container gestiti da Kubernetes. Un cluster ha almeno un Worker 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,19 @@
|
|||
---
|
||||
title: Container
|
||||
id: container
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
short_description: >
|
||||
Una immagine leggera, portabile ed eseguibile che contiene un software e tutte le sue dipendenze.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
Una immagine leggera, portabile ed eseguibile che contiene un software e tutte le sue dipendenze.
|
||||
|
||||
<!--more-->
|
||||
|
||||
I ontainer disaccoppiano le applicazione dall'infrastruttura host sottostante e rendono semplice il deploy nei differenti cloud o sistemi operativi e anche per una semplice scalabilità
|
||||
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: Control Plane
|
||||
id: control-plane
|
||||
date: 2019-05-12
|
||||
full_link:
|
||||
short_description: >
|
||||
Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.
|
||||
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Lo strato per l'orchestrazione dei container che espone le API e interfaccie per definere, deploy, e gestione del ciclo di vita dei container.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Questo strato è composto da diversi componenti, come (ma non limitato a):
|
||||
|
||||
* {{< glossary_tooltip text="etcd" term_id="etcd" >}}
|
||||
* {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
|
||||
* {{< glossary_tooltip text="Scheduler" term_id="kube-scheduler" >}}
|
||||
* {{< glossary_tooltip text="Controller Manager" term_id="kube-controller-manager" >}}
|
||||
* {{< glossary_tooltip text="Cloud Controller Manager" term_id="cloud-controller-manager" >}}
|
||||
|
||||
Questi compenti possono girare come trazionali servizi del sistema operativo (demoni) o come containers. L'host che esegue questi componenti era storicamente chiamato {{< glossary_tooltip text="master" term_id="master" >}}.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Container runtime interface (CRI)
|
||||
id: cri
|
||||
date: 2019-03-07
|
||||
full_link: /docs/concepts/overview/components/#container-runtime
|
||||
short_description: >
|
||||
Una API per i container runtimes che si integra con la kubelet
|
||||
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Il container runtime interface (CRI) è una API per container runtimes
|
||||
che si integra con la kubelet in un node.
|
||||
<!--more-->
|
||||
|
||||
Per maggiori informazioni, guarda [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) API e relative specifiche.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: DaemonSet
|
||||
id: daemonset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/daemonset
|
||||
short_description: >
|
||||
Assicura che una copia di un Pod è attiva su tutti nodi di un cluster.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
Assicura che una copia del {{< glossary_tooltip text="Pod" term_id="pod" >}} è attiva su tutti nodi di un {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Utilizzato per il deploy di demoni di sistema come collettori di log e agenti di monitoraggio che tipicamente girano in ogni {{< glossary_tooltip term_id="node" >}}.
|
||||
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Deployment
|
||||
id: deployment
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/deployment/
|
||||
short_description: >
|
||||
Gestisce una applicazione replicata nel tuo cluster.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
Un oggetto API che gestisce un'applicazione replicatata, tipicamente esegue Pod senza stato locale.
|
||||
|
||||
<!--more-->
|
||||
Ogni replica è rappresentata da un {{< glossary_tooltip term_id="pod" >}}, e i Pod sono distribuiti attraverso i
|
||||
{{< glossary_tooltip text="nodi" term_id="node" >}} di un cluster.
|
||||
Per i carichi di lavoro che hanno bisogno di uno stato locale, cosidera l'utilizzo di un {{< glossary_tooltip term_id="StatefulSet" >}}.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Docker
|
||||
id: docker
|
||||
date: 2018-04-12
|
||||
full_link: https://docs.docker.com/engine/
|
||||
short_description: >
|
||||
Docker è una technologia software che offre una virtualizzazione a livello del sistema operativo nota come container.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Docker (nello specifico, Docker Engine) è una technologia software che offre una virtualizzazione a livello del sistema operativo nota come {{< glossary_tooltip text="container" term_id="container" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Docker utilizza delle funzionalità di isolamente del kernel Linux come cgroups e kernel namespaces e un file system union-capable come OverlayFS e altro permettendo a container indipendenti di girare all'interno di una singola istanza Linux, eliminando il sovraccarico nell'avviare e manutenere delle virtual machines (VMs).
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: Kubeadm
|
||||
id: kubeadm
|
||||
date: 2018-04-12
|
||||
full_link: /docs/admin/kubeadm/
|
||||
short_description: >
|
||||
Un tool per installare velocemente Kubernetes e avviare un cluster sicuro.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
---
|
||||
Un tool per installare velocemente Kubernetes e avviare un cluster sicuro.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Puoi usare kubeadm per installare sia la control plane che il {{< glossary_tooltip text="worker node" term_id="node" >}}.
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Label
|
||||
id: label
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/overview/working-with-objects/labels
|
||||
short_description: >
|
||||
Tags di oggetti con attributi identificativi che sono significativi e pertinenti per gli utenti.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Tags di oggetti con attributi identificativi che sono significativi e pertinenti per gli utenti.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Le label sono delle coppie key/value che sono collegate a oggetti come {{< glossary_tooltip text="Pod" term_id="pod" >}}. Esse sono usate per organizzare e selezionare un sottoinsieme di oggetti.
|
||||
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
title: Master
|
||||
id: master
|
||||
date: 2020-04-16
|
||||
short_description: >
|
||||
Termine vecchio, usato come sinonimo per i nodi che ospitano la control plane.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Termine vecchio, usato come sinonimo per i {{< glossary_tooltip text="nodi" term_id="node" >}} che ospitano la {{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
|
||||
|
||||
<!--more-->
|
||||
Il termine è ancora usato da alcuni strumenti di provisioning, come {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}}, e servizi gestiti, per mettere la {{< glossary_tooltip text="label" term_id="label" >}} `kubernetes.io/role` ai {{< glossary_tooltip text="nodi" term_id="node" >}} per controllare il posizionamento dei {{< glossary_tooltip text="pods" term_id="pod" >}} della {{< glossary_tooltip text="control plane" term_id="control-plane" >}} .
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: Node
|
||||
id: node
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/architecture/nodes/
|
||||
short_description: >
|
||||
Un node è una macchina worker in Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Un node è una macchina worker in Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Un worker node può essere una VM o una macchina fisica, in base al cluster. Possiede daemon locali o servizi ncessari a eseguire {{< glossary_tooltip text="Pods" term_id="pod" >}} e viene gestito dalla control plane. I deamon i un node includono {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, e un container runtiome che implementa {{< glossary_tooltip text="CRI" term_id="cri" >}} come ad esempio {{< glossary_tooltip term_id="docker" >}}.
|
||||
|
||||
Nelle prime versioni di Kubernetes, i Node venivano chiamati "Minions".
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: Pod
|
||||
id: pod
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/pods/pod-overview/
|
||||
short_description: >
|
||||
Un Pod rappresenta un gruppo di container nel tuo cluster.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
Il più piccolo e semplice oggetto in Kubernetes. Un pod rappresenta un gruppo di {{< glossary_tooltip text="container" term_id="container" >}} nel tuo cluster.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Un pod è tipicamente progettato per eseguire un singolo container primario. Può opzionalmente eseguire sidecar container che aggiungono funzionalità supplementari come logging. I Pod sono generalmetne gestiti da un {{< glossary_tooltip term_id="deployment" >}}.
|
||||
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: StatefulSet
|
||||
id: statefulset
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
Gestisce deployment e la scalabilità di un gruppo di Pod, con storage e identificativi persistenti per ogni Pod.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
- storage
|
||||
---
|
||||
Gestisce deployment e la scalabilità di un gruppo di {{< glossary_tooltip text="Pods" term_id="pod" >}}, *e garantisce il corretto ordine e unicità* di questi Pods.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Come un {{< glossary_tooltip term_id="deployment" >}}, uno StatefulSet gestisce Pod che sono basati sulla stessa specifica di container. Contrariamente da un Deployment, uno StatefulSet mantiente una specifica identita per ogni Pod. Questi pod sono creati dalla stessa specifica, ma non sono intercambiabili: ogni pod a un identificativo persistente che si mantiene attraverso ogni rischedulazione.
|
||||
|
||||
Se vuoi usare un volume dello storage per avere la persistenza per il tuo carico di lavoro, puoi usare uno StatefulSet come parte della tua soluzione. Anche se i singoli Pod in uno StatefulSet sono suscettibili al fallimento, l'identificativo persistente del Pod rende semplice il collegamento dei volumi esistenti ai nuovi Pods che sostituiscono quelli falliti.
|
||||
Loading…
Reference in New Issue