diff --git a/content/it/docs/concepts/configuration/_index.md b/content/it/docs/concepts/configuration/_index.md
new file mode 100644
index 0000000000..4ec8154b58
--- /dev/null
+++ b/content/it/docs/concepts/configuration/_index.md
@@ -0,0 +1,6 @@
+---
+title: "Configurazione"
+weight: 80
+description: >
+ Risorse che fornisce Kubernetes per configurare i Pods.
+---
\ No newline at end of file
diff --git a/content/it/docs/concepts/configuration/configmap.md b/content/it/docs/concepts/configuration/configmap.md
new file mode 100644
index 0000000000..35e1ca4147
--- /dev/null
+++ b/content/it/docs/concepts/configuration/configmap.md
@@ -0,0 +1,250 @@
+---
+title: ConfigMaps
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+{{< glossary_definition term_id="configmap" prepend="La ConfigMap è" length="all" >}}
+
+{{< caution >}}
+La ConfigMap non fornisce riservatezza o cifratura dei dati. Se i dati che vuoi salvare sono confidenziali, usa un {{< glossary_tooltip text="Secret" term_id="secret" >}} piuttosto che una ConfigMap, o usa uno strumento di terze parti per tenere privati i tuoi dati.
+{{< /caution >}}
+
+<!-- body -->
+## Utilizzo
+
+Usa una ConfigMap per tenere separati i dati di configurazione dal codice applicativo.
+
+Per esempio, immagina che stai sviluppando un'applicazione che puoi eseguire sul tuo computer (per lo sviluppo) e sul cloud (per gestire il traffico reale). Puoi scrivere il codice puntando a una variabile d'ambiente chiamata `DATABASE_HOST`. Localmente, puoi settare quella variabile a `localhost`. Nel cloud, la puoi settare referenziando il {{< glossary_tooltip text="Service" term_id="service" >}} di Kubernetes che espone la componente del database sul tuo cluster. Ciò ti permette di andare a recuperare l'immagine del container eseguita nel cloud e fare il debug dello stesso codice localmente se necessario.
+
+La ConfigMap non è pensata per sostenere una gran mole di dati. I dati memorizzati su una ConfigMap non possono superare 1 MiB. Se hai bisogno di memorizzare delle configurazioni che superano questo limite, puoi considerare di montare un volume oppure usare un database o un file service separato.
+
+
+## Oggetto ConfigMap
+
+La ConfigMap è un [oggetto](/docs/concepts/overview/working-with-objects/kubernetes-objects/) API che ti permette di salvare configurazioni per poi poter essere riutilizzate da altri oggetti. A differenza di molti oggetti di Kubernetes che hanno una `spec`, la ConfigMap ha i campi `data` e `binaryData`. Questi campi accettano le coppie chiave-valore come valori. Entrambi i campi `data` e `binaryData` sono opzionali. Il campo `data` è pensato per contenere le stringhe UTF-8 mentre il campo `binaryData` è pensato per contenere dati binari come le stringhe codificate in base64.
+
+Il nome di una ConfigMap deve essere un nome valido per un sottodominio DNS.
+
+Ogni chiave sotto il campo `data` o `binaryData` deve consistere di caratteri alfanumerici, `-`, `_` o `.`. Le chiavi salvate sotto `data` non devono coincidere con le chiavi nel campo `binaryData`.
+
+Partendo dalla versione 1.19, puoi aggiungere il campo `immutable` alla definizione di ConfigMap per creare una [ConfigMap immutabile](#configmap-immutable).
+
+## ConfigMaps e Pods
+
+Puoi scrivere una `spec` del Pod che si riferisce a una ConfigMap e configurare il o i containers
+in quel Pod sulla base dei dati presenti nella ConfigMap. Il Pod e la ConfigMap devono essere nello
+stesso Namespace.
+
+{{< note >}}
+La `spec` di un {{< glossary_tooltip text="Pod statico" term_id="static-pod" >}} non può riferirsi a una ConfigMap
+o ad altri oggetti API.
+{{< /note >}}
+
+Questo è un esempio di una ConfigMap che ha alcune chiavi con valori semplici,
+e altre chiavi dove il valore ha il formato di un frammento di configurazione.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: game-demo
+data:
+ # chiavi simili a proprietà; ogni chiave mappa un valore semplice
+ player_initial_lives: "3"
+ ui_properties_file_name: "user-interface.properties"
+
+ # chiavi simili a files
+ game.properties: |
+ enemy.types=aliens,monsters
+ player.maximum-lives=5
+ user-interface.properties: |
+ color.good=purple
+ color.bad=yellow
+ allow.textmode=true
+```
+
+Ci sono quattro modi differenti con cui puoi usare una ConfigMap per configurare
+un container all'interno di un Pod:
+
+1. Argomento da riga di comando come entrypoint di un container
+1. Variabile d'ambiente di un container
+1. Aggiungere un file in un volume di sola lettura, per fare in modo che l'applicazione lo legga
+1. Scrivere il codice da eseguire all'interno del Pod che utilizza l'API di Kubernetes per leggere la ConfigMap
+
+Questi metodologie differenti permettono di utilizzare diversi metodi per modellare i dati che saranno consumati.
+Per i primi tre metodi, il
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utilizza i dati della
+ConfigMap quando lancia il container (o più) in un Pod.
+
+Per il quarto metodo dovrai scrivere il codice per leggere la ConfigMap e i suoi dati.
+Comunque, poiché stai utilizzando l'API di Kubernetes direttamente, la tua applicazione può
+sottoscriversi per ottenere aggiornamenti ogniqualvolta la ConfigMap cambia, e reagire
+quando ciò accade. Accedendo direttamente all'API di Kubernetes, questa
+tecnica ti permette anche di accedere a una ConfigMap in namespace differenti.
+
+Ecco un esempio di Pod che usa i valori da `game-demo` per configurare il container:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: configmap-demo-pod
+spec:
+ containers:
+ - name: demo
+ image: alpine
+ command: ["sleep", "3600"]
+ env:
+ # Definire la variabile d'ambiente
+ - name: PLAYER_INITIAL_LIVES # Notare che il case qui è differente
+ # dal nome della key nella ConfigMap.
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo # La ConfigMap da cui proviene il valore.
+ key: player_initial_lives # La chiave da recuperare.
+ - name: UI_PROPERTIES_FILE_NAME
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo
+ key: ui_properties_file_name
+ volumeMounts:
+ - name: config
+ mountPath: "/config"
+ readOnly: true
+ volumes:
+ # Settare i volumi al livello del Pod, in seguito montarli nei containers all'interno del Pod
+ - name: config
+ configMap:
+ # Fornire il nome della ConfigMap che vuoi montare.
+ name: game-demo
+ # Una lista di chiavi dalla ConfigMap per essere creata come file
+ items:
+ - key: "game.properties"
+ path: "game.properties"
+ - key: "user-interface.properties"
+ path: "user-interface.properties"
+```
+
+Una ConfigMap non differenzia tra le proprietà di una singola linea e un file con più linee e valori.
+L'importante è il modo in cui i Pods e gli altri oggetti consumano questi valori.
+
+Per questo esempio, definire un volume e montarlo all'interno del container `demo` come `/config` crea
+due files,
+`/config/game.properties` e `/config/user-interface.properties`,
+sebbene ci siano quattro chiavi nella ConfigMap. Ciò avviene perché la definizione del Pod
+specifica una lista di `items` nella sezione dei `volumes`.
+Se ometti del tutto la lista degli `items`, ogni chiave nella ConfigMap diventerà
+un file con lo stesso nome della chiave, e otterrai 4 files.
+
+## Usare le ConfigMaps
+
+Le ConfigMaps possono essere montate come volumi. Le ConfigMaps possono anche essere utilizzate da
+altre parti del sistema, senza essere direttamente esposte al Pod. Per esempio, le
+ConfigMaps possono contenere l'informazione che altre parti del sistema utilizzeranno per la loro
+configurazione.
+
+La maniera più comune per usare le ConfigMaps è di configurare i containers che sono in esecuzione
+in un Pod nello stesso namespace. Puoi anche utilizzare una ConfigMap separatamente.
+
+Per esempio, potresti incontrare
+ {{< glossary_tooltip text="addons" term_id="addons" >}}
+o {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} che
+adattano il loro comportamento in base a una ConfigMap.
+
+### Usare le ConfigMaps come files in un Pod
+
+Per utilizzare una ConfigMap in un volume all'interno di un Pod:
+
+1. Creare una ConfigMap o usarne una che già esiste. Più Pods possono utilizzare
+ la stessa ConfigMap.
+1. Modificare la definizione del Pod per aggiungere un volume sotto `.spec.volumes[]`. Nominare
+ il volume in qualsiasi modo, e avere un campo `.spec.volumes[].configMap.name` configurato per
+ referenziare il tuo oggetto ConfigMap.
+1. Aggiungere un `.spec.containers[].volumeMounts[]` a ogni container che necessiti di una
+ ConfigMap. Nello specifico `.spec.containers[].volumeMounts[].readOnly = true` e
+ `.spec.containers[].volumeMounts[].mountPath` in una cartella inutilizzata
+ dove vorresti che apparisse la ConfigMap.
+1. Modificare l'immagine o il comando utilizzato così che il programma cerchi i files in
+ quella cartella. Ogni chiave nella sezione `data` della ConfigMap si converte in un file
+ sotto `mountPath`.
+
+Questo è un esempio di un Pod che monta una ConfigMap in un volume:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ containers:
+ - name: mypod
+ image: redis
+ volumeMounts:
+ - name: foo
+ mountPath: "/etc/foo"
+ readOnly: true
+ volumes:
+ - name: foo
+ configMap:
+ name: myconfigmap
+```
+
+Ogni ConfigMap che desideri utilizzare deve essere referenziata in `.spec.volumes`.
+
+Se c'è più di un container nel Pod, allora ogni container necessita del suo
+blocco `volumeMounts`, ma solamente un `.spec.volumes` è necessario ConfigMap.
+
+#### Le ConfigMaps montate sono aggiornate automaticamente
+
+Quando una ConfigMap è utilizzata in un volume ed è aggiornata, anche le chiavi vengono aggiornate.
+Il kubelet controlla se la ConfigMap montata è aggiornata ad ogni periodo di sincronizzazione.
+Ad ogni modo, il kubelet usa la sua cache locale per ottenere il valore attuale della ConfigMap.
+Il tipo di cache è configurabile usando il campo `ConfigMapAndSecretChangeDetectionStrategy` nel [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/).
+Una ConfigMap può essere propagata per vista (default), ttl-based, o redirigendo
+tutte le richieste direttamente all'API server.
+Come risultato, il ritardo totale dal momento in cui la ConfigMap è aggiornata al momento in cui nuove chiavi sono propagate al Pod può essere tanto lungo quanto il periodo della sincronizzazione del kubelet + il ritardo della propagazione della cache, dove il ritardo della propagazione della cache dipende dal tipo di cache scelta
+(è uguale rispettivamente al ritardo della propagazione, ttl della cache, o zero).
+
+Le ConfigMaps consumate come variabili d'ambiente non sono aggiornate automaticamente e necessitano di un riavvio del pod.
+
+{{< note >}}
+Un container utilizzando una ConfigMap come un [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount non riceverà gli aggiornamenti della ConfigMap.
+{{< /note >}}
+
+## ConfigMaps Immutabili {#configmap-immutable}
+
+{{< feature-state for_k8s_version="v1.21" state="stable" >}}
+
+La funzionalità di Kubernetes _Immutable Secrets and ConfigMaps_ fornisce un'opzione per
+configurare Secrets individuali e ConfigMaps come immutabili. Per clusters che usano le ConfigMaps come estensione (almeno decine o centinaia di ConfigMap uniche montate nel Pod), prevenire i cambiamenti nei loro dati ha i seguenti vantaggi:
+
+- protezione da aggiornamenti accidentali (o non voluti) che potrebbero causare l'interruzione di applicazioni
+- miglioramento della performance del tuo cluster riducendo significativamente il carico sul kube-apiserver, chiudendo l'ascolto sulle ConfigMaps che sono segnate come immutabili.
+
+Questa funzionalità è controllata dal `ImmutableEphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+Puoi creare una ConfigMap immutabile settando il campo `immutable` a `true`.
+Per esempio:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+Una volta che una ConfigMap è segnata come immutabile, _non_ è possibile invertire questo cambiamento né cambiare il contenuto del campo `data` o `binaryData` field. Puoi solamente cancellare e ricreare la ConfigMap. Poiché i Pods hanno un puntamento verso la ConfigMap eliminata, è raccomandato di ricreare quei Pods.
+
+## {{% heading "whatsnext" %}}
+
+* Leggi in merito [Secrets](/docs/concepts/configuration/secret/).
+* Leggi [Configura un Pod per utilizzare una ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+* Leggi in merito [Modificare una ConfigMap (o qualsiasi altro oggetto di Kubernetes)](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
+* Leggi [The Twelve-Factor App](https://12factor.net/) per comprendere il motivo di separare
+ il codice dalla configurazione.
\ No newline at end of file
diff --git a/content/it/docs/reference/glossary/configmap.md b/content/it/docs/reference/glossary/configmap.md
new file mode 100644
index 0000000000..a359c323cd
--- /dev/null
+++ b/content/it/docs/reference/glossary/configmap.md
@@ -0,0 +1,17 @@
+---
+title: ConfigMap
+id: configmap
+date: 2022-06-21
+full_link: /it/docs/concepts/configuration/configmap/
+short_description: >
+ Un oggetto API usato per memorizzare dati non riservati in coppie chiave-valore. Può essere utilizzato come variabili d'ambiente, argomenti da riga di comanto, o files di configurazione in un volume.
+
+aka:
+tags:
+- core-object
+---
+Un oggetto API usato per memorizzare dati non riservati in coppie chiave-valore. I {{< glossary_tooltip text="Pods" term_id="pod" >}} possono utilizzare le ConfigMaps come variabili d'ambiente, argomenti da riga di comando, o come files di configurazione all'interno di un {{< glossary_tooltip text="Volume" term_id="volume" >}}.
+
+<!--more-->
+
+La ConfigMap ti permette di disaccoppiare le configurazioni specifiche per ambiente dalle {{< glossary_tooltip text="immagini del container" term_id="image" >}}, cosicchè le tue applicazioni siano facilmente portabili.
\ No newline at end of file
diff --git a/content/it/docs/reference/glossary/image.md b/content/it/docs/reference/glossary/image.md
new file mode 100644
index 0000000000..434d5b5aa5
--- /dev/null
+++ b/content/it/docs/reference/glossary/image.md
@@ -0,0 +1,17 @@
+---
+title: Image
+id: image
+date: 2022-07-30
+full_link:
+short_description: >
+ Istanza archiviata di un cointainer che contiene un insieme di software e librerie necessarie per eseguire l'applicazione.
+
+aka:
+tags:
+- fundamental
+---
+ Istanza archiviata di un {{< glossary_tooltip term_id="container" >}} che contiene un insieme di software e librerie necessarie per eseguire l'applicazione.
+
+<!--more-->
+
+Un modo di distribuire software che permette di immagazzinarlo in Image Registry (un registro di container images), scaricarlo in un sistema locale ed eseguirlo come un'applicazione. I metadati sono inclusi nell'immagine e possono contenere informazioni su come avviare l'esecuzione, chi ha prodotto l'immagine, o altro.
diff --git a/content/it/docs/reference/glossary/secret.md b/content/it/docs/reference/glossary/secret.md
new file mode 100644
index 0000000000..cb4c0bb608
--- /dev/null
+++ b/content/it/docs/reference/glossary/secret.md
@@ -0,0 +1,18 @@
+---
+title: Secret
+id: secret
+date: 2022-07-30
+full_link:
+short_description: >
+ Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.
+
+aka:
+tags:
+- core-object
+- security
+---
+ Contiene informazioni sensibili, come passwords, token OAuth, e chiavi ssh.
+
+<!--more-->
+
+Permette un maggiore controllo su come vengono usate le informazioni sensibili e riduce il rischio di un'esposizione accidentale. I valori del Secret sono codificati in base64 e esso viene memorizzato non criptato di default, ma può essere configurato per essere [criptato](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). Un {{< glossary_tooltip text="Pod" term_id="pod" >}} fa riferimento al Secret come un file in un volume montato o by the kubelet pulling images for a pod. I Secrets sono ideali per i dati sensibili e le [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) per i dati non sensibili.
diff --git a/content/it/docs/reference/glossary/volume.md b/content/it/docs/reference/glossary/volume.md
new file mode 100644
index 0000000000..4790c2a41f
--- /dev/null
+++ b/content/it/docs/reference/glossary/volume.md
@@ -0,0 +1,20 @@
+---
+title: Volume
+id: volume
+date: 2022-06-21
+full_link: /it/docs/concepts/storage/volumes/
+short_description: >
+ Una cartella contenente dati, accessibile dai containers all'interno del pod.
+
+aka:
+tags:
+- core-object
+- fundamental
+---
+Una cartella contenente i dati, accessibile dal {{< glossary_tooltip text="containers" term_id="container" >}} in un {{< glossary_tooltip term_id="pod" >}}.
+
+<!--more-->
+
+Un volume di Kubernetes rimane in vita fintanto che lo rimane il Pod che lo racchiude. Di conseguenza, un volume sopravvive ad ogni container all'interno del Pod, e i dati nel volume sono preservati a prescindere dai restart del container.
+
+Vedi [storage](/docs/concepts/storage/) per più informazioni.
\ No newline at end of file