Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment di un cluster Redis su GKE

Standard

Questo tutorial fornisce le pratiche consigliate per creare un'applicazione stateful ed eseguire l'upgrade del cluster Google Kubernetes Engine (GKE) che esegue l'applicazione. Questo tutorial utilizza Redis come esempio per il deployment di un'applicazione stateful, ma gli stessi concetti sono applicabili ad altri tipi di applicazioni stateful di cui è stato eseguito il deployment su GKE.

Obiettivi

Questo tutorial illustra i seguenti passaggi:

Crea un cluster GKE registrato in un canale di rilascio.
Crea un cluster Redis su GKE.
Esegui il deployment dell'applicazione client Redis in GKE.
Segui queste best practice per gli upgrade dei pool di nodi:
1. Configura il budget di interruzione dei pod (PDB).
2. Configura il periodo di manutenzione e le esclusioni.
3. Configura la strategia di upgrade dei nodi come upgrade di sovraccarico o upgrade blu/verde.
Testa l'applicazione.
Esegui l'upgrade del cluster.
Testa l'interruzione del workload.

Il seguente diagramma mostra una panoramica di alto livello dell'architettura del cluster per questo tutorial:

Diagramma dell'architettura

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per saperne di più, consulta Esegui la pulizia.

Prima di iniziare

Configura il progetto

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Roles required to create a project

To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Roles required to create a project

To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

Impostare i valori predefiniti per Google Cloud CLI

Nella console Google Cloud , avvia un'istanza Cloud Shell:
Apri Cloud Shell

Scarica il codice sorgente di questa app di esempio:

 git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
 cd kubernetes-engine-samples/quickstarts/hello-app-redis/manifests

Imposta le variabili di ambiente predefinite:
```
 gcloud config set project PROJECT-ID
 gcloud config set compute/zone COMPUTE-ZONE
```
Sostituisci i seguenti valori:
- PROJECT_ID: il tuo ID progetto Google Cloud.
- COMPUTE_ZONE: la zona Compute Engine.

Crea un cluster GKE registrato in un canale di rilascio

Per creare il cluster GKE, completa i seguenti passaggi:

Crea un cluster denominato redis-test con tre nodi:

gcloud container clusters create redis-test \
    --location CONTROL_PLANE_LOCATION \
    --num-nodes=3 \
    --release-channel regular

Sostituisci CONTROL_PLANE_LOCATION con la posizione di Compute Engine del control plane del cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

Una volta creato il cluster, dovresti visualizzare un output simile al seguente esempio:

  NAME: redis-test
  LOCATION: us-central1-c
  MASTER_VERSION: 1.22.10-gke.600
  MASTER_IP: 34.69.67.7
  MACHINE_TYPE: e2-medium
  NODE_VERSION: 1.22.10-gke.600
  NUM_NODES: 3
  STATUS: RUNNING

Configura kubectl per comunicare con il cluster:

gcloud container clusters get-credentials redis-test

Crea un cluster Redis su GKE

In questa sezione aggiungi un cluster Redis in cima al cluster GKE che hai creato in precedenza eseguendo il deployment di ConfigMap, StatefulSet e servizio headless.

Per creare un cluster Redis:

Fai riferimento al file ConfigMap (redis-configmap.yaml) che archivia la configurazione di Redis. Lo snippet seguente mostra gli script del probe di idoneità e del probe di attività.

readiness.sh: |-
  #!/bin/sh

  pingResponse="$(redis-cli -h localhost ping)"
  if [ "$?" -eq "124" ]; then
    echo "PING timed out"
    exit 1
  fi

  if [ "$pingResponse" != "PONG"]; then
    echo "$pingResponse"
    exit 1
  fi
liveness.sh: |-
  #!/bin/sh

  pingResponse="$(redis-cli -h localhost ping | head -n1 | awk '{print $1;}')"
  if [ "$?" -eq "124" ]; then
    echo "PING timed out"
    exit 1
  fi

  if [ "$pingResponse" != "PONG"] && [ "$pingResponse" != "LOADING" ] && [ "$pingResponse" != "MASTERDOWN" ]; then
    echo "$pingResponse"
    exit 1
  fi

Gli script readiness.sh e liveness.sh utilizzano redis-cli ping per verificare se il server Redis è in esecuzione o meno. Se restituisce PONG, il server Redis è attivo e in esecuzione. Questi script verranno utilizzati in redis-cluster.yaml.

