Bestimmen der geeigneten Größe für einen Kafka-Cluster in Kubernetes

Notiz. übersetzen: In diesem Artikel zeigt Banzai Cloud ein Beispiel dafür, wie seine benutzerdefinierten Tools verwendet werden können, um die Verwendung von Kafka in Kubernetes zu vereinfachen. Die folgenden Anweisungen veranschaulichen, wie Sie die optimale Größe Ihrer Infrastruktur ermitteln und Kafka selbst konfigurieren können, um den erforderlichen Durchsatz zu erreichen.

Apache Kafka ist eine verteilte Streaming-Plattform zum Erstellen zuverlässiger, skalierbarer und leistungsstarker Echtzeit-Streaming-Systeme. Seine beeindruckenden Fähigkeiten können mit Kubernetes erweitert werden. Dafür haben wir entwickelt Open-Source-Kafka-Betreiber und ein Werkzeug namens Superröhren. Sie ermöglichen es Ihnen, Kafka auf Kubernetes auszuführen und seine verschiedenen Funktionen zu nutzen, wie z. B. die Feinabstimmung der Broker-Konfiguration, metrikbasierte Skalierung mit Rebalancing, Rack-Awareness, „Soft“ (anmutig) Ausrollen von Updates usw.

Probieren Sie Supertubes in Ihrem Cluster aus:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Oder kontaktieren Sie uns Dokumentation. Sie können sich auch über einige der Fähigkeiten von Kafka informieren, dessen Arbeit mithilfe von Supertubes und dem Kafka-Operator automatisiert wird. Wir haben bereits im Blog darüber geschrieben:

• Ach nein! Noch ein weiterer Kafka-Operator für Kubernetes;
• Überwachen und betreiben Sie Kafka basierend auf Prometheus-Metriken;
• Kafka-Rack-Bewusstsein auf Kubernetes;
• Apache Kafka über Istio ausführen – Benchmark;
• Benutzerauthentifizierte und zugriffskontrollierte Cluster mit dem Kafka-Operator;
• Rollendes Kafka-Upgrade und dynamische Konfiguration auf Kubernetes;
• Envoy-Protokollfilter für Kafka, vermascht.

Wenn Sie sich für die Bereitstellung eines Kafka-Clusters auf Kubernetes entscheiden, stehen Sie wahrscheinlich vor der Herausforderung, die optimale Größe der zugrunde liegenden Infrastruktur zu bestimmen und Ihre Kafka-Konfiguration an die Durchsatzanforderungen anzupassen. Die maximale Leistung jedes Brokers wird durch die Leistung der zugrunde liegenden Infrastrukturkomponenten wie Speicher, Prozessor, Festplattengeschwindigkeit, Netzwerkbandbreite usw. bestimmt.

Idealerweise sollte die Brokerkonfiguration so sein, dass alle Infrastrukturelemente optimal genutzt werden. Im wirklichen Leben ist dieser Aufbau jedoch recht komplex. Es ist wahrscheinlicher, dass Benutzer Broker so konfigurieren, dass sie die Nutzung einer oder zweier Komponenten (Festplatte, Speicher oder Prozessor) maximieren. Im Allgemeinen zeigt ein Broker dann seine maximale Leistung, wenn seine Konfiguration es ermöglicht, die langsamste Komponente in vollem Umfang zu nutzen. Auf diese Weise können wir eine ungefähre Vorstellung davon bekommen, welche Belastung ein Broker bewältigen kann.

Theoretisch können wir auch die Anzahl der Broker abschätzen, die zur Bewältigung einer bestimmten Last erforderlich sind. In der Praxis gibt es jedoch so viele Konfigurationsmöglichkeiten auf unterschiedlichen Ebenen, dass es sehr schwierig (wenn nicht unmöglich) ist, die potenzielle Leistung einer bestimmten Konfiguration zu bewerten. Mit anderen Worten: Es ist sehr schwierig, eine Konfiguration basierend auf einer bestimmten Leistung zu planen.

Für Supertubes-Benutzer verfolgen wir normalerweise den folgenden Ansatz: Wir beginnen mit einer Konfiguration (Infrastruktur + Einstellungen), messen dann deren Leistung, passen die Broker-Einstellungen an und wiederholen den Vorgang erneut. Dies geschieht so lange, bis die langsamste Komponente der Infrastruktur vollständig ausgelastet ist.

