Concepts

Edit This Page

Gestione delle risorse

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 e labels.

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:

application/nginx-app.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Multiple resources can be created the same way as a single resource:

$ 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:

$ 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:

$ 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:

$ 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:

$ 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:

$ 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:

$ 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$ ()oxargs:

$ 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 conkubectl 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:

$ 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:

$ 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:

$ 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.

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, avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette:

     labels:
        app: guestbook
        tier: frontend

while the Redis master and slave would have different tier labels, and perhaps even an additional role label:

     labels:
        app: guestbook
        tier: backend
        role: master

and

     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:

$ 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 comestable:

     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 esempiocanary), in modo che due gruppi di pod non si sovrappongano:

     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:

  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.

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:

$ 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:

$ 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 e kubectl 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:

$ 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 e kubectl 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:

$ kubectl scale deployment/my-nginx --replicas=1
deployment.extensions/my-nginx scaled

Ora hai solo un pod gestito dalla distribuzione

$ 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:

$ 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, kubectl autoscale e documento orizzontale pod autoscaler.

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), in modo che possano essere mantenuti e versionati insieme al codice per le risorse che configurano. Quindi, puoi usare kubectl 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.

$ 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 akubectl 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.

kubectl edit

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 versione aggiornata:

$ 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 oKUBE_EDITOR.

Per ulteriori informazioni, consultare il documento kubectl 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 and kubectl 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:

$ 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.

Diciamo che stavi usando la versione 1.7.9 di nginx:

$ 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.

$ 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.

What's next

Feedback