Per scoprire di più sui parametri Redis in questo ConfigMap, consulta la sezione Parametri di configurazione di Redis Cluster nel tutorial su Redis Cluster.

Esegui il deployment di ConfigMap:
```
kubectl apply -f redis-configmap.yaml
```

Fai riferimento allo snippet StatefulSet (redis-cluster.yaml) riportato di seguito, che mostra l'utilizzo del probe di idoneità e del probe di attività.

Per scoprire come configurare i probe in Kubernetes, consulta Configura i probe.

startupProbe:
  periodSeconds: 5
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 20
  tcpSocket:
    port: redis
livenessProbe:
  periodSeconds: 5
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 5
  exec:
    command: ["sh", "-c", "/probes/liveness.sh"]
readinessProbe:
  periodSeconds: 5
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 5
  exec:
    command: ["sh", "-c", "/probes/readiness.sh"]

Ti consigliamo vivamente di utilizzare i probe di disponibilità e attività durante l'upgrade dei pool di nodi. In questo modo, i pod sono pronti durante un upgrade.

Esegui il deployment di StatefulSet:
```
kubectl apply -f redis-cluster.yaml
```
Il servizio headless denominato redis-service.yaml è per la connessione dei nodi Redis. Il campo clusterIP è impostato su None per creare un servizio headless.

Esegui il deployment del servizio:
```
kubectl apply -f redis-service.yaml
```

Attendi circa due minuti e verifica che tutti i pod siano in esecuzione utilizzando il seguente comando:

kubectl get pods

Dovresti vedere un output simile al seguente esempio:

NAME      READY   STATUS              RESTARTS   AGE
redis-0   1/1     Running             0          2m29s
redis-1   1/1     Running             0          2m8s
redis-2   1/1     Running             0          107s
redis-3   1/1     Running             0          85s
redis-4   1/1     Running             0          54s
redis-5   1/1     Running             0          23s

Verifica che i volumi permanenti siano stati creati eseguendo questo comando:

kubectl get pv

Dovresti vedere un output simile al seguente esempio:

NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-5   standard                75s
pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-1   standard                2m59s
pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-3   standard                2m16s
pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-2   standard                2m38s
pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-0   standard                3m20s
pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-4   standard                104s

In questo output, HASH rappresenta un hash allegato a ogni nome del volume permanente.

Assegna ruoli al tuo cluster Redis

Una volta completata la configurazione, assegna i ruoli al cluster Redis.

Il seguente script ottiene gli indirizzi IP dei pod, quindi assegna i ruoli leader e follower passando ciascuno degli indirizzi IP dei pod al comando:

#!/bin/bash
# Usage: ./roles.sh

urls=$(kubectl get pods -l app=redis -o jsonpath='{range.items[*]}{.status.podIP} ')
command="kubectl exec -it redis-0 -- redis-cli --cluster create --cluster-replicas 1 "

for url in $urls
do
    command+=$url":6379 "
done

echo "Executing command: " $command
$command

Per assegnare ruoli al cluster Redis, completa questi passaggi:

Esegui lo script:
```
chmod +x ./roles.sh
./roles.sh
```
Digita yes quando richiesto.
Accedi a un nodo Redis per verificarne il ruolo. Ad esempio, per verificare che redis-0 abbia un ruolo di leader, esegui questo comando:
```
kubectl exec -it redis-0 -- redis-cli role
```
Dovresti vedere un output simile al seguente esempio:
```
1) "master"
2) (integer) 574
3) 1) 1) "10.28.2.3"
       2) "6379"
       3) "574"
```

Esegui il deployment dell'applicazione client Redis

Per eseguire il deployment dell'applicazione nel cluster GKE che hai creato, definisci un deployment per la tua applicazione. Il file denominato app-deployment.yaml contiene la definizione di deployment per l'applicazione.

Per saperne di più sui probe e sulle regole di affinità dei pod utilizzati in questo deployment, consulta Best practice di GKE: progettazione e creazione di cluster ad alta affidabilità.

Per creare il deployment, completa i seguenti passaggi:

Applica il deployment:
```
kubectl apply -f app-deployment.yaml
```

Esporre l'applicazione tramite un bilanciatore del carico:

kubectl expose deployment hello-web \
    --type=LoadBalancer \
    --port 80 \
    --target-port 8080

