Im letzten Teil dieser Artikelserie zu KubeEdge wird in einem Beispiel gezeigt, wie Daten von einem Sensor über die Edge bis hin zur Cloud gesendet werden. Die gesendeten Daten werden in der Cloud in einer Time Series Database abgelegt und anschließend über Grafana visualisiert.

Im ersten Artikel wurde der Aufbau und die Funktionsweise von KubeEdge beschrieben. Im zweiten Teil wurde KubeEdge deployed. Es wurde ein Kubernetes Cluster aufgesetzt in dem der CloudCore deployed wurde. Der EdgeCore wurde auf einer virtuellen Maschine als Systemdienst gestartet.

Anwendungsfall

Abbildung Ansicht Grafana

Im Anwendungsfall wird die CPU-Temperatur oder ein simulierter Wert erhoben und über MQTT an den EdgeCore gesendet. Der EdgeCore überträgt die Daten mit einem zusätzlichen MQTT Topic an die Kubernetes Cloud. Der DeviceController des CloudCores trägt die Daten daraufhin in die entsprechende Kubernetes-Ressource ein. Ein weiteres Programm, das ebenfalls im Cluster ausgeführt wird, speichert sie in einer Timeseries Datenbank und Grafana visualisiert sie in einem Dashboard – wie in der Abbildung „Grafana Ansicht„ dargestellt.

Komponenten Deployment

Komponenten Deployment

Insgesamt müssen für den Anwendungsfall vier Programmen auf der Edge oder der Cloud deployed werden. Die Abbildung „Komponenten Deployment” zeigt, wo die Systeme deployed werden.

 

 

 

Funktionsweise und Grenzen des Anwendungsfalles

kubeedge-database

Die kubeedge-database Applikation wird die Daten aus den Ressourcen auslesen und in die Datenbank eintragen. Dafür werden die Device-Ressourcen abgerufen, die im vorherigen Artikel angelegt wurden. Über die Kubernetes API werden die Daten ausgelesen und in die Datenbank überführt.. Die nachfolgende Tabelle definiert, was die einzelnen Spalten für eine Bedeutung haben.

ColumnDatentypBeschreibung
timeTimestampZeitstempel der Datenerhebung.
valueTextWert des Sensors.
namespaceTextKubernetes Namespace des Devices.
sensorTextName des Sensors.
activeBoolDieser Wert zeigt an ob ein Device noch aktiv ist oder gelöscht wurde.
deviceTextDevice Name

 

Durch den Namespace, den Namen und das Device kann jeder Sensor eindeutig zugeordnet werden. Die eindeutige Zuordnung eines jeden Sensors hilft bei der Visualisierung der Daten in Grafana. Die Tabelle wird automatisiert beim Starten des Programms angelegt.

Grafana

Grafana ist ein Open Source Tool, das Daten über Dashboards visualisiert. Es wird häufig in Verbindung mit dem Monitoring Tool Prometheus eingesetzt. In diesem Anwendungsfall wird anstatt des Prometheus Backends ein PostgreSQL ausgewählt. Die Daten aus der PostgreSQL können so direkt in einen Graphen visualisiert werden. Die Verwendung von Variablen in der Abfrage ermöglicht es, die Anfrage auf unterschiedliche Devices und Sensoren zu begrenzen. Damit die Daten in einem Graphen angezeigt werden können, müssen sie zu einem Zahlenwert konvertiert werden. PostgreSQL / TimescaleDB

PostgreSQL ist ein Datenbankmanagement-System auf Open-Source-Basis, ähnlich wie MySQL oder MariaDB. In diesem Anwendungsfall wurde PostgreSQL verwendet, da es über das Plugin „TimescaleDB” nativ Zeitreihen unterstützt. Die Datenbank wird in Kubernetes  ohne persistente Speicherung der Daten betrieben. Wird die Datenbankinstanz also neugestartet, können alle Daten verloren sein. Für eine produktive Datenbank sollte daher auf die Persistierung der Daten geachtet werden, bspw. durch ein externes Speichermedium.

Sensor

Der Sensor ist in diesem Fall ein Programm, welches über das Tool „lm-sensors” die CPU Temperatur ausliest oder Zufallszahlen generiert. Die Daten werden im Anschluss an den MQTT-Broker übertragen. Der Sensor arbeitet mit zwei Werten: die CPU-Temperatur, die dem entsprechenden gemessenen oder generierten Wert entspricht, und die die CPU-ID. Letzterer Wert wird im aktuellen Anwendungsfall nicht verwendet. Zwischen zwei gesendeten Werten vergehen in diesem Programm zehn Sekunden. Das Programm ist also in keinster Weise mit einem real existierenden Sensor vergleichbar, kann aber für erste Tests und ein Kennenlernen von KubeEdge gut verwendet werden.

Umsetzung Anwendungsfall

In diesem Abschnitt werden die Programme auf den entsprechenden Systemen deployed.  Für die Interaktion mit dem Kubernetes Cluster wird das bekannte Tool “kubectl” verwendet.

PostgreSQL / TimescaleDB

Zuerst wird die Datenbank im Cluster deployed, da einige andere Dienste auf dieser Aufbauen. Zum Deployen kann das nachfolgende Manifest genutzt werden. In der Ressource wird automatisch ein Passwort für die Datenbank angelegt, das auf ein entsprechend sicheres Passwort geändert werden sollte. Die Datenbank wird als Kubernetes Deployment erstellt und ein Service für die interne Kommunikation angelegt.

 

