Apache Kafka mit Strimzi in GKE bereitstellen

Autopilot Standard

In dieser Anleitung erfahren Sie, wie Sie mit dem Strimzi-Operator Apache Kafka-Cluster bereitstellen.

Kafka ist ein verteiltes Open-Source-Messaging-System, das für Streamingdaten in großem Umfang, mit hohem Durchsatz und in Echtzeit verarbeitet werden kann. Sie können damit Streamingdaten-Pipelines für eine zuverlässige Datenübertragung zwischen verschiedenen Systemen und Anwendungen erstellen, um Verarbeitungs- und Analyseaufgaben zu unterstützen.

Operatoren sind Softwareerweiterungen, die benutzerdefinierte Ressourcen zur Verwaltung von Anwendungen und ihrer Komponenten verwenden. Weitere Informationen zur Motivation für die Verwendung von Operatoren finden Sie unter Operatormuster in der Open-Source-Dokumentation zu Kubernetes. Der Strimzi-Operator bietet Flexibilität bei den Bereitstellungsoptionen und ermöglicht Ihnen die Verwendung von Kubernetes-Markierungen und -Toleranzen zum Ausführen von Kafka auf dedizierten Knoten.

Dieser Leitfaden richtet sich an Plattformadministratoren, Cloud-Architekten und Betriebsexperten, die an der Bereitstellung von Kafka-Clustern in GKE interessiert sind.

Diese Lösung ist ein guter Ausgangspunkt, wenn Sie wissen möchten, wie Sie Kafka-Cluster mithilfe eines Drittanbieteroperators bereitstellen, um die Verwaltung zu automatisieren und Fehler zu reduzieren. Wenn Sie eine detailliertere operative Kontrolle bevorzugen, lesen Sie die Informationen unter Hochverfügbare Kafka-Cluster in GKE bereitstellen.

Lernziele

GKE-Infrastruktur für Apache Kafka planen und bereitstellen
Strimzi-Operator bereitstellen und konfigurieren
Apache Kafka mit dem Strimzi-Operator konfigurieren

Vorteile

Strimzi hat folgende Vorteile:

Strimzi-Operatoren bieten einen vereinfachten und Kubernetes-nativen Ansatz zur Verwaltung von Kafka-Clustern. Strimzi verwendet benutzerdefinierte Ressourcen, die Kafka-Themen und -Nutzer darstellen. Dadurch wird die Clusterverwaltung viel einfacher und mit den Best Practices von Kubernetes ausgerichtet.
Strimzi priorisiert standardmäßig die Sicherheit, indem Zertifikate für Listener generiert und sichere Authentifizierungsmethoden wie TLS, SCRAM-SHA und OAuth unterstützt werden. Strimzi verarbeitet außerdem NetworkPolicies für alle Kafka-Listener.
Strimzi verwendet keine externen Abhängigkeiten. Es umfasst Kafka- und ZooKeeper-Cluster mit integriertem Messwertexportern, sodass Sie sich nicht mit zusätzlichen Tools befassen müssen. Sie können Broker-Konfigurationen auch optimieren, um bestimmte Anforderungen zu erfüllen.

Bereitstellungsarchitektur

Ein Kafka-Cluster besteht aus einem oder mehreren Servern, die als Broker bezeichnet werden und die zusammen die eingehende Datenstreams verwalten und Publish-Subscribe-Nachrichten für Kafka-Clients erleichtern. Diese werden als Nutzer bezeichnet.

Jeder Datenpartition innerhalb des Kafka-Clusters wird ein Leader-Broker zugewiesen, der für die Verwaltung aller Lese- und Schreibvorgänge in dieser Partition verantwortlich ist. Die Partition kann auch einen oder mehrere Follower-Broker haben, die die Aktionen des Leader-Brokers passiv replizieren.

In einer typischen Einrichtung koordiniert ZooKeeper Cluster von Kafka, indem er dazu beiträgt, einen Leader unter den Brokern zu wählen, und einen reibungslosen Failover bei Problemen gewährleistet.