Attendi circa un minuto e recupera l'indirizzo IP esterno dell'applicazione eseguendo il seguente comando:

kubectl get service

Dall'output, copia il valore elencato nella colonna hello-web's EXTERNAL-IP:

NAME             TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)              AGE
hello-web        LoadBalancer   10.13.10.55   EXTERNAL_IP   80:30703/TCP         166m

Verifica che l'applicazione funzioni incollando EXTERNAL_IP nel browser web. Dovresti vedere un output simile al seguente esempio:
```
I have been hit [1] times since deployment!
```
Prendi nota del numero della visita. Devi utilizzarlo nella sezione Test dell'interruzione dell'applicazione.
Imposta una variabile per EXTERNAL_IP che hai appena copiato. Utilizzi questo valore quando crei script per testare l'applicazione nella sezione successiva:
```
export IP=EXTERNAL_IP
```

Configura le best practice per gli upgrade dei pool di nodi

Segui queste best practice per le applicazioni stateful per ottimizzare la disponibilità durante gli upgrade dei pool di nodi.

Configura il budget di interruzione dei pod (PDB)

Crea un budget di interruzione dei pod per limitare il numero di pod replicati che non sono disponibili contemporaneamente durante un'interruzione volontaria. Questa opzione è utile per le applicazioni stateful in cui è necessario un quorum per il numero di repliche disponibili durante un upgrade.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: redis-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: redis

In una definizione PDB:

app specifica a quale applicazione si applica questo PDB.
minAvailable imposta il numero minimo di pod da rendere disponibili durante un'interruzione. Può essere un valore o una percentuale (ad es. 30%).
maxUnavailable imposta il numero massimo di pod che possono non essere disponibili durante un'interruzione. Può essere anche un valore o una percentuale.

Per configurare il PDB, completa questi passaggi:

Esegui il deployment del PDB:
```
kubectl apply -f pdb-minavailable.yaml
```
Verifica che il PDB sia stato creato:
```
kubectl get pdb
```

Configura i periodi di manutenzione e le esclusioni

Gli upgrade automatici dei nodi semplificano la procedura di upgrade e mantengono aggiornati i nodi nel cluster quando l'upgrade del control plane viene eseguito per tuo conto. Questa funzione è attivata per impostazione predefinita. Per saperne di più, consulta la sezione Upgrade automatico dei nodi.

Utilizza periodi di manutenzione ed esclusioni della manutenzione per configurare intervalli di tempo e controllare quando la manutenzione può e non può essere eseguita sui cluster GKE:

Configura un periodo di manutenzione che inizia alle 02:00 UTC del 19 agosto 2022 e termina quattro ore dopo. Questo periodo di manutenzione viene eseguito quotidianamente. Durante questo periodo, è consentita la manutenzione automatica.
```
gcloud container clusters update redis-test \
   --maintenance-window-start 2022-08-19T02:00:00Z \
   --maintenance-window-end 2022-08-19T06:00:00Z \
   --maintenance-window-recurrence FREQ=DAILY
```
Configura un periodo di esclusione che impedisca la manutenzione durante le vacanze di Capodanno. Questa esclusione dalla manutenzione utilizza l'ambito no_upgrades. Durante questo periodo, non è consentita alcuna manutenzione automatica. Per scoprire di più, consulta Ambito della manutenzione da escludere.
```
gcloud container clusters update redis-test \
   --add-maintenance-exclusion-name new-year \
   --add-maintenance-exclusion-start 2022-12-26T00:00:00Z \
   --add-maintenance-exclusion-end 2023-01-02T02:00:00Z \
   --add-maintenance-exclusion-scope no_upgrades
```
Verifica che il periodo di manutenzione e le esclusioni siano applicati. Guarda in maintenancePolicy:
```
gcloud container clusters describe redis-test
```

Per scoprire di più, consulta Configurare periodi di manutenzione ed esclusioni.

Configura una strategia di upgrade dei nodi

Esistono due strategie di upgrade dei nodi che puoi utilizzare per i node pool nel tuo cluster GKE: upgrade blu/verde e upgrade di sovraccarico. Per saperne di più, consulta Strategie di upgrade dei nodi.

Upgrade blu/verde

Scegli gli upgrade blu/verde se i workload sono meno tolleranti alle interruzioni e un aumento temporaneo dei costi dovuto a un maggiore utilizzo delle risorse è accettabile.