Auf diese Weise erhalten wir eine klarere Vorstellung davon, wie viele Broker ein Cluster benötigt, um eine bestimmte Last zu bewältigen (die Anzahl der Broker hängt auch von anderen Faktoren ab, z. B. der Mindestanzahl von Nachrichtenreplikaten zur Gewährleistung der Ausfallsicherheit und der Anzahl der Partitionen). Führungskräfte usw.). Darüber hinaus gewinnen wir Erkenntnisse darüber, welche Infrastrukturkomponenten eine vertikale Skalierung erfordern.

In diesem Artikel geht es um die Schritte, die wir unternehmen, um die langsamsten Komponenten in Erstkonfigurationen optimal zu nutzen und den Durchsatz eines Kafka-Clusters zu messen. Eine hochbelastbare Konfiguration erfordert mindestens drei laufende Broker (min.insync.replicas=3), verteilt auf drei verschiedene Barrierefreiheitszonen. Zur Konfiguration, Skalierung und Überwachung der Kubernetes-Infrastruktur nutzen wir unsere eigene Container-Management-Plattform für Hybrid Clouds – Pipeline. Es unterstützt On-Premise (Bare Metal, VMware) und fünf Arten von Clouds (Alibaba, AWS, Azure, Google, Oracle) sowie jede beliebige Kombination davon.

Gedanken zur Kafka-Cluster-Infrastruktur und -Konfiguration

Für die folgenden Beispiele haben wir AWS als Cloud-Anbieter und EKS als Kubernetes-Distribution ausgewählt. Eine ähnliche Konfiguration kann mit implementiert werden P.K.E. - Kubernetes-Distribution von Banzai Cloud, zertifiziert von CNCF.

Fahren

Amazon bietet verschiedene an EBS-Volume-Typen. Im Kern gp2 и io1 Um einen hohen Durchsatz zu gewährleisten, gibt es jedoch SSD-Laufwerke gp2 verbraucht angesammelte Credits (I/O-Credits), also bevorzugten wir den Typ io1, was einen konstant hohen Durchsatz bietet.

Instanztypen

Die Leistung von Kafka hängt stark vom Seitencache des Betriebssystems ab, daher benötigen wir Instanzen mit ausreichend Speicher für die Broker (JVM) und den Seitencache. Beispiel c5.2xgroß - ein guter Anfang, da es über 16 GB Speicher verfügt und optimiert für die Arbeit mit EBS. Sein Nachteil besteht darin, dass er alle 30 Stunden nur maximal 24 Minuten lang maximale Leistung erbringen kann. Wenn Ihre Arbeitslast über einen längeren Zeitraum Spitzenleistung erfordert, sollten Sie möglicherweise andere Instanztypen in Betracht ziehen. Genau das haben wir getan und dabei angehalten c5.4xgroß. Es bietet maximalen Durchsatz 593,75 Mbit/s. Maximaler Durchsatz eines EBS-Volumes io1 höher als die Instanz c5.4xgroßDaher dürfte der I/O-Durchsatz dieses Instanztyps das langsamste Element der Infrastruktur sein (was auch unsere Lasttests bestätigen sollten).

Netzwerk

Der Netzwerkdurchsatz muss im Vergleich zur Leistung der VM-Instanz und der Festplatte groß genug sein, sonst wird das Netzwerk zu einem Engpass. In unserem Fall die Netzwerkschnittstelle c5.4xgroß unterstützt Geschwindigkeiten von bis zu 10 Gbit/s, was deutlich höher ist als der I/O-Durchsatz einer VM-Instanz.

Broker-Bereitstellung

Broker sollten auf dedizierten Knoten bereitgestellt (in Kubernetes geplant) werden, um zu vermeiden, dass sie mit anderen Prozessen um CPU-, Speicher-, Netzwerk- und Festplattenressourcen konkurrieren.

Java-Version

Die logische Wahl ist Java 11, da es in dem Sinne mit Docker kompatibel ist, dass die JVM die Prozessoren und den verfügbaren Speicher für den Container, in dem der Broker ausgeführt wird, korrekt bestimmt. Da die JVM weiß, dass CPU-Grenzwerte wichtig sind, legt sie intern und transparent die Anzahl der GC-Threads und JIT-Threads fest. Wir haben das Kafka-Bild verwendet banzaicloud/kafka:2.13-2.4.0, die Kafka Version 2.4.0 (Scala 2.13) auf Java 11 enthält.