Sie können die Kafka-Konfiguration auch ohne Zookeeper bereitstellen. Dazu aktivieren Sie den KRaft-Modus. Diese Methode wird jedoch nicht von der Strimzi-Community als produktionsbereit betrachtet, da sie keine Unterstützung für KafkaTopic-Ressourcen, die Authentifizierung von Anmeldedaten und vieles mehr bietet.

Verfügbarkeit und Notfallwiederherstellung

In dieser Anleitung werden separate Knotenpools und Zonen für Cluster von Kafka und ZooKeeper verwendet, um eine hohe Verfügbarkeit sicherzustellen und sich auf Notfallwiederherstellung vorzubereiten.

Die Verwendung mehrerer Knoten und Zonen ist aus folgenden Gründen entscheidend, um einen hochverfügbaren Kubernetes-Cluster in Google Cloud zu erreichen:

Fehlertoleranz: Mehrere Knoten verteilen die Arbeitslast auf den Cluster. Dadurch wird sichergestellt, dass die anderen Knoten die Aufgaben übernehmen, wenn ein Knoten ausfällt. Dadurch werden Ausfallzeiten und Dienstunterbrechungen verhindert.
Skalierbarkeit: Die Verwendung mehrerer Knoten sorgt dafür, dass die horizontale Skalierung nach Bedarf Knoten hinzufügen oder entfernen kann, um eine optimale Ressourcenzuweisung zu gewährleisten und die erhöhten Traffic- oder Arbeitslastanforderungen zu erfüllen.
Hohe Verfügbarkeit: Die Verwendung mehrerer Zonen innerhalb einer Region sorgt für Redundanz und minimiert das Risiko eines Single Point of Failure. Wenn eine ganze Verfügbarkeitszone ausfällt, kann der Cluster in anderen Zonen ausgeführt werden, wobei die Dienstverfügbarkeit aufrechterhalten wird.
Geografische Redundanz: Durch die Verteilung von Knoten über Regionen hinweg sind die Daten und Dienste des Clusters geografisch verteilt, wodurch sie gegen Naturkatastrophen, Stromausfälle oder andere lokale Störungen geschützt wird, die sich auf eine einzelne Zone auswirken können.
Rolling Updates und Wartung: Bei Verwendung mehrerer Zonen können Rolling Updates und Wartungen auf einzelnen Knoten ausgeführt werden, ohne die Gesamtverfügbarkeit des Clusters zu beeinträchtigen. Dies gewährleistet einen kontinuierlichen Dienst und ermöglicht gleichzeitig eine nahtlose Anwendung von Aktualisierungen und Patches.
Service Level Agreements (SLAs): Google Cloud bietet SLAs für Bereitstellungen in mehreren Zonen, die eine Mindestverfügbarkeit und Verfügbarkeit gewährleisten.

Bereitstellungsdiagramm

Das folgende Diagramm zeigt einen Kafka-Cluster, der auf mehreren Knoten und Zonen in einem GKE-Cluster ausgeführt wird:

Im Diagramm wird die Kafka-StrimziPodSet auf drei Knoten in drei verschiedenen Zonen bereitgestellt. Sie können diese Konfiguration steuern, indem Sie die erforderlichen Regeln für Pod-Affinität und Topologieverteilung auf die benutzerdefinierte Ressourcenspezifikation StrimziPodSet festlegen.

Wenn eine Zone ausfällt und die empfohlene Konfiguration verwendet wird, weist GKE Pods auf neuen Knoten neu und repliziert Daten aus den verbleibenden Replikaten für Kafka und Zookeeper.

Das folgende Diagramm zeigt einen ZooKeeper-StrimziPodSet, der auf drei Knoten in drei verschiedenen Zonen bereitgestellt wird:

Benutzerdefinierte Ressource `StrimziPodSet`