Esegui il seguente comando per modificare i node pool correnti in modo che utilizzino la strategia di upgrade blu/verde.

gcloud container node-pools update default-pool \
--cluster=redis-test \
--enable-blue-green-upgrade \
--location CONTROL_PLANE_LOCATION \
--node-pool-soak-duration=120s

La durata di attesa per il node pool è impostata su due minuti per risparmiare tempo durante la fase di attesa per il pool di nodi ai fini di questo tutorial. Questa fase viene utilizzata per verificare l'integrità del workload dopo lo svuotamento dei nodi del pool blu. Ti consigliamo di impostare la durata del test del pool di nodi su un'ora (3600 secondi) o su una durata più adatta all'applicazione.

Per saperne di più sulla gestione dell'allocazione dei pod, vedi Eseguire il deployment di un pod in un pool di nodi specifico e Eseguire il deployment di servizi in pool di nodi specifici.

Per ulteriori informazioni sulla configurazione degli upgrade blu/verde, consulta Configurare gli upgrade blu/verde.

Upgrade di sovraccarico

Scegli gli upgrade inattivi se l'ottimizzazione dei costi è importante e se i workload possono tollerare un arresto controllato in meno di 60 minuti (GKE rispetta PDB fino a 60 minuti).

Esegui il comando seguente per modificare i node pool correnti in modo che utilizzino la strategia di upgrade di sovraccarico.

gcloud container node-pools update default-pool \
--max-surge-upgrade=1 \
--max-unavailable-upgrade=0 \
--cluster=redis-test

Con questa configurazione (maxSurge=1 e maxUnavailable=0), è possibile aggiungere un solo nodo di picco alpool di nodil durante un upgrade, quindi è possibile eseguire l'upgrade di un solo nodo alla volta. Questa impostazione accelera i riavvii dei pod durante gli upgrade, procedendo in modo conservativo.

Per ulteriori informazioni sulla configurazione degli upgrade di sovraccarico, consulta Configurare gli upgrade di sovraccarico.

Controlla la configurazione attuale del pool di nodi:

   gcloud container node-pools describe default-pool \
   --cluster redis-test \
   --location CONTROL_PLANE_LOCATION

Per saperne di più sulla visualizzazione dei node pool, consulta Visualizza i node pool in un cluster.

testa l'applicazione

In questa sezione utilizzi due script: uno che invia richieste alla tua applicazione e uno che misura il tasso di successo delle richieste. Utilizza questi script per misurare cosa succede quando esegui l'upgrade del cluster.

Per creare gli script:

Passa alla directory contenente gli script:

cd
cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts

Fai riferimento allo script denominato generate_load.sh, che invia una richiesta di query al secondo (QPS) alla tua applicazione. Lo script salva il codice di risposta HTTP nella directory corrente in un file denominato output. Il valore di output viene utilizzato nello script che crei nel passaggio successivo.
```
#!/bin/bash
# Usage: ./generate_load.sh <IP> <QPS>

IP=$1
QPS=$2

while true
  do for N in $(seq 1 $QPS)
    do curl -I -m 5 -s -w "%{http_code}\n" -o /dev/null http://${IP}/ >> output &
    done
  sleep 1
done
```

Fai riferimento allo script denominato print_error_rate.sh, che calcola il tasso di successo in base all'output generato da generate_load.sh.

#!/bin/bash
# Usage: watch ./print_error_rate.sh

TOTAL=$(cat output | wc -l);
SUCCESS=$(grep "200" output |  wc -l);
ERROR1=$(grep "000" output |  wc -l)
ERROR2=$(grep "503" output |  wc -l)
ERROR3=$(grep "500" output |  wc -l)
SUCCESS_RATE=$(($SUCCESS * 100 / TOTAL))
ERROR_RATE=$(($ERROR1 * 100 / TOTAL))
ERROR_RATE_2=$(($ERROR2 * 100 / TOTAL))
ERROR_RATE_3=$(($ERROR3 * 100 / TOTAL))
echo "Success rate: $SUCCESS/$TOTAL (${SUCCESS_RATE}%)"
echo "App network Error rate: $ERROR1/$TOTAL (${ERROR_RATE}%)"
echo "Resource Error rate: $ERROR2/$TOTAL (${ERROR_RATE_2}%)"
echo "Redis Error rate: $ERROR3/$TOTAL (${ERROR_RATE_3}%)"

