449 lines
19 KiB
Markdown
449 lines
19 KiB
Markdown
---
|
|
draft: True
|
|
title: Gestione delle risorse
|
|
content_type: concept
|
|
weight: 40
|
|
---
|
|
|
|
<!-- 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/).
|
|
|
|
|
|
|
|
|
|
<!-- body -->
|
|
|
|
## Organizzazione delle configurazioni delle risorse
|
|
|
|
Molte applicazioni richiedono la creazione di più risorse, ad esempio una distribuzione e un servizio. La gestione di più risorse può essere semplificata raggruppandole nello stesso file (separate da `---` in YAML). Per esempio:
|
|
|
|
{{< codenew file="application/nginx-app.yaml" >}}
|
|
|
|
Multiple resources can be created the same way as a single resource:
|
|
|
|
```shell
|
|
$ kubectl create -f https://k8s.io/examples/application/nginx-app.yaml
|
|
service/my-nginx-svc created
|
|
deployment.apps/my-nginx created
|
|
```
|
|
|
|
Le risorse verranno create nell'ordine in cui appaiono nel file. Pertanto, è meglio specificare prima il servizio, poiché ciò assicurerà che lo scheduler possa distribuire i pod associati al servizio man mano che vengono creati dal / i controller, ad esempio Deployment.
|
|
|
|
`kubectl create` accetta anche più argomenti` -f`:
|
|
|
|
```shell
|
|
$ kubectl create -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
|
```
|
|
|
|
E una directory può essere specificata piuttosto che o in aggiunta ai singoli file:
|
|
```shell
|
|
$ kubectl create -f https://k8s.io/examples/application/nginx/
|
|
```
|
|
|
|
`kubectl` leggerà tutti i file con suffissi` .yaml`, `.yml` o` .json`.
|
|
|
|
Si consiglia di inserire nello stesso file risorse correlate allo stesso livello di microservice o di applicazione e di raggruppare tutti i file associati all'applicazione nella stessa directory. Se i livelli dell'applicazione si associano tra loro tramite DNS, è quindi possibile distribuire in massa tutti i componenti dello stack.
|
|
|
|
Un URL può anche essere specificato come origine di configurazione, utile per la distribuzione direttamente dai file di configurazione controllati in github:
|
|
|
|
```shell
|
|
$ kubectl create -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
|
|
deployment.apps/my-nginx created
|
|
```
|
|
|
|
## Bulk operations in kubectl
|
|
|
|
La creazione di risorse non è l'unica operazione che `kubectl` può eseguire alla rinfusa. Può anche estrarre i nomi delle risorse dai file di configurazione per eseguire altre operazioni, in particolare per eliminare le stesse risorse che hai creato:
|
|
|
|
```shell
|
|
$ kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml
|
|
deployment.apps "my-nginx" deleted
|
|
service "my-nginx-svc" deleted
|
|
```
|
|
|
|
Nel caso di due sole risorse, è anche facile specificare entrambi sulla riga di comando usando la sintassi risorsa / nome:
|
|
|
|
```shell
|
|
$ kubectl delete deployments/my-nginx services/my-nginx-svc
|
|
```
|
|
|
|
Per un numero maggiore di risorse, troverai più semplice specificare il selettore (query etichetta) specificato usando `-l` o` --selector`, per filtrare le risorse in base alle loro etichette:
|
|
|
|
```shell
|
|
$ kubectl delete deployment,services -l app=nginx
|
|
deployment.apps "my-nginx" deleted
|
|
service "my-nginx-svc" deleted
|
|
```
|
|
|
|
130/5000
|
|
Poiché `kubectl` restituisce i nomi delle risorse nella stessa sintassi che accetta, è facile concatenare le operazioni usando` $ () `o` xargs`:
|
|
|
|
```shell
|
|
$ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
|
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
|
my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s
|
|
```
|
|
|
|
Con i suddetti comandi, prima creiamo le risorse sotto `examples/application/nginx/` e stampiamo le risorse create con il formato di output `-o name`
|
|
(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con` kubectl get`.
|
|
|
|
Se si organizzano le risorse su più sottodirectory all'interno di una particolare directory, è possibile eseguire ricorsivamente anche le operazioni nelle sottodirectory, specificando `--recursive` o` -R` accanto al flag `--filename, -f`.
|
|
|
|
Ad esempio, supponiamo che ci sia una directory `project/k8s/development` che contiene tutti i manifesti necessari per l'ambiente di sviluppo, organizzati per tipo di risorsa:
|
|
|
|
```
|
|
project/k8s/development
|
|
├── configmap
|
|
│ └── my-configmap.yaml
|
|
├── deployment
|
|
│ └── my-deployment.yaml
|
|
└── pvc
|
|
└── my-pvc.yaml
|
|
```
|
|
|
|
Per impostazione predefinita, l'esecuzione di un'operazione bulk su `project/k8s/development` si interromperà al primo livello della directory, senza elaborare alcuna sottodirectory. Se avessimo provato a creare le risorse in questa directory usando il seguente comando, avremmo riscontrato un errore:
|
|
|
|
```shell
|
|
$ kubectl create -f project/k8s/development
|
|
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
|
|
```
|
|
|
|
Invece, specifica il flag `--recursive` o` -R` con il flag `--filename, -f` come tale:
|
|
|
|
```shell
|
|
$ kubectl create -f project/k8s/development --recursive
|
|
configmap/my-config created
|
|
deployment.apps/my-deployment created
|
|
persistentvolumeclaim/my-pvc created
|
|
```
|
|
|
|
Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag` --filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .`
|
|
|
|
Il flag `--recursive` funziona anche quando sono forniti più argomenti` -f`:
|
|
|
|
```shell
|
|
$ kubectl create -f project/k8s/namespaces -f project/k8s/development --recursive
|
|
namespace/development created
|
|
namespace/staging created
|
|
configmap/my-config created
|
|
deployment.apps/my-deployment created
|
|
persistentvolumeclaim/my-pvc created
|
|
```
|
|
|
|
Se sei interessato a saperne di più su `kubectl`, vai avanti e leggi [Panoramica di kubectl](/docs/reference/kubectl/overview/).
|
|
|
|
## Usare le etichette in modo efficace
|
|
|
|
Gli esempi che abbiamo utilizzato fino ad ora si applicano al massimo una singola etichetta a qualsiasi risorsa. Esistono molti scenari in cui è necessario utilizzare più etichette per distinguere i set l'uno dall'altro.
|
|
|
|
Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette:
|
|
|
|
```yaml
|
|
labels:
|
|
app: guestbook
|
|
tier: frontend
|
|
```
|
|
|
|
while the Redis master and slave would have different `tier` labels, and perhaps even an additional `role` label:
|
|
|
|
```yaml
|
|
labels:
|
|
app: guestbook
|
|
tier: backend
|
|
role: master
|
|
```
|
|
|
|
and
|
|
|
|
```yaml
|
|
labels:
|
|
app: guestbook
|
|
tier: backend
|
|
role: slave
|
|
```
|
|
|
|
Le etichette ci permettono di tagliare e tagliare le nostre risorse lungo qualsiasi dimensione specificata da un'etichetta:
|
|
|
|
```shell
|
|
$ kubectl create -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
|
|
$ kubectl get pods -Lapp -Ltier -Lrole
|
|
NAME READY STATUS RESTARTS AGE APP TIER ROLE
|
|
guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend <none>
|
|
guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend <none>
|
|
guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend <none>
|
|
guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master
|
|
guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave
|
|
guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave
|
|
my-nginx-divi2 1/1 Running 0 29m nginx <none> <none>
|
|
my-nginx-o0ef1 1/1 Running 0 29m nginx <none> <none>
|
|
$ kubectl get pods -lapp=guestbook,role=slave
|
|
NAME READY STATUS RESTARTS AGE
|
|
guestbook-redis-slave-2q2yf 1/1 Running 0 3m
|
|
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
|
|
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.
|
|
|
|
La versione stabile e primaria avrebbe un'etichetta `track` con valore come` stable`:
|
|
|
|
```yaml
|
|
name: frontend
|
|
replicas: 3
|
|
...
|
|
labels:
|
|
app: guestbook
|
|
tier: frontend
|
|
track: stable
|
|
...
|
|
image: gb-frontend:v3
|
|
```
|
|
|
|
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
|
|
name: frontend-canary
|
|
replicas: 1
|
|
...
|
|
labels:
|
|
app: guestbook
|
|
tier: frontend
|
|
track: canary
|
|
...
|
|
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
|
|
applicazioni:
|
|
|
|
```yaml
|
|
selector:
|
|
app: guestbook
|
|
tier: frontend
|
|
```
|
|
|
|
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
|
|
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
|
|
semplicemente:
|
|
|
|
```shell
|
|
$ kubectl label pods -l app=nginx tier=fe
|
|
pod/my-nginx-2035384211-j5fhi labeled
|
|
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
|
|
appena etichettati, esegui:
|
|
|
|
```shell
|
|
$ kubectl get pods -l app=nginx -L tier
|
|
NAME READY STATUS RESTARTS AGE TIER
|
|
my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe
|
|
my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe
|
|
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
|
|
[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
|
|
esempio:
|
|
|
|
```shell
|
|
$ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
|
|
$ kubectl get pods my-nginx-v4-9gw19 -o yaml
|
|
apiversion: v1
|
|
kind: pod
|
|
metadata:
|
|
annotations:
|
|
description: my frontend running nginx
|
|
...
|
|
```
|
|
|
|
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
|
|
repliche nginx da 3 a 1, fare:
|
|
|
|
```shell
|
|
$ kubectl scale deployment/my-nginx --replicas=1
|
|
deployment.extensions/my-nginx scaled
|
|
```
|
|
|
|
Ora hai solo un pod gestito dalla distribuzione
|
|
|
|
```shell
|
|
$ kubectl get pods -l app=nginx
|
|
NAME READY STATUS RESTARTS AGE
|
|
my-nginx-2035384211-j5fhi 1/1 Running 0 30m
|
|
```
|
|
|
|
Per fare in modo che il sistema scelga automaticamente il numero di repliche nginx secondo necessità, da 1 a 3, fare:
|
|
|
|
```shell
|
|
$ kubectl autoscale deployment/my-nginx --min=1 --max=3
|
|
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
|
|
[orizzontale pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
|
|
|
## Aggiornamenti sul posto delle risorse
|
|
|
|
A volte è necessario apportare aggiornamenti stretti e senza interruzioni alle risorse che hai creato.
|
|
|
|
### 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
|
|
[`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à
|
|
le modifiche che hai apportato, senza sovrascrivere le modifiche automatiche alle proprietà che non hai specificato.
|
|
|
|
```shell
|
|
$ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
|
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
|
|
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
|
|
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
|
|
eseguire cancellazioni usando un tre via diff.
|
|
|
|
{{< note >}}
|
|
To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
|
{{< /note >}}
|
|
|
|
### kubectl edit
|
|
|
|
In alternativa, puoi anche aggiornare le risorse con `kubectl edit`:
|
|
|
|
```shell
|
|
$ kubectl edit deployment/my-nginx
|
|
```
|
|
|
|
Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
|
|
versione aggiornata:
|
|
|
|
```shell
|
|
$ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
|
|
$ vi /tmp/nginx.yaml
|
|
# do some edit, and then save the file
|
|
$ kubectl apply -f /tmp/nginx.yaml
|
|
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
|
|
variabili di ambiente `EDITOR` o` KUBE_EDITOR`.
|
|
|
|
Per ulteriori informazioni, consultare il documento [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit).
|
|
|
|
### kubectl patch
|
|
|
|
You can use `kubectl patch` to update API objects in place. This command supports JSON patch,
|
|
JSON merge patch, and strategic merge patch. See
|
|
[Update API Objects in Place Using kubectl patch](/docs/tasks/run-application/update-api-object-kubectl-patch/)
|
|
and
|
|
[kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).
|
|
|
|
|
|
## 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
|
|
risorsa. In questo caso, puoi semplicemente modificare il tuo file di configurazione originale:
|
|
|
|
```shell
|
|
$ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
|
|
deployment.apps/my-nginx deleted
|
|
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
|
|
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
|
|
[come usare `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/).
|
|
|
|
Diciamo che stavi usando la versione 1.7.9 di nginx:
|
|
|
|
```shell
|
|
$ 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`
|
|
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
|
|
informazioni su di esso, visitare [Pagina di distribuzione](/docs/concepts/workloads/controller/deployment/).
|
|
|
|
|
|
|
|
## {{% heading "whatsnext" %}}
|
|
|
|
|
|
- [[Scopri come usare `kubectl` per l'introspezione e il debug delle applicazioni.](/Docs/tasks/debug-application-cluster/debug-application-introspection/)
|
|
- [Best practice e suggerimenti sulla configurazione](/docs/concepts/configuration/overview/)
|
|
|
|
|