In dieser Anleitung wird die benutzerdefinierte Ressource StrimziPodSet verwendet, die in Version 0.29 von Strimzi anstelle von StatefulSets eingeführt wurde.

Die StrimziPodSet-Ressourcen bieten eine verbesserte Skalierbarkeit für den Cluster und ermöglichen die Übergabe von Konfigurationsoptionen, sodass Sie detailliertere Änderungen an Pods vornehmen können. Die StrimziPodSet-Ressource ist in den Strimzi-Versionen 0.35 und höher standardmäßig aktiviert.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

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.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

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.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine, IAM, GKE, Backup for GKE, and Resource Manager APIs:

gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine, IAM, GKE, Backup for GKE, and Resource Manager APIs:

gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com cloudresourcemanager.googleapis.com

Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/storage.objectViewer, roles/logging.logWriter, roles/container.clusterAdmin, roles/container.serviceAgent, roles/iam.serviceAccountAdmin, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin
```
gcloud projects add-iam-policy-binding PROJECT_ID --member="USER_IDENTIFIER" --role=ROLE
```
- Replace PROJECT_ID with your project ID.
- Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.
- Replace ROLE with each individual role.

Umgebung vorbereiten

In dieser Anleitung verwenden Sie Cloud Shell zum Verwalten von Ressourcen, die in Google Cloud gehostet werden. Die Software, die Sie für diese Anleitung benötigen, ist in Cloud Shell vorinstalliert, einschließlich kubectl, gcloud CLI, Helm und Terraform.

So richten Sie Ihre Umgebung mit Cloud Shell ein:

Starten Sie eine Cloud Shell-Sitzung über die Google Cloud Console. Klicken Sie dazu in der Google Cloud Console auf Cloud Shell aktivieren. Dadurch wird im unteren Bereich der Google Cloud Console eine Sitzung gestartet.

Legen Sie Umgebungsvariablen fest:

export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=kafka
export REGION=us-central1

Ersetzen Sie PROJECT_ID: Ihre Google Cloud mit Ihrer Projekt-ID.

Klonen Sie das GitHub-Repository:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

Wechseln Sie in das Arbeitsverzeichnis:

cd kubernetes-engine-samples/streaming/

Clusterinfrastruktur erstellen

In diesem Abschnitt führen Sie ein Terraform-Skript aus, um einen privaten, hochverfügbaren regionalen GKE-Cluster zu erstellen. Die folgenden Schritte ermöglichen einen öffentlichen Zugriff auf die Steuerungsebene. Erstellen Sie einen privaten Cluster, um den Zugriff einzuschränken.

Sie können den Operator mit einem Standard- oder Autopilot-Cluster installieren.

Standard

Das folgende Diagramm zeigt einen privaten regionalen Standard-GKE-Cluster, der in drei verschiedenen Zonen bereitgestellt wird:

Führen Sie die folgenden Befehle in der Cloud Shell aus, um diese Infrastruktur bereitzustellen:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=kafka/terraform/gke-standard init
terraform -chdir=kafka/terraform/gke-standard apply -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Geben Sie bei Aufforderung yes ein. Es kann einige Minuten dauern, bis dieser Befehl abgeschlossen ist und der Cluster den Status „Bereit“ anzeigt.

Terraform erstellt die folgenden Ressourcen:

Ein VPC-Netzwerk und ein privates Subnetz für die Kubernetes-Knoten.
Ein Router für den Zugriff auf das Internet über NAT.
Ein privater GKE-Cluster in der Region us-central1.
2 Knotenpools mit aktiviertem Autoscaling (1-2 Knoten pro Zone, mindestens 1 Knoten pro Zone)
Ein ServiceAccount mit Logging- und Monitoring-Berechtigungen.
Backup for GKE zur Notfallwiederherstellung.
Google Cloud Managed Service for Prometheus für das Clustermonitoring.

Die Ausgabe sieht in etwa so aus:

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials strimzi-cluster --region us-central1"

