Déployer des applications associées à des disques persistants régionaux avec Kubernetes Engine

Ce tutoriel explique comment déployer une application à disponibilité élevée en déployant WordPress à l'aide de disques persistants régionaux sur Google Kubernetes Engine. Les disques persistants régionaux fournissent une réplication synchrone entre deux zones.

Les disques persistants régionaux fournissent une réplication synchrone entre deux zones.

Objectifs

  • Créer un cluster GKE régional
  • Créer une ressource Kubernetes StorageClass configurée pour les zones répliquées
  • Déployer WordPress avec un disque régional utilisant la ressource StorageClass
  • Simuler une défaillance de zone en supprimant un nœud
  • Valider la migration de l'application et des données Wordpress vers une autre zone répliquée

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

  1. Connectez-vous à votre compte Google.

    Si vous n'en possédez pas déjà un, vous devez en créer un.

  2. Dans Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Cloud.

    Accéder à la page de sélection du projet

  3. Vérifiez que la facturation est activée pour votre projet Google Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  4. Activer les API Compute Engine and GKE.

    Activer les API

Créer le cluster GKE

  1. Ouvrez Cloud Shell.

    OUVRIR Cloud Shell

    Vous exécutez le reste de ce tutoriel à partir de Cloud Shell.

  2. Créez un cluster GKE régional qui couvre deux zones de la région us-west1 :

    CLUSTER_VERSION=$(gcloud beta container get-server-config --region us-west1 --format='value(validMasterVersions[0])')
    
    export CLOUDSDK_CONTAINER_USE_V1_API_CLIENT=false
    gcloud beta container clusters create repd \
      --cluster-version=${CLUSTER_VERSION} \
      --machine-type=n1-standard-4 \
      --region=us-west1 \
      --num-nodes=1 \
      --node-locations=us-west1-b,us-west1-c
    

Vous disposez maintenant d'un cluster régional avec un nœud dans chaque zone. La commande gcloud a également configuré automatiquement la commande kubectl pour qu'elle se connecte au cluster.

Déployer l'application avec un disque régional

Dans cette section, vous installez Helm, créez la ressource Kubernetes StorageClass utilisée par le disque persistant régional et déployez WordPress.

Installer et initialiser Helm pour installer le package de graphiques

Le package de graphiques, installé avec Helm, contient tout ce dont vous avez besoin pour exécuter WordPress.

  1. Installez Helm localement sur l'instance Cloud Shell :

    curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
    chmod 700 get_helm.sh
    ./get_helm.sh
    
  2. Initialisez Helm :

    kubectl create serviceaccount tiller --namespace kube-system
    kubectl create clusterrolebinding tiller-cluster-rule \
      --clusterrole=cluster-admin \
      --serviceaccount=kube-system:tiller
    helm init --service-account=tiller
    until (helm version --tiller-connection-timeout=1 >/dev/null 2>&1); do echo "Waiting for tiller install..."; sleep 2; done && echo "Helm install complete"
    

Helm est maintenant installé sur le cluster.

Créer la ressource StorageClass

Dans cette section, vous créez la ressource StorageClass utilisée par le graphique pour définir les zones du disque régional. Les zones répertoriées dans la ressource StorageClass correspondent aux zones du cluster GKE.

  1. Créez une StorageClass pour le disque régional :

    kubectl apply -f - <<EOF
    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: repd-west1-b-c
    provisioner: kubernetes.io/gce-pd
    parameters:
      type: pd-standard
      replication-type: regional-pd
    volumeBindingMode: WaitForFirstConsumer
    allowedTopologies:
    - matchLabelExpressions:
      - key: failure-domain.beta.kubernetes.io/zone
        values:
        - europe-west1-b
        - europe-west1-c
    EOF
    

Vous disposez maintenant d'une StorageClass capable de provisionner des ressources PersistentVolume répliquées dans les zones us-west1-b et us-west1-c.

Déployer WordPress