Dieser Abschnitt beschreibt das Anlegen unterschiedlicher Rollen, die für einzelne Datenbanken genutzt werden sollen. Das Einrichten der Datenbankschemata wird über den “kubectl exec” Befehl durchgeführt. Dieser erlaubt es, andere Befehle direkt im Container eines Pods auszuführen. Eine Alternative wäre das Erstellen eines Kubernetes Jobs um die Datenbankschemata zu erstellen.

 

kubeedge-database

Abschließend wird die kubeedge-database Applikation gestartet und ebenfalls im Cluster deployed. Hierzu kann einfach die in dem Repository https://github.com/subpathdev/kubeedge-database liegende Definition verwendet werden. Im Anschluss muss noch das Passwort für die Datenbank und der entsprechende Nutzer gesetzt werden. Der Nachfolgende Codeblock zeigt, wie das Deployment ausgeführt wird. Für die Eingabe des Nutzers und des Passwortes wird in dem Codeblock der zuvor bereits angelegte Nutzer mit seinem Passwort gesetzt.

 

View (Edge-Applikation)

Zum Visualisieren wird Grafana deployed. Grafana ist in diesem Deployment so definiert, dass es zur Datensicherung die Datenbank verwendet. Das Grafana Deployment ist ebenfalls im Github Repository verfügbar und kann mit folgendem Befehl auf das Cluster deployed werden. Hier sollte das Passwort entsprechend angepasst werden. Das Administrator-Passwort für Grafana wird auf verryStrongPassword gesetzt.

 

Nun kann über die Adresse des Master-Nodes und dem Port 30975 auf Grafana zugegriffen werden. Es existiert aktuell nur ein Nutzer (admin) mit dem Passwort „verryStrongPassword”. Hier muss eine neue Datenbankverbindung angelegt werden. Dazu wird „Create your first data source” ausgewählt. Als Datenquellen wird PostgreSQL selektiert. Für die Konfigurationen dient nachfolgende Tabelle als Hilfe.

 

KonfigurationWert
Hosttimescale.default.svc.cluster.local
Databasedemo
Userkubeedge
Passwortkubeedge
SSL-Modedisable

 

Nach dem Anlegen der Datenverbindung werden die Dashboards erstellt. Am einfachsten ist es, die beiden Dashboards über die folgenden Befehle herunterzuladen und in Grafana zu importieren.

Über das Plus-Symbol kann der Import der Dashboards ausgewählt werden. Mit „Upload .json” können die Devices.json- und Sensor.json-Dateien in Grafana importiert werden. In der Abbildung “Dashboard hinzufügen” ist dieser Schritt visualisiert.

 

Screenshot: Dashboard hinzufügen in Grafana

Dashboard hinzufügen

Sensor

Zum Abschluss des Installationsabschnitts wird der Sensor auf dem Edge und im Cluster deployed. Die Anwendung steht als Container zur Verfügung sodass diese mit den CLI-Parametern gestartet werden kann. Die Parameter sind in der nachfolgenden Tabelle mit einer Beschreibung definiert.

ParameterBeschreibung
deviceIDSetzt die DeviceID. Diese ist beim Anlegen der Kubernetes-Ressource von Bedeutung. Der Standardwert für die Device ID ist: “43098512438508132096394-a41fcb”
ipAddressIst die IP-Adresse des MQTT-Brokers inkluse des Ports. Der Standardwert ist hier „tcp://127.0.0.1:1884”.
userEinige MQTT-Broker unterstützen User-Password-basierte Authentifizierung. Der MQTT-Nutzer wird mit dieser Flag gesetzt.
passwordIst das Passwort, welches zum MQTT-Nutzer gehört
simulateDie Daten werden nicht mithilfe des Tools lm-sensors ausgelesen. Stattdessen werden random-Daten generiert und an den Broker gesendet.

Die beiden nachfolgenden Befehle zeigen, wie das Programm gestartet und das Device im Cluster angelegt wird. Zum Starten wird auf einer nicht-virtuellen Edge folgender Befehl verwendet: „docker run subpathdev/cpu_temp_mqtt_client:v0.1 -deviceID cpu-sensor-01”

Sollte eine virtuelle Edge verwendet werden, wird zusätzlich noch das „simulate”-Flag gesetzt:

„docker run subpathdev/cpu_temp_mqtt_client:v0.1 -deviceID cpu-sensor-01 -simulate”

Zum Anlegen des Devices wird zuerst ein DeviceModel erstellt. Dieses kann kann einfach aus dem Repository „https://github.com/subpathdev/CpuTempMqttClient/” entnommen werden.

 

 

Nun wird alle zehn Sekunden ein Wert gemessen bzw. generiert. Dieser Wert wird an den MQTT-Broker gesendet, dann an die Kubernetes API übertragen, in der Datenbank gespeichert und über Grafana visualisiert.

Bei Fragen oder Anmerkungen kann die KubeEdge Community wie folgt erreicht werden:

Quellen

 

Die Inhalte dieser Arbeit stammen aus dem Projekt KOSMoS – Kollaborative Smart Contracting Plattform für digitale Wertschöpfungsnetze. Dieses Forschungs- und Entwicklungsprojekt wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) im Programm „Innovationen für die Produktion, Dienstleistung und Arbeit von morgen“ (Förderkennzeichen 02P17D026) gefördert und vom Projektträger Karlsruhe (PTKA) betreut. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autor:innen.