Autopilot

Das folgende Diagramm zeigt einen privaten regionalen Autopilot-GKE-Cluster:

Führen Sie die folgenden Befehle in der Cloud Shell aus, um die Infrastruktur bereitzustellen:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=kafka/terraform/gke-autopilot init
terraform -chdir=kafka/terraform/gke-autopilot apply -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Geben Sie bei Aufforderung yes ein. Es kann einige Minuten dauern, bis dieser Befehl abgeschlossen ist und der Cluster den Status „Bereit“ anzeigt.

Terraform erstellt die folgenden Ressourcen:

VPC-Netzwerk und privates Subnetz für die Kubernetes-Knoten.
Ein Router für den Zugriff auf das Internet über NAT.
Ein privater GKE-Cluster in der Region us-central1.
Ein ServiceAccount mit Logging- und Monitoring-Berechtigungen.
Google Cloud Managed Service for Prometheus für das Clustermonitoring.

Die Ausgabe sieht in etwa so aus:

...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials strimzi-cluster --region us-central1"

Verbindung zum Cluster herstellen

Konfigurieren Sie kubectl für die Kommunikation mit dem Cluster:

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}

Stellen Sie den Strimzi-Operator in Ihrem Cluster bereit:

In diesem Abschnitt stellen Sie den Strimzi-Operator mit einem Helm-Diagramm bereit. Es gibt auch mehrere andere Möglichkeiten zur Bereitstellung von Strimzi.

Fügen Sie das Strimzi-Helm-Diagramm-Repository hinzu:

helm repo add strimzi https://strimzi.io/charts/

Fügen Sie einen Namespace für den Strimzi-Operator und den Kafka-Cluster hinzu:
```
kubectl create ns kafka
```
Stellen Sie den Strimzi-Clusteroperator mit Helm bereit:
```
helm install strimzi-operator strimzi/strimzi-kafka-operator -n kafka
```
Wenn Sie Strimzi-Clusteroperatoren und Kafka-Cluster in verschiedenen Namespaces bereitstellen möchten, fügen Sie dem Helm-Befehl den Parameter --set watchNamespaces="{kafka-namespace,kafka-namespace-2,...}" hinzu.

Prüfen Sie mit Helm, ob der Strimzi-Clusteroperator erfolgreich bereitgestellt wurde:

helm ls -n kafka

Die Ausgabe sieht in etwa so aus:

NAME            NAMESPACE    REVISION    UPDATED                              STATUS    CHART                        APP VERSION
strimzi-operator    kafka      1       2023-06-27 11:22:15.850545 +0200 CEST    deployed    strimzi-kafka-operator-0.35.0    0.35.0

Kafka bereitstellen

Nachdem der Operator im Cluster bereitgestellt wurde, können Sie eine Kafka-Clusterinstanz bereitstellen.

In diesem Abschnitt stellen Sie Kafka in einer grundlegenden Konfiguration bereit und testen dann verschiedene erweiterte Konfigurationsszenarien, um Anforderungen an Verfügbarkeit, Sicherheit und Beobachtbarkeit zu erfüllen.

Grundlegende Konfiguration

Die grundlegende Konfiguration für die Kafka-Instanz umfasst die folgenden Komponenten:

Drei Replikate von Kafka-Brokern, wobei mindestens zwei verfügbare Replikate für die Clusterkonsistenz erforderlich sind.
Drei Replikate von ZooKeeper-Knoten, die einen Cluster bilden.
Zwei Kafka-Listener: einer ohne Authentifizierung und einer mit TLS-Authentifizierung mit einem von Strimzi generierten Zertifikat.
Java MaxHeapSize und MinHeapSize sind auf 4 GB für Kafka und 2 GB für ZooKeeper festgelegt.
CPU-Ressourcenzuweisung von 1 CPU-Anfrage und 2 CPU-Limits für Kafka und ZooKeeper sowie 5 GB Arbeitsspeicheranfragen und Limits für Kafka (4 GB für den Hauptdienst und 0,5 GB für den Messwertexporter) und{ 101}2,5 GB für ZooKeeper (2 GB für den Hauptdienst und 0,5 GB für den Messwertexporter).
Entitätsoperator mit den folgenden Anfragen und Limits:
- tlsSidecar: 100 m/500 m CPU und 128 mi Arbeitsspeicher.
- topicOperator: 100 m/500 m CPU und 512 mi Arbeitsspeicher.
- userOperator: 500 m CPU und 2 GB Arbeitsspeicher.
100 GB Speicherplatz, der jedem Pod mithilfe von premium-rwo storageClass zugewiesen wird.
Toleranzen, nodeAffinities und podAntiAffinities für jede Arbeitslast, wodurch eine ordnungsgemäße Verteilung zwischen Knoten gewährleistet wird. Dabei werden die entsprechenden Knotenpools und verschiedene Zonen verwendet.
Kommunikation im Cluster, die durch selbst signierte Zertifikate gesichert ist: separate Zertifizierungsstellen (CAs) für Cluster und Clients (mTLS). Sie können auch eine andere Zertifizierungsstelle konfigurieren.

Diese Konfiguration stellt die minimale Einrichtung dar, die zum Erstellen eines produktionsfertigen Kafka-Clusters erforderlich ist. In den folgenden Abschnitten werden benutzerdefinierte Konfigurationen für unterschiedliche Aspekte wie die Clustersicherheit, Access Control Lists (ACLs), Themenverwaltung und Zertifikatsverwaltung vorgestellt.

Einfachen Kafka-Cluster erstellen

Erstellen Sie mithilfe der grundlegenden Konfiguration einen neuen Kafka-Cluster:
```
kubectl apply -n kafka -f kafka-strimzi/manifests/01-basic-cluster/my-cluster.yaml
```
Dieser Befehl erstellt eine benutzerdefinierte Kafka-Ressource des Strimzi-Operators, die CPU- und Arbeitsspeicheranfragen und -limits, Blockspeicheranfragen und eine Kombination aus Markierungen und Affinitäten enthält, um die bereitgestellten Pods auf Kubernetes-Knoten zu verteilen.
Warten Sie einige Minuten, während Kubernetes die erforderlichen Arbeitslasten startet:
```
kubectl wait kafka/my-cluster --for=condition=Ready --timeout=600s -n kafka
```

Prüfen Sie, ob die Kafka-Arbeitslasten erstellt wurden:

kubectl get pod,service,deploy,pdb -l=strimzi.io/cluster=my-cluster -n kafka

Die Ausgabe sieht in etwa so aus:

NAME                                            READY   STATUS  RESTARTS   AGE
pod/my-cluster-entity-operator-848698874f-j5m7f   3/3   Running   0        44m
pod/my-cluster-kafka-0                          1/1   Running   0        5m
pod/my-cluster-kafka-1                          1/1   Running   0        5m
pod/my-cluster-kafka-2                          1/1   Running   0        5m
pod/my-cluster-zookeeper-0                      1/1   Running   0        6m
pod/my-cluster-zookeeper-1                      1/1   Running   0        6m
pod/my-cluster-zookeeper-2                      1/1   Running   0        6m

NAME                                TYPE      CLUSTER-IP   EXTERNAL-IP   PORT(S)                             AGE
service/my-cluster-kafka-bootstrap  ClusterIP   10.52.8.80   <none>      9091/TCP,9092/TCP,9093/TCP          5m
service/my-cluster-kafka-brokers    ClusterIP   None         <none>      9090/TCP,9091/TCP,9092/TCP,9093/TCP   5m
service/my-cluster-zookeeper-client   ClusterIP   10.52.11.144   <none>      2181/TCP                            6m
service/my-cluster-zookeeper-nodes  ClusterIP   None         <none>      2181/TCP,2888/TCP,3888/TCP          6m

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-cluster-entity-operator   1/1   1          1         44m