Wenn Sie mehr über Java/JVM auf Kubernetes erfahren möchten, schauen Sie sich unsere folgenden Beiträge an:

• Warum meine Java-Anwendung OOMKilled ist;
• So dimensionieren Sie Container für Java 10-Anwendungen richtig.

Broker-Speichereinstellungen

Bei der Konfiguration des Broker-Speichers gibt es zwei wichtige Aspekte: Einstellungen für die JVM und für den Kubernetes-Pod. Das für einen Pod festgelegte Speicherlimit muss größer sein als die maximale Heap-Größe, damit die JVM Platz für den Java-Metaspace hat, der sich in ihrem eigenen Speicher befindet, und für den Seitencache des Betriebssystems, den Kafka aktiv nutzt. In unseren Tests haben wir Kafka-Broker mit Parametern gestartet -Xmx4G -Xms2G, und das Speicherlimit für den Pod betrug 10 Gi. Bitte beachten Sie, dass Speichereinstellungen für die JVM automatisch mit abgerufen werden können -XX:MaxRAMPercentage и -X:MinRAMPercentage, basierend auf dem Speicherlimit für den Pod.

Einstellungen des Broker-Prozessors

Im Allgemeinen können Sie die Leistung verbessern, indem Sie die Parallelität erhöhen, indem Sie die Anzahl der von Kafka verwendeten Threads erhöhen. Je mehr Prozessoren für Kafka verfügbar sind, desto besser. In unserem Test haben wir mit einem Limit von 6 Prozessoren begonnen und deren Anzahl schrittweise (durch Iterationen) auf 15 erhöht num.network.threads=12 in den Broker-Einstellungen, um die Anzahl der Threads zu erhöhen, die Daten aus dem Netzwerk empfangen und senden. Als sie sofort feststellten, dass die Follower-Broker die Replikate nicht schnell genug erhalten konnten, meldeten sie sich num.replica.fetchers auf 4, um die Geschwindigkeit zu erhöhen, mit der Follower-Broker Nachrichten von Führungskräften replizieren.

Lastgenerierungstool

Sie sollten sicherstellen, dass die Kapazität des ausgewählten Lastgenerators nicht erschöpft ist, bevor der Kafka-Cluster (der einem Benchmarking unterzogen wird) seine maximale Last erreicht. Mit anderen Worten: Es ist notwendig, eine vorläufige Bewertung der Fähigkeiten des Lastgenerierungstools durchzuführen und auch Instanztypen dafür auszuwählen, die über eine ausreichende Anzahl von Prozessoren und Speicher verfügen. In diesem Fall erzeugt unser Tool mehr Last, als der Kafka-Cluster verarbeiten kann. Nach vielen Experimenten haben wir uns für drei Exemplare entschieden c5.4xgroß, von denen jeder einen Generator in Betrieb hatte.

Benchmarking

Die Leistungsmessung ist ein iterativer Prozess, der die folgenden Phasen umfasst:

• Aufbau der Infrastruktur (EKS-Cluster, Kafka-Cluster, Lastgenerierungstool sowie Prometheus und Grafana);
• Erzeugen einer Last für einen bestimmten Zeitraum, um zufällige Abweichungen in den gesammelten Leistungsindikatoren zu filtern;
• Anpassen der Infrastruktur und Konfiguration des Brokers basierend auf beobachteten Leistungsindikatoren;
• Wiederholen des Vorgangs, bis der erforderliche Kafka-Cluster-Durchsatz erreicht ist. Gleichzeitig muss es stets reproduzierbar sein und minimale Schwankungen im Durchsatz aufweisen.

Im nächsten Abschnitt werden die Schritte beschrieben, die während des Testcluster-Benchmarking-Prozesses durchgeführt wurden.

Werkzeuge

Die folgenden Tools wurden verwendet, um schnell eine Basiskonfiguration bereitzustellen, Lasten zu generieren und die Leistung zu messen:

• Banzai Cloud Pipeline für die Organisation eines EKS-Clusters von Amazon c Prometheus (um Kafka- und Infrastrukturmetriken zu sammeln) und Grafana (um diese Kennzahlen zu visualisieren). Wir haben es ausgenutzt integriert в Pipeline Dienste, die föderierte Überwachung, zentralisierte Protokollerfassung, Schwachstellen-Scans, Notfallwiederherstellung, Sicherheit auf Unternehmensniveau und vieles mehr bieten.
• Sangrenel – ein Tool zum Auslastungstest eines Kafka-Clusters.
• Grafana-Dashboards zur Visualisierung von Kafka-Metriken und -Infrastruktur: Kubernetes Kafka, Knotenexporteur.
• Supertubes CLI für die einfachste Möglichkeit, einen Kafka-Cluster auf Kubernetes einzurichten. Zookeeper, Kafka-Operator, Envoy und viele andere Komponenten sind installiert und ordnungsgemäß konfiguriert, um einen produktionsbereiten Kafka-Cluster auf Kubernetes auszuführen.
  • Zum Installieren Supertubes CLI Verwenden Sie die bereitgestellten Anweisungen hier.

EKS-Cluster

Bereiten Sie einen EKS-Cluster mit dedizierten Worker-Knoten vor c5.4xgroß in verschiedenen Verfügbarkeitszonen für Pods mit Kafka-Brokern sowie dedizierten Knoten für den Lastgenerator und die Überwachungsinfrastruktur.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

Sobald der EKS-Cluster betriebsbereit ist, aktivieren Sie seine Integration Überwachungsdienst – Sie wird Prometheus und Grafana in einem Cluster einsetzen.

Kafka-Systemkomponenten

Installieren Sie Kafka-Systemkomponenten (Zookeeper, Kafka-Operator) in EKS mithilfe der Supertubes-CLI:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Kafka-Cluster

Standardmäßig verwendet EKS EBS-Volumes vom Typ gp2Daher müssen Sie eine separate Speicherklasse basierend auf Volumes erstellen io1 für Kafka-Cluster:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

Legen Sie den Parameter für Broker fest min.insync.replicas=3 und stellen Sie Broker-Pods auf Knoten in drei verschiedenen Verfügbarkeitszonen bereit:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

Themen

Wir haben drei Lastgenerator-Instanzen parallel ausgeführt. Jeder von ihnen schreibt zu seinem eigenen Thema, d.h. wir brauchen insgesamt drei Themen:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

Für jedes Thema beträgt der Replikationsfaktor 3 – der empfohlene Mindestwert für hochverfügbare Produktionssysteme.

Lastgenerierungstool

Wir haben drei Kopien des Lastgenerators gestartet (jede davon wurde in einem separaten Thema geschrieben). Für Lastgenerator-Pods müssen Sie die Knotenaffinität so festlegen, dass sie nur auf den ihnen zugewiesenen Knoten geplant werden:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

Ein paar Punkte, die Sie beachten sollten:

• Der Lastgenerator generiert Nachrichten mit einer Länge von 512 Byte und veröffentlicht sie in Stapeln von 500 Nachrichten an Kafka.
• Ein Argument verwenden -required-acks=all Die Veröffentlichung gilt als erfolgreich, wenn alle synchronisierten Replikate der Nachricht von Kafka-Brokern empfangen und bestätigt wurden. Das bedeutet, dass wir im Benchmark nicht nur die Geschwindigkeit gemessen haben, mit der Führungskräfte Nachrichten erhalten, sondern auch die Geschwindigkeit, mit der ihre Follower Nachrichten reproduzieren. Der Zweck dieses Tests besteht nicht darin, die Lesegeschwindigkeit von Verbrauchern zu bewerten (Verbraucher) Kürzlich empfangene Nachrichten, die noch im Seitencache des Betriebssystems verbleiben, und Vergleich mit der Lesegeschwindigkeit der auf der Festplatte gespeicherten Nachrichten.
• Der Lastgenerator betreibt 20 Worker parallel (-workers=20). Jeder Worker enthält 5 Produzenten, die sich die Verbindung des Workers zum Kafka-Cluster teilen. Infolgedessen verfügt jeder Generator über 100 Produzenten, und alle senden Nachrichten an den Kafka-Cluster.

Überwachen des Zustands des Clusters

Während des Lasttests des Kafka-Clusters haben wir auch seinen Zustand überwacht, um sicherzustellen, dass es keine Pod-Neustarts, keine nicht synchronisierten Replikate und einen maximalen Durchsatz mit minimalen Schwankungen gab:

