#20959 Localize Images page to Italian
This commit is contained in:
alessandroargentieri
parent
cd800027a5
commit
a71ba8d63b
|
|
@ -0,0 +1,316 @@
|
||||||
|
---
|
||||||
|
title: Immagini
|
||||||
|
content_type: concept
|
||||||
|
weight: 10
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- overview -->
|
||||||
|
|
||||||
|
L'immagine di un container rappresenta dati binari che incapsulano un'applicazione e
|
||||||
|
tutte le sue dipendenze software. Le immagini sono costituite da pacchetti software
|
||||||
|
eseguibili che possono essere avviati in modalità standalone e su cui si possono fare
|
||||||
|
ipotesi ben precise circa l'ambiente in cui vengono eseguiti.
|
||||||
|
|
||||||
|
Tipicamente viene creata un'immagine di un'applicazione ed effettuato il _push_
|
||||||
|
su un registry (un repository pubblico di immagini) prima di poterne fare riferimento esplicito in un
|
||||||
|
{{< glossary_tooltip text="Pod" term_id="pod" >}}
|
||||||
|
|
||||||
|
Questa pagina va a delineare nello specifico il concetto di immagine di un container.
|
||||||
|
|
||||||
|
<!-- body -->
|
||||||
|
|
||||||
|
## I nomi delle immagini
|
||||||
|
|
||||||
|
Alle immagini dei container vengono normalmente attribuiti nomi come `pause`, `example/mycontainer`, o `kube-apiserver`.
|
||||||
|
Le immagini possono anche contenere l'hostname del registry in cui le immagini sono pubblicate;
|
||||||
|
ad esempio: `registro.fittizio.esempio/nomeimmagine`,
|
||||||
|
ed è possibile che sia incluso nel nome anche il numero della porta; ad esempio: `registro.fittizio.esempio:10443/nomeimmagine`.
|
||||||
|
|
||||||
|
Se non si specifica l'hostname di un registry, Kubernetes assume che ci si riferisca al registry pubblico di Docker.
|
||||||
|
|
||||||
|
Dopo la parte relativa al nome dell'immagine si può aggiungere un _tag_ (come comunemente avviene per comandi come `docker` e `podman`).
|
||||||
|
I tag permettono l'identificazione di differenti versioni della stessa serie di immagini.
|
||||||
|
|
||||||
|
I tag delle immagini sono composti da lettere minuscole e maiuscole, numeri, underscore (`_`),
|
||||||
|
punti (`.`), e trattini (`-`).
|
||||||
|
Esistono regole aggiuntive relative a dove i caratteri separatori (`_`, `-`, and `.`)
|
||||||
|
possano essere inseriti nel tag di un'immagine.
|
||||||
|
Se non si specifica un tag, Kubernetes assume il tag `latest` che va a definire l'immagine disponibile più recente.
|
||||||
|
|
||||||
|
{{< caution >}}
|
||||||
|
Evitate di utilizzare il tag `latest` quando si rilasciano dei container in produzione,
|
||||||
|
in quanto risulta difficile tracciare quale versione dell'immagine sia stata avviata e persino più difficile
|
||||||
|
effettuare un rollback ad una versione precente.
|
||||||
|
|
||||||
|
Invece, meglio specificare un tag specifico come ad esempio `v1.42.0`.
|
||||||
|
{{< /caution >}}
|
||||||
|
|
||||||
|
## Aggiornamento delle immagini
|
||||||
|
|
||||||
|
Quando un {{< glossary_tooltip text="Deployment" term_id="deployment" >}},
|
||||||
|
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod, o qualsiasi altro
|
||||||
|
oggetto che includa un Pod template viene creato per la prima volta, la policy di default per il pull di tutti i container nel Pod
|
||||||
|
è impostata su `IfNotPresent` (se non presente) se non specificato diversamente.
|
||||||
|
Questa policy permette al
|
||||||
|
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} di evitare di fare il pull
|
||||||
|
di un'immagine se questa è già presente.
|
||||||
|
|
||||||
|
Se necessario, si può forzare il pull in ogni occasione in uno dei seguenti modi:
|
||||||
|
|
||||||
|
- impostando `imagePullPolicy` (specifica per il pull delle immagini) del container su `Always` (sempre).
|
||||||
|
- omettendo `imagePullPolicy` ed usando il tag `:latest` (più recente) per l'immagine da utilizzare;
|
||||||
|
Kubernetes imposterà la policy su `Always` (sempre).
|
||||||
|
- omettendo `imagePullPolicy` ed il tag per l'immagine da utilizzare.
|
||||||
|
- abilitando l'admission controller [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages).
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Il valore dell'impostazione `imagePullPolicy` del container è sempre presente quando l'oggetto viene creato per la prima volta
|
||||||
|
e non viene aggiornato se il tag dell'immagine dovesse cambiare successivamente.
|
||||||
|
|
||||||
|
Ad esempio, creando un Deployment con un'immagine il cui tag _non_ è
|
||||||
|
`:latest`, e successivamente aggiornando il tag di quell'immagine a `:latest`, il campo
|
||||||
|
`imagePullPolicy` _non_ cambierà su `Always`.
|
||||||
|
È necessario modificare manualmente la policy di pull di ogni oggetto dopo la sua creazione.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Quando `imagePullPolicy` è definito senza un valore specifico, esso è impostato su `Always`.
|
||||||
|
|
||||||
|
## Multi-architecture support nelle immagini
|
||||||
|
|
||||||
|
Oltre a fornire immagini binarie, un _container registry_ può fornire un [indice delle immagini disponibili per un container](https://github.com/opencontainers/image-spec/blob/master/image-index.md).
|
||||||
|
L'indice di un'immagine può puntare a più [file manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md) ciascuno per una versione specifica dell'architettura di un container.
|
||||||
|
L'idea è che si può avere un unico nome per una stessa immagine (ad esempio: `pause`, `example/mycontainer`, `kube-apiserver`) e permettere a diversi sistemi di recuperare l'immagine binaria corretta a seconda dell'architettura della macchina che la sta utilizzando.
|
||||||
|
|
||||||
|
|
||||||
|
Kubernetes stesso tipicamente nomina le immagini dei container tramite il suffisso `-$(ARCH)`.
|
||||||
|
Per la garantire la retrocompatibilità è meglio generare le vecchie immagini con dei suffissi.
|
||||||
|
L'idea è quella di generare, ad esempio, l'immagine `pause` con un manifest che include tutte le architetture supportate,
|
||||||
|
affiancata, ad esempio, da `pause-amd64` che è retrocompatibile per le vecchie configurazioni o per quei file YAML
|
||||||
|
in cui sono specificate le immagini con i suffissi.
|
||||||
|
|
||||||
|
## Utilizzare un private registry
|
||||||
|
|
||||||
|
I private registry possono richiedere l'utilizzo di chiavi per accedere alle immagini in essi contenute.
|
||||||
|
Le credenziali possono essere fornite in molti modi:
|
||||||
|
- configurando i nodi in modo tale da autenticarsi al private registry
|
||||||
|
- tutti i pod possono acquisire informazioni da qualsiasi private registry configurato
|
||||||
|
- è necessario che l'amministratore del cluster configuri i nodi in tal senso
|
||||||
|
- tramite pre-pulled images (immagini pre-caricate sui nodi)
|
||||||
|
- tutti i pod possono accedere alle immagini salvate sulla cache del nodo a cui si riferiscono
|
||||||
|
- è necessario effettuare l'accesso come root di sistema su ogni nodo per inserire questa impostazione
|
||||||
|
- specificando _ImagePullSecrets_ su un determinato pod
|
||||||
|
- solo i pod che forniscono le proprie chiavi hanno la possibilità di accedere al private registry
|
||||||
|
- tramite estensioni locali o specifiche di un _Vendor_
|
||||||
|
- se si sta utilizzando una configurazione personalizzata del nodo oppure se manualmente, o tramite il _cloud provider_,
|
||||||
|
si implementa un meccanismo di autenticazione del nodo presso il _container registry_.
|
||||||
|
|
||||||
|
Di seguito la spiegazione dettagliata di queste opzioni.
|
||||||
|
|
||||||
|
### Configurazione dei nodi per l'autenticazione ad un private registry
|
||||||
|
|
||||||
|
Se si sta utilizzando Docker sui nodi, si può configurare il _Docker container runtime_
|
||||||
|
per autenticare il nodo presso un private container registry.
|
||||||
|
|
||||||
|
Questo è un approccio possibile se si ha il controllo sulle configurazioni del nodo.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Kubernetes di default supporta solo le sezioni `auths` e `HttpHeaders` nelle configurazioni relative a Docker.
|
||||||
|
Eventuali _helper_ per le credenziali di Docker (`credHelpers` o `credsStore`) non sono supportati.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
|
||||||
|
Docker salva le chiavi per i registri privati in `$HOME/.dockercfg` oppure nel file `$HOME/.docker/config.json`.
|
||||||
|
Inserendo lo stesso file nella lista seguente, kubelet lo utilizzerà per recuperare le credenziali quando deve fare il _pull_ delle immagini.
|
||||||
|
|
||||||
|
* `{--root-dir:-/var/lib/kubelet}/config.json`
|
||||||
|
* `{cwd of kubelet}/config.json`
|
||||||
|
* `${HOME}/.docker/config.json`
|
||||||
|
* `/.docker/config.json`
|
||||||
|
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
|
||||||
|
* `{cwd of kubelet}/.dockercfg`
|
||||||
|
* `${HOME}/.dockercfg`
|
||||||
|
* `/.dockercfg`
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Potrebbe essere necessario impostare `HOME=/root` esplicitamente come variabile d'ambiente del processo _kubelet_.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Di seguito i passi consigliati per configurare l'utilizzo di un private registry da parte dei nodi del _cluster_.
|
||||||
|
In questo esempio, eseguire i seguenti comandi sul proprio desktop/laptop:
|
||||||
|
|
||||||
|
1. Esegui `docker login [server]` per ogni _set_ di credenziali che vuoi utilizzare. Questo comando aggiornerà `$HOME/.docker/config.json` sul tuo PC.
|
||||||
|
1. Controlla il file `$HOME/.docker/config.json` in un editor di testo per assicurarti che contenga le credenziali che tu voglia utilizzare.
|
||||||
|
1. Recupera la lista dei tuoi nodi; ad esempio:
|
||||||
|
- se vuoi utilizzare i nomi: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
|
||||||
|
- se vuoi recuperare gli indirizzi IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
|
||||||
|
1. Copia il tuo file locale `.docker/config.json` in uno dei path sopra riportati nella lista di ricerca.
|
||||||
|
- ad esempio, per testare il tutto: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Per i cluster di produzione, utilizza un configuration management tool per poter applicare le impostazioni su tutti i nodi laddove necessario.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Puoi fare una verifica creando un Pod che faccia uso di un'immagine privata; ad esempio:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl apply -f - <<EOF
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
metadata:
|
||||||
|
name: private-image-test-1
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: uses-private-image
|
||||||
|
image: $PRIVATE_IMAGE_NAME
|
||||||
|
imagePullPolicy: Always
|
||||||
|
command: [ "echo", "SUCCESS" ]
|
||||||
|
EOF
|
||||||
|
```
|
||||||
|
```
|
||||||
|
pod/private-image-test-1 created
|
||||||
|
```
|
||||||
|
Se tutto funziona correttamente, pochi istanti dopo, si può lanciare il comando:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl logs private-image-test-1
|
||||||
|
```
|
||||||
|
e verificare che il comando restituisca in output:
|
||||||
|
```
|
||||||
|
SUCCESS
|
||||||
|
```
|
||||||
|
|
||||||
|
Qualora si sospetti che il comando sia fallito, si può eseguire:
|
||||||
|
```shell
|
||||||
|
kubectl describe pods/private-image-test-1 | grep 'Failed'
|
||||||
|
```
|
||||||
|
In caso di fallimento, l'output sarà simile al seguente:
|
||||||
|
```
|
||||||
|
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
|
||||||
|
```
|
||||||
|
|
||||||
|
Bisogna assicurarsi che tutti i nodi nel cluster abbiano lo stesso file `.docker/config.json`.
|
||||||
|
Altrimenti i pod funzioneranno correttamente su alcuni nodi ma falliranno su altri.
|
||||||
|
Ad esempio, se si utilizza l'autoscaling per i nodi, il template di ogni istanza
|
||||||
|
devono includere il file `.docker/config.json` oppure montare un disco che lo contenga.
|
||||||
|
|
||||||
|
Tutti i pod avranno accesso in lettura alle immagini presenti nel private registry
|
||||||
|
una volta che le rispettive chiavi di accesso siano state aggiunte nel file `.docker/config.json`.
|
||||||
|
|
||||||
|
### Immagini pre-pulled
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Questo approccio è possibile se si ha il controllo sulla configurazione del nodo.
|
||||||
|
Non funzionerà qualora il cloud provider gestisca i nodi e li sostituisca automaticamente.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Kubelet di default prova a fare il pull di ogni immagine dal registry specificato.
|
||||||
|
Tuttavia, qualora la proprietà `imagePullPolicy` (specifica di pull dell'immagine) del container sia impostata su `IfNotPresent` (vale a dire, se non è già presente) oppure su `Never` (mai),
|
||||||
|
allora l'immagine locale è utilizzata (in via preferenziale o esclusiva, rispettivamente).
|
||||||
|
|
||||||
|
Se si vuole fare affidamento a immagini pre-scaricate per non dover incorrere in una fase di autenticazione presso il registry,
|
||||||
|
bisogna assicurarsi che tutti i nodi nel cluster abbiano scaricato le stesse versioni delle immagini.
|
||||||
|
|
||||||
|
Questa procedura può essere utilizzata per accelerare il processo di creazione delle istanze o come alternativa all'autenticazione presso un private registry.
|
||||||
|
|
||||||
|
Tutti i pod avranno accesso in lettura a qualsiasi immagine pre-scaricata.
|
||||||
|
|
||||||
|
### Specificare la proprietà imagePullSecrets su un Pod
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Questo approccio è quello consigliato per l'avvio di container a partire da immagini presenti in registri privati.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Kubernetes da la possibilità di specificare le chiavi del _container registry_ su un Pod.
|
||||||
|
|
||||||
|
#### Creare un Secret tramite Docker config
|
||||||
|
|
||||||
|
Esegui il comando seguente, sostituendo i valori riportati in maiuscolo con quelli corretti:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
|
||||||
|
```
|
||||||
|
|
||||||
|
Se possiedi il file delle credenziali per Docker, anziché utilizzare il comando quì sopra
|
||||||
|
puoi importare il file di credenziali come un Kubernetes
|
||||||
|
{{< glossary_tooltip text="Secrets" term_id="secret" >}}.
|
||||||
|
[Creare un Secret a partire da credenziali Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) fornisce la spiegazione dettagliata su come fare.
|
||||||
|
|
||||||
|
Ciò è particolarmente utile se si utilizzano più _container registry_ privati,
|
||||||
|
in quanto il comando `kubectl create secret docker-registry` genera un Secret che
|
||||||
|
funziona con un solo private registry.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
I Pod possono fare riferimento ai Secret per il pull delle immagini soltanto nel proprio _namespace_,
|
||||||
|
quindi questo procedimento deve essere svolto per ogni _namespace_.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
#### Fare riferimento ad imagePullSecrets in un Pod
|
||||||
|
|
||||||
|
È possibile creare pod che referenzino quel Secret aggiungendo la sezione `imagePullSecrets` alla definizione del Pod.
|
||||||
|
|
||||||
|
Ad esempio:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
cat <<EOF > pod.yaml
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
metadata:
|
||||||
|
name: foo
|
||||||
|
namespace: awesomeapps
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: foo
|
||||||
|
image: janedoe/awesomeapp:v1
|
||||||
|
imagePullSecrets:
|
||||||
|
- name: myregistrykey
|
||||||
|
EOF
|
||||||
|
|
||||||
|
cat <<EOF >> ./kustomization.yaml
|
||||||
|
resources:
|
||||||
|
- pod.yaml
|
||||||
|
EOF
|
||||||
|
```
|
||||||
|
|
||||||
|
Questo deve esser fatto per ogni Pod che utilizzi un private registry.
|
||||||
|
|
||||||
|
Comunque, le impostazioni relative a questo campo possono essere automatizzate inserendo la sezione _imagePullSecrets_
|
||||||
|
nella definizione della risorsa [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/).
|
||||||
|
|
||||||
|
Visitare la pagina [Aggiungere ImagePullSecrets ad un Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) per istruzioni più dettagliate.
|
||||||
|
|
||||||
|
Puoi utilizzarlo in congiunzione al file `.docker/config.json` configurato per ogni nodo. In questo caso, si applicherà un _merge_ delle credenziali.
|
||||||
|
|
||||||
|
## Casi d'uso
|
||||||
|
|
||||||
|
Ci sono varie soluzioni per configurare i private registry. Di seguito, alcuni casi d'uso comuni e le soluzioni suggerite.
|
||||||
|
|
||||||
|
1. Cluster in cui sono utilizzate soltanto immagini non proprietarie (ovvero _open-source_). In questo caso non sussiste il bisogno di nascondere le immagini.
|
||||||
|
- Utilizza immagini pubbliche da Docker hub.
|
||||||
|
- Nessuna configurazione richiesta.
|
||||||
|
- Alcuni _cloud provider_ mettono in _cache_ o effettuano il _mirror_ di immagini pubbliche, il che migliora la disponibilità delle immagini e ne riduce il tempo di _pull_.
|
||||||
|
1. Cluster con container avviati a partire da immagini proprietarie che dovrebbero essere nascoste a chi è esterno all'organizzazione, ma
|
||||||
|
visibili a tutti gli utenti abilitati nel cluster.
|
||||||
|
- Utilizza un private [Docker registry](https://docs.docker.com/registry/).
|
||||||
|
- Esso può essere ospitato da [Docker Hub](https://hub.docker.com/signup), o da qualche altra piattaforma.
|
||||||
|
- Configura manualmente il file .docker/config.json su ogni nodo come descritto sopra.
|
||||||
|
- Oppure, avvia un private registry dietro il tuo firewall con accesso in lettura libero.
|
||||||
|
- Non è necessaria alcuna configurazione di Kubernetes.
|
||||||
|
- Utilizza un servizio di _container registry_ che controlli l'accesso alle immagini
|
||||||
|
- Esso funzionerà meglio con una configurazione del cluster basata su _autoscaling_ che con una configurazione manuale del nodo.
|
||||||
|
- Oppure, su un cluster dove la modifica delle configurazioni del nodo non è conveniente, utilizza `imagePullSecrets`.
|
||||||
|
1. Cluster con immagini proprietarie, alcune delle quali richiedono un controllo sugli accessi.
|
||||||
|
- Assicurati che l'_admission controller_ [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod potenzialmente possono avere accesso a tutte le immagini.
|
||||||
|
- Sposta i dati sensibili un un _Secret_, invece di inserirli in un'immagine.
|
||||||
|
1. Un cluster multi-tenant dove ogni tenant necessiti di un private registry.
|
||||||
|
- Assicurati che l'_admission controller_ [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod di tutti i tenant potrebbero potenzialmente avere accesso a tutte le immagini.
|
||||||
|
- Avvia un private registry che richieda un'autorizzazione all'accesso.
|
||||||
|
- Genera delle credenziali di registry per ogni tenant, inseriscile in dei _Secret_, e popola i _Secret_ per ogni _namespace_ relativo ad ognuno dei tenant.
|
||||||
|
- Il singolo tenant aggiunge così quel _Secret_ all'impostazione _imagePullSecrets_ di ogni _namespace_.
|
||||||
|
|
||||||
|
|
||||||
|
Se si ha la necessità di accedere a più registri, si può generare un _Secret_ per ognuno di essi.
|
||||||
|
Kubelet farà il _merge_ di ogni `imagePullSecrets` in un singolo file virtuale `.docker/config.json`.
|
||||||
|
|
||||||
|
## {{% heading "whatsnext" %}}
|
||||||
|
|
||||||
|
* Leggi [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
|
||||||
Loading…
Reference in New Issue