NAME                                            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
poddisruptionbudget.policy/my-cluster-kafka     2             N/A             1                   5m
poddisruptionbudget.policy/my-cluster-zookeeper   2             N/A             1                   6m

Der Operator erstellt die folgenden Ressourcen:

Zwei StrimziPodSets für Kafka und ZooKeeper.
Drei Pods für Kafka-Broker-Replikate.
Drei Pods für ZooKeeper-Replikate.
Zwei PodDisruptionBudgets, wobei eine minimale Verfügbarkeit von zwei Replikaten für die Clusterkonsistenz gewährleistet ist.
Ein Dienst mit dem Namen my-cluster-kafka-bootstrap, der als Bootstrap-Server für Kafka-Clients dient, die eine Verbindung innerhalb des Kubernetes-Clusters herstellen. In diesem Dienst sind alle internen Kafka-Listener verfügbar.
Ein monitorloser Service mit dem Namen my-cluster-kafka-brokers, der die DNS-Auflösung von Kafka-Broker-Pod-IP-Adressen direkt aktiviert. Dieser Dienst wird für die Interbroker-Kommunikation verwendet.
Ein Service namens my-cluster-zookeeper-client, mit dem Kafka-Broker eine Verbindung zu ZooKeeper-Knoten als Clients herstellen können.
Ein monitorloser Service mit dem Namen my-cluster-zookeeper-nodes, der die DNS-Auflösung von ZooKeeper-Pod-IP-Adressen direkt ermöglicht. Dieser Dienst wird für die Verbindung zwischen ZooKeeper-Replikaten verwendet.
Ein Deployment mit dem Namen my-cluster-entity-operator, das den Themen- und Nutzeroperator enthält und die Verwaltung der benutzerdefinierten Ressourcen KafkaTopics und KafkaUsers erleichtert.

Sie können auch zwei NetworkPolicies konfigurieren, um die Verbindung zu Kafka-Listenern von jedem Pod und Namespace aus zu ermöglichen. Diese Richtlinien beschränken auch Verbindungen zu ZooKeeper auf Broker und ermöglichen die Kommunikation zwischen den Cluster-Pods und internen Service-Ports, die ausschließlich für die Clusterkommunikation gelten.

Authentifizierung und Nutzerverwaltung

In diesem Abschnitt erfahren Sie, wie Sie die Authentifizierung und Autorisierung aktivieren, um Kafka-Listener zu sichern und Anmeldedaten mit Clients zu teilen.

Strimzi bietet eine Kubernetes-native Methode für die Nutzerverwaltung mit einem separaten User Operator und der entsprechenden benutzerdefinierten Kubernetes-Ressource, KafkaUser, zur Definition der Nutzerkonfiguration. Die Nutzerkonfiguration enthält Einstellungen für die Authentifizierung und Autorisierung und stellt den entsprechenden Nutzer in Kafka bereit.

Strimzi kann Kafka-Listener und Nutzer erstellen, die mehrere Authentifizierungsmechanismen wie Nutzername und passwortbasierte Authentifizierung (SCRAM-SHA-512) oder TLS unterstützen. Sie können auch die OAuth 2.0-Authentifizierung verwenden. Diese ist im Vergleich zur Verwendung von Passwörtern oder Zertifikaten zur Authentifizierung aufgrund der Verwaltung von Sicherheits- und externen Anmeldedaten oft ein besserer Ansatz.

Kafka-Cluster bereitstellen

In diesem Abschnitt erfahren Sie, wie Sie einen Strimzi-Operator bereitstellen, der Funktionen zur Nutzerverwaltung zeigt, darunter:

Ein Kafka-Cluster mit passwortbasierter Authentifizierung (SCRAM-SHA-512), der für einen der Listener aktiviert ist.
Ein KafkaTopic mit drei Replikaten.
Eine KafkaUser mit einer ACL, die angibt, dass der Nutzer Lese- und Schreibberechtigungen für das Thema hat.

