whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Revert "Repair and sync the dev-1.18 branch" (#19228)

Browse Source
This commit is contained in:
Zach Corleissen
2020-02-21 12:16:47 -08:00
committed by GitHub
parent 6ea6519b8f
commit e66e21ab7b
117 changed files with 3577 additions and 2899 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/it/docs/concepts/cluster-administration/manage-deployment.md
+45 -45
View File
@@ -6,9 +6,9 @@ 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/)
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 %}}
@@ -187,9 +187,9 @@ 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
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.
@@ -208,7 +208,7 @@ 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
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
@@ -223,8 +223,8 @@ 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
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
@@ -234,16 +234,16 @@ applicazioni:
```
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
È 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).
## 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
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
@@ -253,7 +253,7 @@ 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
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
@@ -267,13 +267,13 @@ 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`).
Per ulteriori informazioni, consultare [labels](/docs/concepts/overview/working-with-objects/labels/) e
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
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
@@ -287,12 +287,12 @@ metadata:
...
```
Per ulteriori informazioni, consultare il documento [annotazioni](/docs/concepts/overview/working-with-objects/annotations/)
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
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
@@ -318,7 +318,7 @@ 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
[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
@@ -327,13 +327,13 @@ 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
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à
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
@@ -341,18 +341,18 @@ $ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.ya
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
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
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
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 >}}
@@ -367,7 +367,7 @@ 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
Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
versione aggiornata:
```shell
@@ -379,7 +379,7 @@ 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
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).
@@ -396,9 +396,9 @@ 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
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
@@ -409,12 +409,12 @@ 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
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
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:
@@ -424,16 +424,16 @@ $ 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`
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
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 %}}