Kubernetes Engine zum Bereitstellen von Anwendungen mit regionalen nichtflüchtigen Speichern

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.

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.

Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

Zur Projektauswahl

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.
Aktivieren Sie die APIs

GKE-Cluster erstellen

Öffnen Sie Cloud Shell:

Zu 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}
```
Hinweis: Kubernetes erkennt den Fehler und migriert den Pod auf einen Knoten in einer anderen 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