Konfigurieren Sie Ihren Kafka-Cluster so, dass ein Listener mit passwortbasierter SCRAM-SHA-512-Authentifizierung auf Port 9094 und einfacher Autorisierung verwendet wird:
```
kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/my-cluster.yaml
```
Erstellen Sie einen Topic, User und einen Client-Pod, um Befehle für den Kafka-Cluster auszuführen:
```
kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/topic.yaml
kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/my-user.yaml
```
Der Secret my-user mit den Nutzeranmeldedaten wird als Volume auf dem Client-Pod bereitgestellt.

Diese Anmeldedaten bestätigen, dass der Nutzer berechtigt ist, Nachrichten für das Thema mit dem Listener zu veröffentlichen, bei dem die passwortbasierte Authentifizierung (SCRAM-SHA-512) aktiviert ist.

Erstellen Sie einen Client-Pod:

kubectl apply -n kafka -f kafka-strimzi/manifests/03-auth/kafkacat.yaml

Warten Sie einige Minuten, bis der Client-Pod Ready wird, und stellen Sie dann eine Verbindung zu ihm her:

kubectl wait --for=condition=Ready pod --all -n kafka --timeout=600s
kubectl exec -it kafkacat -n kafka -- /bin/sh

Erstellen Sie eine neue Nachricht mit my-user-Anmeldedaten und versuchen Sie, sie zu verarbeiten:

echo "Message from my-user" |kcat \
  -b my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9094 \
  -X security.protocol=SASL_SSL \
  -X sasl.mechanisms=SCRAM-SHA-512 \
  -X sasl.username=my-user \
  -X sasl.password=$(cat /my-user/password) \
  -t my-topic -P
kcat -b my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9094 \
  -X security.protocol=SASL_SSL \
  -X sasl.mechanisms=SCRAM-SHA-512 \
  -X sasl.username=my-user \
  -X sasl.password=$(cat /my-user/password) \
  -t my-topic -C

Die Ausgabe sieht in etwa so aus:

Message from my-user
% Reached end of topic my-topic [0] at offset 0
% Reached end of topic my-topic [2] at offset 1
% Reached end of topic my-topic [1] at offset 0

Geben Sie CTRL+C ein, um den Nutzervorgang zu beenden.

Beenden Sie die Pod-Shell
```
exit
```

Sicherungen und Notfallwiederherstellung

Der Strimzi-Operator bietet zwar keine integrierte Sicherungsfunktion, aber Sie können effiziente Sicherungsstrategien nach bestimmten Mustern implementieren.

Sie können Sicherung für GKE verwenden, um Folgendes zu sichern:

Kubernetes-Ressourcenmanifeste
Benutzerdefinierte Ressourcen der Strimzi API und ihre Definitionen, die vom Kubernetes API-Server des Clusters extrahiert wurden, der die Sicherung ausführt.
Volumes, die PersistentVolumeClaim-Ressourcen in den Manifesten entsprechen.

Weitere Informationen zum Sichern und Wiederherstellen von Kafka-Clustern mit Sicherung für GKE finden Sie unter Notfallwiederherstellung vorbereiten.

Sie können auch eine Sicherung eines Kafka-Clusters durchführen, der mit dem Strimzi-Operator bereitgestellt wurde. Sichern Sie Folgendes:

Die Kafka-Konfiguration, die alle benutzerdefinierten Ressourcen der Straimzi API wie KafkaTopics und KafkaUsers enthält.
Die Daten, die in den PersistentVolumes der Kafka-Broker gespeichert werden.

Da Kubernetes-Ressourcenmanifeste, einschließlich Strimzi-Konfigurationen, in Git-Repositories gespeichert werden, ist keine separate Sicherung für die Kafka-Konfiguration erforderlich, da die Ressourcen bei Bedarf auf einen neuen Kubernetes-Cluster noch einmal angewendet werden können.