Dans cette section, Kubernetes associe automatiquement le disque persistant à un nœud approprié de l'une des zones de disponibilité.

  1. Déployez le graphique WordPress configuré pour utiliser la ressource StorageClass que vous avez créée précédemment :

    helm install --name wp-repd \
      --set persistence.storageClass=repd-west1-b-c \
      stable/wordpress \
      --set mariadb.persistence.storageClass=repd-west1-b-c
    
  2. Exécutez la commande suivante, qui attend la création de l'adresse IP externe de l'équilibreur de charge de service :

    while [[ -z $SERVICE_IP ]]; do SERVICE_IP=$(kubectl get svc wp-repd-wordpress -o jsonpath='{.status.loadBalancer.ingress[].ip}'); echo "Waiting for service external IP..."; sleep 2; done; echo http://$SERVICE_IP/admin
    
  3. Vérifiez que le disque persistant a bien été créé :

    while [[ -z $PV ]]; do PV=$(kubectl get pvc wp-repd-wordpress -o jsonpath='{.spec.volumeName}'); echo "Waiting for PV..."; sleep 2; done
    
    kubectl describe pv $PV
    
  4. Ouvrez la page d'administration de WordPress dans votre navigateur à partir du lien affiché dans le résultat de la commande :

    echo http://$SERVICE_IP/admin
  5. Connectez-vous avec le nom d'utilisateur et le mot de passe affichés dans le résultat de la commande :

    cat - <<EOF
    Username: user
    Password: $(kubectl get secret --namespace default wp-repd-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
    EOF
    

Vous obtenez un déploiement WordPress qui fonctionne et qui est sauvegardé par des disques persistants régionaux dans deux zones.

Simuler une défaillance de zone

Dans cette section, vous simulez une défaillance de zone ; Kubernetes déplace ainsi la charge de travail vers l'autre zone et associe le disque régional au nouveau nœud.

  1. Obtenez le nœud actuel du pod WordPress :

    NODE=$(kubectl get pods -l app=wp-repd-wordpress -o jsonpath='{.items..spec.nodeName}')
    
    ZONE=$(kubectl get node $NODE -o jsonpath="{.metadata.labels['failure-domain\.beta\.kubernetes\.io/zone']}")
    
    IG=$(gcloud compute instance-groups list --filter="name~gke-repd-default-pool zone:(${ZONE})" --format='value(name)')
    
    echo "Pod is currently on node ${NODE}"
    
    echo "Instance group to delete: ${IG} for zone: ${ZONE}"
    
  2. Simulez une défaillance de zone en supprimant le groupe d'instances du nœud sur lequel le pod WordPress est en cours d'exécution :

    gcloud compute instance-groups managed delete ${IG} --zone ${ZONE}
  3. Vérifiez que le pod WordPress et le volume persistant migrent vers le nœud situé dans l'autre zone :

    kubectl get pods -l app=wp-repd-wordpress -o wide

    Assurez-vous que le nœud affiché est différent du nœud indiqué à l'étape précédente.

  4. Affichez la page d'administration de WordPress dans votre navigateur à partir du lien affiché dans le résultat de la commande :

    echo http://$SERVICE_IP/admin

    Vous avez associé un disque persistant régional à un nœud situé dans une zone différente.

Nettoyer

Afin d'éviter la facturation sur votre compte Google Cloud Platform des ressources utilisées lors de ce tutoriel, procédez comme suit :

  1. Supprimez l'application WordPress et le disque persistant :

    helm delete --purge wp-repd
  2. Attendez que tous les volumes persistants soient supprimés :

    while [[ $(kubectl get pv  | wc -l) -gt 0 ]]; do echo "Waiting for PV deletion..."; sleep 2; done
  3. Supprimez le cluster GKE :

    export CLOUDSDK_CONTAINER_USE_V1_API_CLIENT=false
    gcloud beta container clusters delete repd --region=us-west1

Étapes suivantes