• Der Lastgenerator schreibt Standardstatistiken über die Anzahl der veröffentlichten Nachrichten und die Fehlerquote. Die Fehlerquote soll gleich bleiben 0,00%.
• Tempomat, bereitgestellt von kafka-operator, bietet ein Dashboard, in dem wir auch den Status des Clusters überwachen können. Um dieses Panel anzuzeigen, gehen Sie wie folgt vor:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISR-Ebene (Anzahl der „synchronisierten“ Replikate) Schrumpfung und Ausdehnung sind gleich 0.

Messergebnisse

3 Broker, Nachrichtengröße – 512 Byte

Durch die gleichmäßige Verteilung der Partitionen auf drei Broker konnten wir eine hohe Leistung erzielen ~500 Mbit/s (ungefähr 990 Nachrichten pro Sekunde):

Der Speicherverbrauch der virtuellen JVM-Maschine überschritt 2 GB nicht:

Der Festplattendurchsatz erreichte den maximalen E/A-Knotendurchsatz auf allen drei Instanzen, auf denen die Broker ausgeführt wurden:

Aus den Daten zur Speichernutzung durch Knoten geht hervor, dass die Systempufferung und das Caching etwa 10–15 GB beanspruchten:

3 Broker, Nachrichtengröße – 100 Byte

Wenn die Nachrichtengröße abnimmt, sinkt der Durchsatz um etwa 15–20 %: Die Zeit, die für die Verarbeitung jeder Nachricht aufgewendet wird, wirkt sich auf sie aus. Zudem hat sich die Prozessorlast fast verdoppelt.

Da Broker-Knoten noch über ungenutzte Kerne verfügen, kann die Leistung durch eine Änderung der Kafka-Konfiguration verbessert werden. Dies ist keine leichte Aufgabe. Um den Durchsatz zu erhöhen, ist es daher besser, mit größeren Nachrichten zu arbeiten.

4 Broker, Nachrichtengröße – 512 Byte

Sie können die Leistung eines Kafka-Clusters ganz einfach steigern, indem Sie einfach neue Broker hinzufügen und ein Gleichgewicht der Partitionen aufrechterhalten (dadurch wird sichergestellt, dass die Last gleichmäßig auf die Broker verteilt wird). In unserem Fall stieg der Cluster-Durchsatz nach dem Hinzufügen eines Brokers auf ~580 Mbit/s (~1,1 Millionen Nachrichten pro Sekunde). Das Wachstum fiel geringer aus als erwartet: Dies ist hauptsächlich auf das Ungleichgewicht der Partitionen zurückzuführen (nicht alle Broker arbeiten auf dem Höhepunkt ihrer Leistungsfähigkeit).

Der Speicherverbrauch der JVM-Maschine blieb unter 2 GB:

Die Arbeit von Brokern mit Laufwerken wurde durch das Ungleichgewicht der Partitionen beeinträchtigt:

Befund

Der oben vorgestellte iterative Ansatz kann erweitert werden, um komplexere Szenarien mit Hunderten von Verbrauchern, Neupartitionierung, fortlaufenden Updates, Pod-Neustarts usw. abzudecken. All dies ermöglicht es uns, die Grenzen der Fähigkeiten des Kafka-Clusters unter verschiedenen Bedingungen einzuschätzen, Engpässe in seinem Betrieb zu identifizieren und Wege zu finden, diese zu bekämpfen.

Wir haben Supertubes entwickelt, um schnell und einfach einen Cluster bereitzustellen, ihn zu konfigurieren, Broker und Themen hinzuzufügen/zu entfernen, auf Warnungen zu reagieren und sicherzustellen, dass Kafka im Allgemeinen ordnungsgemäß auf Kubernetes funktioniert. Unser Ziel ist es, Ihnen zu helfen, sich auf die Hauptaufgabe („Generieren“ und „Konsumieren“ von Kafka-Nachrichten) zu konzentrieren und die ganze harte Arbeit Supertubes und dem Kafka-Betreiber zu überlassen.

Wenn Sie an Banzai Cloud-Technologien und Open-Source-Projekten interessiert sind, abonnieren Sie das Unternehmen unter GitHub, LinkedIn oder Twitter.

PS vom Übersetzer

Lesen Sie auch auf unserem Blog:

• «Eine Geschichte mit dem Redis-Operator in K8s und eine Kurzübersicht über Dienstprogramme zur Analyse von Daten aus dieser Datenbank";
• «Nahtlose Migration von RabbitMQ zu Kubernetes";
• «zetcd von CoreOS: Ersetzen von ZooKeeper durch...etcd-Speicher".

Source: habr.com