Zum Schutz der Kafka-Datenwiederherstellung in Szenarien, in denen eine Kafka-Serverinstanz oder ein Kubernetes-Cluster, in dem Kafka bereitgestellt wird, verloren geht, sollten Sie die Kubernetes-Speicherklasse konfigurieren, die zum Bereitstellen von Volumes für Kafka-Broker verwendet wird. Die Option reclaimPolicy ist auf Retain gesetzt. Außerdem empfehlen wir, Snapshots von Kafka-Broker-Volumes zu erstellen.

Das folgende Manifest beschreibt eine StorageClass, die die reclaimPolicy-Option Retain verwendet:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-rwo-retain
...
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

Das folgende Beispiel zeigt die StorageClass, die der spec einer benutzerdefinierten Kafka-Clusterressource hinzugefügt wird:

# ...
spec:
  kafka:
    # ...
    storage:
      type: persistent-claim
      size: 100Gi
      class: premium-rwo-retain

Bei dieser Konfiguration werden PersistentVolumes, die mit der Speicherklasse bereitgestellt werden, nicht gelöscht, auch wenn der entsprechende PersistentVolumeClaim gelöscht wird.

So stellen Sie die Kafka-Instanz auf einem neuen Kubernetes-Cluster mithilfe der vorhandenen Konfigurations- und Broker-Instanzdaten wieder her:

Wenden Sie die vorhandenen benutzerdefinierten Strimzi-Kafka-Ressourcen (Kakfa, KafkaTopic, KafkaUser usw.) auf einen neuen Kubernetes-Cluster an.
Aktualisieren Sie die PersistentVolumeClaims mit dem Namen der neuen Kafka-Broker-Instanzen auf die alten PersistentVolumes mit dem Attribut spec.volumeName im PersistentVolumeClaim.

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 Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Einzelne Ressourcen löschen

Wenn Sie ein vorhandenes Projekt verwendet haben und es nicht löschen möchten, können Sie die einzelnen Ressourcen löschen.

Umgebungsvariablen festlegen

export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=kafka
export REGION=us-central1

Führen Sie den Befehl terraform destroy aus:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=kafka/terraform/FOLDER destroy -var project_id=${PROJECT_ID}   \
  -var region=${REGION}  \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Ersetzen Sie FOLDER durch gke-autopilot oder gke-standard.

Geben Sie bei Aufforderung yes ein.

Alle nicht angehängten Laufwerke suchen:
```
export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
```
Dieser Schritt ist erforderlich, da Strimzi standardmäßig den Parameter deleteClaim: false zur Speicherung verwendet. Wenn Sie den Cluster löschen, bleiben alle Laufwerke verfügbar.

Laufwerke löschen:

for i in $disk_list; do
  disk_name=$(echo $i| cut -d'|' -f1)
  disk_zone=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
  echo "Deleting $disk_name"
  gcloud compute disks delete $disk_name --zone $disk_zone --quiet
done

Nächste Schritte

Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center

Apache Kafka mit Strimzi in GKE bereitstellen

Lernziele

Vorteile

Bereitstellungsarchitektur

Verfügbarkeit und Notfallwiederherstellung

Bereitstellungsdiagramm

Benutzerdefinierte Ressource StrimziPodSet

Kosten

Hinweise

Umgebung vorbereiten

Clusterinfrastruktur erstellen

Standard

Autopilot

Verbindung zum Cluster herstellen

Stellen Sie den Strimzi-Operator in Ihrem Cluster bereit:

Kafka bereitstellen

Grundlegende Konfiguration

Einfachen Kafka-Cluster erstellen

Authentifizierung und Nutzerverwaltung

Kafka-Cluster bereitstellen

Sicherungen und Notfallwiederherstellung

Bereinigen

Projekt löschen

Einzelne Ressourcen löschen

Nächste Schritte

Benutzerdefinierte Ressource `StrimziPodSet`