Concediti l'autorizzazione per eseguire gli script:

chmod u+x generate_load.sh print_error_rate.sh

Imposta una variabile per il numero di QPS. Questo valore viene utilizzato nello script generate_load.sh così come la variabile impostata per EXTERNAL_IP. Ti consigliamo di impostare un valore pari a 40.
```
export QPS=40
```
Esegui lo script generate_load.sh per iniziare a inviare QPS:
```
./generate_load.sh $IP $QPS 2>&1
```
Lascia in esecuzione lo script generate_load.sh e apri un nuovo terminale. Nel nuovo terminale, esegui lo script print_error_rate.sh per controllare il tasso di errore:
```
cd
cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
watch ./print_error_rate.sh
```
Dovresti visualizzare una percentuale di successo del 100% e tassi di errore dello 0% man mano che vengono effettuate le QPS.
Lascia in esecuzione entrambi gli script e apri un terzo terminale in preparazione della sezione successiva.

Esegui l'upgrade del cluster

Per eseguire l'upgrade del cluster, completa questi passaggi:

Determina la versione di GKE utilizzata dal cluster redis-test:
```
V=$(gcloud container clusters describe redis-test | grep "version:" | sed "s/version: //")
echo $V
```
Dovresti vedere un output simile al seguente esempio: 1.22.9-gke.2000.
Recupera un elenco delle versioni di Kubernetes disponibili:
```
gcloud container get-server-config
```
Nell'elenco delle versioni, individua la sezione validMasterVersions: e cerca la versione redis-test recuperata nel passaggio precedente. Per evitare di violare le norme relative alla differenza di versione di GKE scegliendo una versione incompatibile con i nodi, copia la versione dall'elenco riportato immediatamente prima della versione redis-test.
Esegui l'upgrade del control plane del cluster alla versione selezionata e digita y quando ti viene richiesto:
```
gcloud container clusters upgrade redis-test \
    --master \
    --cluster-version VERSION
```
Sostituisci VERSION con la versione selezionata dall'elenco nel passaggio precedente.

L'upgrade del control plane richiede diversi minuti.
Esegui l'upgrade dei nodi del cluster alla versione selezionata e digita y quando ti viene richiesto:
```
gcloud container clusters upgrade redis-test \
    --cluster-version=VERSION \
    --node-pool=default-pool
```
Sostituisci VERSION con la versione selezionata dall'elenco.

Testa l'interruzione del workload

In questa sezione, testi lo stato dell'applicazione e osservi l'interruzione del carico di lavoro.

Torna alla finestra del terminale in cui è in esecuzione ./print_error_rate.sh e osserva come è cambiato il tasso di successo durante l'upgrade. Dovresti notare una leggera diminuzione della percentuale di successo e un leggero aumento del tasso di errore della rete dell'app man mano che i nodi vengono disattivati per l'upgrade.

Nel campo Success rate vedrai il numero di visite effettuate correttamente al sito web. Prendi nota di questo valore.
Interrompi l'esecuzione di entrambi gli script inserendo CTRL+C nei terminali pertinenti.
Torna al sito web della tua applicazione inserendo il relativo indirizzo IP (ovvero EXTERNAL_IP che hai copiato nella sezione Deploy dell'applicazione client Redis) nel browser.
Osserva il numero di visite per la tua applicazione. Il numero visualizzato dovrebbe essere uguale a:

ORIGINAL_VISIT_NUMBER + SUCCESSFUL_VISIT_NUMBER

dove ORIGINAL_VISIT_NUMBER è il numero che hai registrato nel passaggio finale di Deploy dell'applicazione client Redis e SUCCESSFUL_VISIT_NUMBER è il valore che hai registrato nel primo passaggio di questa sezione.

Esegui la pulizia

Al termine del tutorial, puoi eliminare le risorse che hai creato in modo che non utilizzino più la quota generando addebiti. Le seguenti sezioni descrivono come eliminare o disattivare queste risorse.

Elimina il progetto

Il modo più semplice per eliminare la fatturazione è eliminare il progetto creato per il tutorial.

Per eliminare il progetto:

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, eliminerai anche tutto il lavoro che hai svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Elimina il cluster

Per eliminare il cluster che hai creato per questo tutorial, esegui questo comando:

gcloud container clusters delete redis-test