In dieser Anleitung wird erläutert, wie Sie eine hochverfügbare Anwendung implementieren. Dazu stellen Sie WordPress mit regionalen nichtflüchtigen Speichern in Google Kubernetes Engine bereit. Regionale nichtflüchtige Speicher bieten eine synchrone Replikation zwischen zwei Zonen.
Ziele
- Einen regionalen GKE-Cluster erstellen.
- Eine Kubernetes-StorageClass-Ressource erstellen, die für replizierte Zonen konfiguriert ist.
- WordPress mit einem regionalen Speicher erstellen, der die StorageClass verwendet.
- Einen Zonenfehler durch Löschen eines Knotens simulieren.
- Überprüfen, ob die WordPress-Anwendung und die Daten erfolgreich zu einer anderen replizierten Zone migriert werden.
Kosten
In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.
Vorbereitung
-
Melden Sie sich bei Ihrem Google-Konto an.
Wenn Sie noch kein Konto haben, melden Sie sich hier für ein neues Konto an.
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für Ihr Projekt aktiviert ist.
- Compute Engine and GKE APIs aktivieren.
GKE-Cluster erstellen
Öffnen Sie Cloud Shell:
Sie führen den Rest dieser Anleitung über Cloud Shell aus.
Erstellen Sie einen regionalen GKE-Cluster, der zwei Zonen in der Region
us-west1
umfasst:CLUSTER_VERSION=$(gcloud container get-server-config \ --region us-west1 --format='value(validMasterVersions[0])') gcloud 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
Sie haben jetzt einen regionalen Cluster mit einem Knoten in jeder Zone. Mit dem gcloud
-Befehl wurde auch automatisch der kubectl
-Befehl für die Verbindung mit dem Cluster konfiguriert.
Anwendung mit einem regionalen Speicher erstellen
In diesem Abschnitt installieren Sie Helm, erstellen die Kubernetes StorageClass, die vom regionalen nichtflüchtigen Speicher verwendet wird, und stellen WordPress bereit.
Helm installieren und initialisieren, um das Diagrammpaket zu installieren
Das Diagrammpaket, das mit Helm installiert wird, enthält alles, was Sie zum Ausführen von WordPress benötigen.
Installieren Sie Helm lokal in Ihrer Cloud Shell-Instanz:
curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get-helm-3 > get_helm.sh chmod 700 get_helm.sh ./get_helm.sh
Fügen Sie das Bitnami-Repository hinzu:
helm repo add bitnami https://charts.bitnami.com/bitnami
Helm ist jetzt in Ihrem Cluster installiert.
StorageClass erstellen
In diesem Abschnitt erstellen Sie die StorageClass, die vom Diagramm zum Definieren der Zonen des regionalen Speichers verwendet wird. Die in der StorageClass aufgeführten Zonen entsprechen den Zonen des GKE-Clusters.
Erstellen Sie für das regionale Laufwerk eine StorageClass:
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-ssd replication-type: regional-pd volumeBindingMode: WaitForFirstConsumer allowedTopologies: - matchLabelExpressions: - key: failure-domain.beta.kubernetes.io/zone values: - us-west1-b - us-west1-c EOF
Sie haben jetzt eine StorageClass, die PersistentVolumes bereitstellen kann, die über die Zonen us-west1-b
und us-west1-c
repliziert werden.
WordPress erstellen
In diesem Abschnitt hängt Kubernetes den nichtflüchtigen Speicher automatisch an einen geeigneten Knoten in einer der Verfügbarkeitszonen an.
Erstellen Sie das WordPress-Diagramm, das für die Verwendung der zuvor von Ihnen erstellten StorageClass konfiguriert ist:
helm install wp-repd \ --set persistence.storageClass=repd-west1-b-c \ --set global.storageClass=repd-west1-b-c \ bitnami/wordpress
Führen Sie diesen Befehl aus, der darauf wartet, dass die externe IP-Adresse des Dienst-Load-Balancers erstellt wird:
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
Überprüfen Sie, ob der nichtflüchtige Speicher erstellt wurde:
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
Öffnen Sie in Ihrem Browser die Admin-Seite von WordPress über den Link, den die Befehlsausgabe anzeigt:
echo http://$SERVICE_IP/admin
Melden Sie sich mit dem Nutzernamen und dem Passwort an, die in der Befehlsausgabe angezeigt werden:
cat - <<EOF Username: user Password: $(kubectl get secret \ --namespace default wp-repd-wordpress \ -o jsonpath="{.data.wordpress-password}" | base64 --decode) EOF
Sie haben jetzt eine funktionierende Bereitstellung von WordPress, die von regionalen nichtflüchtigen Speichern in zwei Zonen unterstützt wird.
Zonenfehler simulieren
In diesem Abschnitt simulieren Sie einen Zonenfehler und beobachten, wie Kubernetes Ihre Arbeitslast in die andere Zone verschiebt und das regionale Laufwerk an den neuen Knoten anfügt.
Wenn das Cluster-Autoscaling für den Cluster aktiviert ist, verwenden Sie nicht das in diesem Abschnitt beschriebene Verfahren, um einen Zonenausfall zu simulieren.
Rufen Sie den aktuellen Knoten des WordPress-Pods ab:
NODE=$(kubectl get pods \ -l app.kubernetes.io/name=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}"
Simulieren Sie einen Zonenfehler, indem Sie die Instanzgruppe für den Knoten löschen, auf dem der WordPress-Pod ausgeführt wird:
gcloud compute instance-groups managed delete ${IG} --zone ${ZONE}
Überprüfen Sie, dass sowohl der WordPress-Pod als auch das nichtflüchtige Volume auf den Knoten in der anderen Zone migriert werden:
kubectl get pods -l app=wp-repd-wordpress -o wide
Überprüfen Sie, ob der angezeigte Knoten sich vom Knoten im vorherigen Schritt unterscheidet.
Öffnen Sie in Ihrem Browser die Admin-Seite von WordPress über den Link, der in der Befehlsausgabe angezeigt wird:
echo http://$SERVICE_IP/admin
Sie haben einen regionalen nichtflüchtigen Speicher an einen Knoten angefügt, der sich in einer anderen Zone befindet.
Bereinigen
Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder behalten Sie das Projekt und löschen Sie die einzelnen Ressourcen.
Löschen Sie die WordPress-Anwendung und den nichtflüchtigen Speicher:
helm uninstall wp-repd
Warten Sie, bis alle nichtflüchtigen Volumes gelöscht sind:
while [[ $(kubectl get pv | wc -l) -gt 1 ]]; \ do echo "Waiting for PV deletion..."; sleep 2; \ done
Löschen Sie den GKE-Cluster:
gcloud container clusters delete repd --region=us-west1