Evolution of a Microservice-Infrastructure by Jan Martens | OSDC 2019

This entry is part 1 of 6 in the series OSDC 2019 | Recap

 

At the Open Source Data Center Conference (OSDC) 2019 in Berlin, Jan Martens invited to audience to travel with him in his talk „Evolution of a Microservice-Infrastructure”. You have missed him speaking? We got something for you: See the video of Jan‘s presentation and read a summary (below).

The former OSDC will be held for the first time in 2020 under the new name stackconf. With the changes in modern IT in recent years, the focus of the conference has increasingly shifted from a mainly static infrastructure approach to a broader spectrum that includes agile methods, continuous integration, container, hybrid and cloud solutions. This development is taken into account by changing the name of the conference and opening the topic area for further innovations.

Due to concerns around the coronavirus (COVID-19), the decision was made to hold stackconf 2020 as an online conference. The online event will now take place from June 16 to 18, 2020. Join us, live online! Save your ticket now at: stackconf.eu/ticket/


 

Evolution of a Microservice-Infrastructure

Jan Martens signed up with a talk titled “Evolution of a Microservice Infrastructure” and why should I summarize his talk if he had done that himself perfectly: “This talk is about our journey from Ngnix & Docker Swarm to Traefik & Nomad.”

But before we start getting more in depth with this talk, there is one more thing to know about it. This is more or less a sequel to “From Monolith to Microservices” by Paul Puschmann a colleague of Jan Martens, but it’s not absolutely necessary to watch them in order or both.

 

So there will be a bunch of questions answered by Jan during the talk, regarding their environment, like: “How do we do deployments? How do we do request routing? What problems did we encounter, during our infrastructural growth and how did we address them?”

After giving some quick insight in the scale he has to deal with, that being 345.000 employees and 15.000 shops, he goes on with the history of their infrastructure.

Jan works at REWE Digital, which is responsible for the infrastructure around services, like delivery of groceries. They started off with the takeover of an existing monolithic infrastructure, not very attractive huh? They confronted themselves with the question: “How can we scale this delivery service?” and the solution they came up with was a micro service environment. Important to point out here, would be the use of Docker/Swarm for the deployment of micro services.

Let’s skip ahead a bit and take a look at the state of 2018 REWE Digital. Well there operating custom Docker-Environment consists of: Docker, Consul, Elastic Stack, ngnix, dnsmasq and debian

Jan goes into explaining his infrastructure more and more and how the different applications work with each other, but let’s just say: Everything was fine and peaceful until the size of the environment grew to a certain point. And at that point problems with nginx were starting to surface, like requests which never reached their destination or keepalive connections, which dropped after a short time. The reason? Consul-template would reload all ngnix instances at the same time. The solution? Well they looked for a different reverse proxy, which is able to reload configuration dynamically and best case that new reverse proxy is even able to be configured dynamically.

The three being deemed fitting for that job were envoy, Fabio and traefik, but I have already spoiled their decision, its treafik. The points Jan mentioned, which had them decide on traefik were that it is dynamically configurable and is able to reload configuration live. That’s obviously not all, lots of metrics, a web ui, which was deemed nice by Jan and a single go binary, might have made the difference.

Jan drops a few words on how migration is done and then invests some time in talking about the benefits of traefik, well the most important benefit for us to know is, that the issues that existed with ngnix are gone now.

Well now that the environment was changed, there were also changes coming for swarm, acting on its own. The problems Jan addresses are a poor container spread, no self-healing, and more. You should be able to see where this is going. Well the candidates besides Docker Swarm are Rancher, Kubernetes and Nomad. Well, this one was spoiled by me as well.

The reasons to use nomad in this infrastructure might be pretty obvious, but I will list them anyway. Firstly, seamless consul integration, well both are by HashiCorp, who would have guessed. Nomad is able to selfheal and comes in a single go binary, just like traefik. Jan also claims it has a nice web UI, we have to take his word on that one.

Jan goes into the benefits of using Nomad, just like he went into the benefits of ngnix and shows how their work processes have changed with the change of their environment.

This post doesn’t give enough credit to how much information Jan has shared during his talk. Maybe roughly twenty percent of his talk are covered here. You should definitely check it out the full video to catch all the deeper more insightful topics about the infrastructure and how the applications work with each other.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.
NEU im Shop: AKCP LoRaWan Geräte für wireless Sensoren

NEU im Shop: AKCP LoRaWan Geräte für wireless Sensoren

Unser Shop ist schon lange eine Bezugsquelle für AKCP Produkte – viele unserer Kunden betreiben Geräte aus den Reihen sensorProbe, sensorProbe+ und securityProbe. Nun wollen wir Euch eine weitere AKCP-Serie anbieten, nämlich die LoRaWAN Gateways, mit denen die Nutzung von Funk-Sensoren umgesetzt wird.

L-DCIM Desktop-Version

Was ist LoRa™ Funktechnologie?

LoRaWAN ist die Abkürzung für Long Range Wide Area Network. Der Netzaufbau ist hierbei sternförmig und Endgeräte senden asymmetrisch an das entsprechende Gateway. Trotz höchster Energieeffizienz – Endgeräte können mit klug gewählten Standbyzeiten mehrere Jahre ohne Batteriewechsel auskommen – können Distanzen zwischen 2 und 40 km erzielt werden, letztere vor allem im ländlichen Bereich. Flächendeckende LoRaWAN-Netze wurden bereits in den Niederlanden, der Schweiz und Südkorea aufgebaut. Berlin hingegen ist laut wikipedia.org die Großstadt mit den weltweit meisten LoRaWAN-Installationen, aber auch Zürich, Bern und Amsterdam gehen hier stark in die Konkurrenz.

 

AKCP LoRa L-DCIM: Das Gateway für AKCP Funk-Sensoren

Das AKCP LoRa L-DCIM ist das Gateway, mit dem die Funk-Sensoren kommunizieren, um Werte zu übertragen. Diese Werte laufen in den integrierten AKCPro Server, die hauseigene Überwachungsplattform von AKCP. Mithilfe von Adaptern kann das L-DCIM auch herkömmliche, verkabelte Sensoren von AKCP nutzen oder aber auch mit Drittanbieter-Sensoren per SNMP oder Modbus kommunizieren. Weiterhin können auch binäre Detektoren wie Rauchmelder über Funkadapter mit potentialfreien Kontakten angeschlossen werden.

L-DCIM Rack-Version

Das AKCP LoRa L-DCIM ist bei uns in folgenden Varianten erhältlich:

  • als Desktopversion, die sich auch zur Wand- oder Hutschienenmontage eignet
  • als Desktopversion mit Material zur Hutschienenmontage
  • als Rack-Version mit 1HE für den Einbau in Standard-19″-Schränke
  • beide Geräte können mit 3G- oder 4G-Modem ausgestattet werden. Bitte kontaktiert uns in diesem Fall.

 

Was kann mit dem AKCP LoRa L-DCIM überwacht werden?

Für das AKCP LoRA L-DCIM gibt es Funk-Sensoren für folgende Anwendungsfälle:

  • Überwachung von Temperatur und Luftfeuchtigkeit
    • Hier wird ein Kombisensor angeboten, diesen gibt es optional auch mit einem zusätzlichen Kontakt, der das Öffnen und Schließen von Türen erkennen kann. Auch gibt es hier die Möglichkeit, den Kombisensor mit einem Verlegeradius von 1,5m zu beziehen.
  • Thermal Map und Cabinet Thermal Map
    • Diese bilden eine Sensorkette, die mit 3 bzw. 6 Kombisensoren zur Messung von Temperatur und Luftfeuchtigkeit ausgestattet ist.
  • Potentialfreie Eingänge
    • Dieser Adapter bietet 5 potentialfreie Eingänge, so dass entsprechende Geräte mit dem wireless Gateway gekoppelt werden können.
  • Sensor-Adapter
    • Dieser eignet sich zum Koppeln eines AKCP Detektors wir Rauchmeldern, Wasserleackagesensoren, Türkontakten, Wechselstromsensoren und Bewegungsmeldern.
  • Tank-Füllstand
    • Hier bietet AKCP einen Sensor zur Überwachung von Tank-Füllständen für Tanktiefen von 2 / 5 / 10 / 15 / 20 Metern.
  • Wassereinbruch und -leckage
    • Erkennung von Wassereinbrüchen und -leckage, auch erhältlich mit einem Verlegeradius von 1,5m für den Sensor.
  • Konvertierung von Analog auf Digital
    • Hiermit können analoge Sensor-Signale digital aufbereitet an das L-DCIM Gateway weitergegeben werden (zum Anschluss von bis zu 2 Sensoren für die Bereiche 4 – 20 mA oder 0 – 10 VDC).
  • Cabinet Analysis
    • Für den Rundumüberblick über Serverschränke: Es können pro Cabinet Analysis Sensor maximal 2 Thermal Map Sensoren und 2 Luftstromsensoren angeschlossen sowie 2 potentialfreie Eingänge für Türöffnungssensoren genutzt werden.
  • Modbus-Adapter
    • Insbesondere im IoT-Bereich kann dieser Adapter eingesetzt werden.

AKCPro Server

Durch die integrierte AKCPro Server Software, die selbstverständlich auch unabhängig vom L-DCIM Gateway genutzt werden kann, bleibt der Nutzer nicht beschränkt auf den Einsatz der obigen Sensoren und Anschlussmöglichkeiten. Es können folgende Sensoren und und Geräte per Lizenz integriert werden:

  • Virtuelle Sensoren
  • Virtuelle Modbus TCP/IP Sensoren
  • ONVIF IP Kamera
  • AKCP Geräte

Des Weiteren bietet AKCPro Server auch vielfältige Über- und Ansichten, wie z.B. schematische Darstellungen von Racks und Räumen und der Verteilung der entsprechenden Messpunkte. Besonders nützlich ist die Realtime-Aktualisierung von Daten und der Anzeigemöglichkeit auf Tablets, was z.B. für eine Begehung der entsprechenden Räumlichkeiten einen starken Mehrwert gibt. Eine Übersicht und Online-Demo bietet AKCP auf der Website zu AKCPro Server.

Rack-Übersicht in AKCPro Server

 

Selbstverständlich sind alle oben genannten Produkte und Lizenzen bei uns erhältlich. Solltet Ihr Fragen haben, dann sind wir jederzeit für Euch erreichbar per Mail: shop@netways.de oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team. Bleibt gesund – wir freuen uns auf Euch!

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...
Arbeiten und Leben im Homeoffice in Zeiten von Corona

Arbeiten und Leben im Homeoffice in Zeiten von Corona

Seit nun mehr als 7 Wochen befinden sich alle Kolleginnen und Kollegen im Homeoffice. Es ist das erste Mal, dass alle Mitarbeiter gleichzeitig von Zuhause arbeiten, und für viele ist es auch das allererste Mal Homeoffice. Der Start war, natürlich, etwas holprig, aber schon nach kurzer Zeit lief alles erstaunlich gut. Ich möchte hier einmal die Sicht eines Auszubildenden im Homeoffice beleuchten.

 

Die große Umstellung

Auf einmal stand in der Firma alles still und vieles änderte sich. Sonntag kam die Mitteilung, dass man am darauffolgenden Tag nicht ins Büro kommen soll, sondern zuhause bleiben und alle Vorbereitungen für das langfristige Arbeiten von Zuhause vornehmen soll. Das war, natürlich erstmal eine Umstellung und sehr ungewohnt, vor allem wenn man das noch nie gemacht hat. Einige Fragen kamen auf, wie:

  • Habe ich alles was ich benötige?
  • Funktioniert mein VPN?
  • Was ist, wenn ich Fragen habe?
  • Welche Arbeitsaufgaben werde ich haben?

All diese Fragen ließen sich schnell klären. Mein VPN hat funktioniert und wenn nicht wäre das auch kein Weltuntergang, da uns unsere Internal- Support Abteilung immer mit Rat und Tat zur Seite standen und immer noch stehen. (Danke an euch!)

Alle ausbildungsspezifischen Fragen hat dann der Ausbilder für NETWAYS Professional Services, Dirk Götz geklärt, der auch im Prinzip ständig erreichbar ist und einen auch immer sofort über alles informiert und an der Seite der Azubis steht und für sie “kämpft”. (Ein großes Danke auch an dich Dirk!)

 

Arbeiten zuhause

Endlich war alles bereit und die Technik funktionierte. Normalerweise wäre ich in der ersten Woche im Abteilungsdurchlauf bei der Sales-Abteilung gewesen. Da der Abteilungsdurchlauf jedoch pausiert wurde, brauchte ich ein neues Projekt. Da hat sich auch schnell eins gefunden – Terraform! Hier kam meine “alte Liebe” wieder in mein Leben und ich habe dann zwei Wochen lang an der Schulung gearbeitet und sie auf AWS und Azure angepasst. Danach habe ich ein Projekt in Kooperation mit unserer Marketing-Abteilung bekommen, welches noch immer läuft. Dabei geht es um Dashboards für Marketing, die mit Graphite / Grafana verwirklicht werden sollen. Auf den Dashboards sollen später in einer übersichtlichen und kompakten Version Informationen zu Schulungen, Events und Social Media zu finden sein.

 

Zwischenzeitlich durfte ich auch an einer unserer neuen Online-Trainings teilnehmen. Die Schulung drehte sich rund um GitLab. Diese verlief von meiner Seite absolut reibungslos. Es gab weder Internet-Probleme noch war die Schulung zu schnell. Ich fand die Umsetzung online sehr angenehm und die Teilnahme hat mir sehr viel Spaß bereitet. Und ja, gelernt habe ich auch etwas!

 

Jetzt steht weiterhin erstmal 1 Woche Dashboards an und danach geht es wieder ins Büro. Wie es dann weitergeht ist noch offen und wir versuchen möglichst flexibel zu bleiben. Auf mich sollten dann demnächst 4 sehr spannende Schulungen zukommen, die man als NETWAYS Azubi glücklicherweise besuchen darf.

 

Mein Fazit- zumindest bisher

Alles in allem ist es schön von Zuhause aus zu arbeiten. Der fünf Meter Arbeitsweg ist, natürlich, besonders attraktiv. Allerdings fängt man nach einer Weile an das Büro zu vermissen und auch die gemeinsamen Pausen mit den Kollegen. Zudem ist es etwas ganz Anderes etwas online erklärt zu bekommen als persönlich – auch wenn das dennoch sehr gut funktioniert. Jeder versucht das Beste aus der Situation zu machen und ich denke mal das wir als NETWAYS es doch geschafft haben sehr gut mit der Situation umzugehen. Die Event-Abteilung zum Beispiel hat Online-Trainings eingeführt und die stackconf zu einer Online-Konferenz umgestellt. Aber alle anderen Abteilungen haben auch ihre Finger mit im Spiel, so das alles möglichst reibungslos abläuft. Managed Services beispielsweise ist immer sofort da falls Jitsi mal nicht so möchte, damit Meetings weiterhin möglich sind.

 

Haustiere im Homeoffice

Ein weiterer Vorteil vom Homeoffice fällt mir gerade noch ein, allerdings für die Haustiere! Viele haben sicherlich Haustiere zu Hause, die sich freuen uns ständig zu Hause zu sehen. Sei es, damit wir mit ihnen spielen oder nur damit sie uns bei der Arbeit zusehen können und sich weniger langweilen – also mein Reptil liebt die Gesellschaft!

 

Und jetzt?

Aktuell laufen die ersten Vorkehrungen, um das Büro langsam wieder hochzufahren und den Bürobetrieb wieder aufzunehmen. NETWAYS macht sehr viel, um seine Mitarbeiter zu schützen. Sei es noch flexiblere Arbeitszeiten, um nicht zu Stoßzeiten einkaufen gehen zu müssen, die Beschaffung von Masken aber auch die Möglichkeit im Homeoffice arbeiten zu können.

Hier bleibt mir nur noch eins zu sagen – Danke an das Ganze NETWAYS Team! Vor allem die Leads und Ausbilder, das ihr gerade jetzt alles flexibel haltet und immer unterstützend da seid. In diesem Sinne – Bleibt zuhause und bleibt gesund!

Nathaniel Donahue
Nathaniel Donahue
Junior Consultant

Nathaniel hat 2019 die Wirtschaftsschule abgeschlossen. Wegen seinem Interesse am IT-Bereich entschied er sich dafür eine Ausbildung zum Fachinformatiker im Bereich Systemintegration zu machen und fing im September 2019 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er gerne am Computer, allerdings meistens zum Spielen, oder er unternimmt etwas mit seinen Freunden.

Wie ich meine Open Source-Apps und MyEngineers zu schätzen gelernt habe

Corona-Lockdown: Und plötzlich sind fast alle im Homeoffice… So war das zumindest bei uns. Und sicher auch bei vielen von euch!

Für mich hatten die Apps, die mir auch vorher schon die tägliche Zusammenarbeit mit Kolleg*innen erleichtert haben, schlagartig einen noch viel höheren Stellenwert. Das gute Rocket.Chat, in dem ich mich in verschiedenen Kanälen mit departmentübergreifenden Teams auf kurzem Weg zum jeweiligen gemeinsamen Projekt austausche oder in dem ich der Kollegin im privaten Channel schreibe. Normalerweise würde sie neben mir sitzen, jetzt sitzt sie am anderen Ende der Welt im indischen Lockdown fest… Jitsi, mit dem wir unsere täglichen “Telkos” abhalten. Notiz an mich: Nicht vergessen, die Frisur zurecht zu rücken, bevor ich die Kamera aktiviere! Oder der Request Tracker, mit dem ich meine täglichen ToDo’s verwalte, der aber viel mehr ist: Projektmanagement-Tool, das mich via E-Mail benachrichtigt und außerdem alle anderen, die mit auf dem Ticket sind und vom Status und Fortschritt einer Aufgabe erfahren sollen. Die gesamte Kommunikation mit Kunden oder Kollegen an einem Ort gesammelt: Da geht keine Info stiften. Und weil ich ja meine coolen NETWAYS Web Services-Kollegen habe, die sich um die Technik kümmern, kann ich ganz entspannt die Dienste nutzen und muss mir keine Gedanken machen über Sicherheit, Updates, Backups, Betrieb und so: Das läuft einfach!

Das sind sie übrigens:

Vielleicht seid Ihr im Rahmen unserer Aktion #StayAtHome ja auch in den Genuss gekommen…

Manche von Euch werden sicher noch länger mit veränderten Arbeitsbedingungen zu tun haben, die plötzlich viel digitaler sind als jemals zuvor. Lehrer*innen zum Beispiel. Andere arbeiten wahrscheinlich schon immer viel am PC, jetzt aber fast ausschließlich, so wie ich. Ich weiß meine Apps jetzt jedenfalls viel mehr zu schätzen und will die zusätzlich gewonnenen Feinheiten in Kommunikation und Arbeitsabläufen nicht mehr missen. Vielleicht seid ihr aber auch dafür verantwortlich, dass die IT einer Organisation, einer Firma oder öffentlichen Einrichtung funktioniert. Wir unterstützen Euch gerne! Wir bieten professionelle IT-Dienstleistungen auf allen Ebenen. (Ja, auch wenn da oben eine Micky Maus auf diesem Pulli ist! Homeoffice halt.)

Neben den fertigen Open Source-Apps gibt es mit der NETWAYS Cloud eine individuelle “Infrastructure as a Service” oder mit NETWAYS Managed Kubernetes Deine private Container-Plattform. Mit dem MyEngineer sind wir zudem immer persönlich für unsere Kund*innen da. Egal ob IT-Beratung, Betrieb inklusive aller Sicherheitsstandards und Backups, Migration oder Troubleshooting: Wir unterstützen Dich!

Flexibel. Passioniert. Open Source. Überzeuge Dich selbst!

Open Source-Apps

Starte Deine Lieblings-Open-Source-Apps in wenigen Minuten. Wir helfen Dir gerne, sie nahtlos in Deine Arbeitsumgebung zu integrieren!

Unsere Apps:

  • Nextcloud – Ein sicherer Platz zum Ablegen & Teilen Deiner Daten
  • Rocket.Chat – Kommunikation multimedial & in mehreren Kanälen
  • Jitsi – Dein Open Source Videoconferencing Tool
  • GitLab – Projektmanagement, nicht nur für Entwickler*innen
  • Request Tracker – Verwaltung von Anfragen & Aufgaben, perfekt ins E-Mail-System integrierbar

und viele weitere Open Source Apps

NETWAYS Cloud

Du brauchst Online-Ressourcen? Die NETWAYS Cloud ist ideal zum Erstellen oder Erweitern Deiner IT-Infrastruktur. Wir helfen Dir, Deine Infrastruktur maßzuschneidern und die passenden Komponenten zu finden: Virtuelle Maschinen, Betriebssysteme, flexible Datenspeicher und Netzwerke. Gemeinsam bauen wir Deine IT, die Du mit ein bisschen Übung ganz leicht selbst erweitern und umbauen kannst.

Jetzt in die NETWAYS Cloud starten!

NETWAYS Managed Kubernetes

Du willst mit Containern arbeiten? Kubernetes ist klarer Sieger im Kampf um die Container-Orchestrierung. Dabei geht es um viel mehr, als nur Container auf einer Vielzahl von Nodes zu starten. Wir empfehlen unsere Blog-Serie “Kubernetes – so startest Du durch!” Der einfachste Weg zum funktionalen Kubernetes-Cluster ist sicherlich unser NETWAYS Managed Kubernetes-Angebot.

NETWAYS MyEngineer

Mit unseren MyEngineers startest Du durch – Dank persönlichem, direktem Kontakt und kompetenter Unterstützung. Gemeinsam finden wir Deine beste Lösung!

Erfahre mehr über unseren MyEngineer!

Fragen? Kontaktiere uns!

Wir haben einen Live-Chat auf unserer Webseite!
Außerdem:
+49 911 92885 0
info@netways.de
nws.netways.de

Wir freuen uns, von Dir zu hören!

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Erste Schritte mit Kubernetes

This entry is part 3 of 5 in the series Kubernetes - so startest Du durch!

Du hast ein brand neues Kubernetes Cluster und willst jetzt loslegen? Aber egal, ob bei Dir ein lokales minikube läuft oder ob Du ein Managed Kubernetes mit allen Schikanen hast, die ersten Kubernetes-Objekte im super einfachem YAML-Format lassen fast jeden erstmal die Stirn runzeln. Was sind eigentlich deployments, services und Co? Und wozu die ganzen Labels? Versuchen wir Licht ins Dunkle zu bekommen.

Die wichtigsten Kubernetes-Objekte

Hierarchie von Deployment Replicaset und PodZum Verwalten und Steuern eins Kubernetes Clusters verwendet man Kubernetes-API-Objekte, in welchen man den gewünschten Zustand des Clusters beschreibt. Diese werden im einfachen YAML-Format mit Hilfe von kubectl an das Cluster gesendet. Neben einer API-Version, Metadaten und der Objektart gibt es meistens noch den Abschnitt spec. In diesem beschreibt man den gewünschten Zustand seiner Anwendung. spec kann für jedes Objekt unterschiedlich definiert sein und ist in vielen Fällen verschachtelt. Zum Beispiel enthält ein Objekt deployment Attribute für ein Objekt replicaSet, welches wiederum im eigenen spec Abschnitt Attribute für ein pod Objekt hat. Aber bevor es zu kompliziert wird, erstmal eine kurze Erklärung dieser drei wichtigen Objekte:

deployment

Ein deployment beschreibt einen gewünschten Zustand einer Anwendung und versucht, beständig diesen herzustellen. Mit deployments lassen sich Anwendungen starten, skalieren, aktualisieren, zurückrollen und löschen. In der Regel verwendet man deployment Objekte, um Anwendungen zu verwalten.

replicaSet

Ein replicaSet gewährleistet die Verfügbarkeit einer definierten Anzahl identischer Pods. Gegebenenfalls werden neue Pods gestartet und auch gestoppt. replicaSet verwendet man im Normalfall nur indirekt durch ein deployment.

pod

Ein pod definiert eine Gruppe von Containern (oftmals nur einer), die sich einen gemeinsamen Namespace auf einen Host teilen. Durch die gemeinsamen Namespaces (z.B. gemeinsames Dateisystem oder Netzwerk) ist eine einfache Kommunikation der Container erleichtert. Ein Pod ist immer durch eine eindeutige IP im Cluster erreichbar. Im Normalfall verwendet man Pods nur indirekt durch ein deployment.

Mit diesen drei Objekten können wir unser erstes MariaDB Deployment starten und eine erste Verbindung damit herstellen.

Das erste K8s-Deployment

Als erste einfache Anwendung starten wir eine nicht replizierte MariaDB als deployment. Bevor wir aber einen genauen Blick auf die Definition werfen, sende doch das Objekt mit kubectl apply an Dein Cluster:

Speichere einfach die mariadb.yaml auf Deinem Rechner und sende diese mit apply an Dein Cluster:

$ kubectl apply -f mariadb.yaml deployment.apps/mariadb-deploy created

Du hast noch kein kubectl? Erfahre, wie man kubctl installiert (klick) und speichere deine kubeconfig in ~/.kube/config

 

Für Änderungen an Deinem deployment kannst Du die Yaml-Datei einfach anpassen und mit dem gleichen Befehl an Dein Cluster senden. Willst Du Dein deployment wieder löschen, ersetzt Du das apply einfach durch ein delete.

mariadb.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mariadb-deploy
  labels:
    app: mariadb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mariadb
  template:
    metadata:
      labels:
        app: mariadb
    spec:
      containers:
        - name: mariadb
          image: mariadb
          ports:
            - containerPort: 3306
              name: db-port
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: "123456"
Erklärung:

Bei einem genaueren Blick finden wir im Beispiel Parameter für alle drei Kubernetes-Objekte.

Zeile 1-6: Wir definieren API-Version, kind, Name und ein frei wählbares Label für unser deployment Objekt.

Zeile 8-11: Sind Teil des replicaset (RS). Hier wird neben der Anzahl der replicas auch matchLabels definiert und es werden pods mit dem Label mariadb in das RS mit aufgenommen.

Zeile 13-25: Definieren Deinen Pod. Neben einem Label werden Parameter für den MariaDB Container übergeben. Wir verwenden das offizielle MariaDB Image, definieren den Port 3306 und setzen über eine Environment-Variable das root-Passwort für die Datenbank.

Besserer Überblick mit describe und get

Mit describe und get kannst Du Dir einen schnellen Überblick verschaffen und alle nötigen Details Deiner Anwendungen bekommen. Ein einfaches kubectl describe deployment/mariadb-deploy liefert alle Details zum MariaDB Deployment aus dem Beispiel.
get all hingegen listet alle Objekte auf, aber die Ausgabe kann auch schon mit wenigen Anwendungen im Cluster schnell unübersichtlich werden. Deshalb gibt es verschiedene Möglichkeiten zum Filtern der Ausgabe, z.B. anhand des Labels app. Mit folgenden Beispielen hast Du die Ausgabe aber schnell im Griff.

Beispiel für get mit verschiedenen Filtern

$ kubectl get pods
$ kubectl get deployment
$ kubectl get replicaset -l app=mariadb -o json
$ kubectl get po –field-selector=status.phase=Running

Die Komponenten Deiner MariaDB kannst Du am schnellsten mit dem Label Filter anzeigen:

kubectl get all -l app=mariadb


NAME READY STATUS RESTARTS AGE
pod/mariadb-deploy-64bfc599f7-j9twt 1/1 Running 0 64s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/mariadb-deploy 1/1 1 1 64s

NAME DESIRED CURRENT READY AGE
replicaset.apps/mariadb-deploy-64bfc599f7 1 1 1 64s

Nachdem Du jetzt weißt, wie Du den aktuellen und gewünschten Zustand Deiner Anwendung überprüfst, werfen wir nun einen genaueren Blick auf Pods und Container.

Mit Pods interagieren

Ohne weitere Konfiguration sind Anwendungen nur innerhalb des Kubernetes-Clusters erreichbar. Zudem will man selten eine Datenbank über eine öffentliche IP erreichbar machen. kubectl bietet deswegen mit proxy und port-forward zwei Möglichkeiten, um Zugriffe auf interne Pods und Services zu gewährleisten. Für MariaDB benutzen wir port-forward und senden sämtlichen Traffic der lokal auf Port 3306 ankommt durch kubectl an unseren MariaDB Pod. Du kannst übrigens direkt den Namen des deployments verwenden. Die Namen von pod und replicaSet führen aber zum selben Ergebnis. Mit telnet oder einem MySQL Client prüfst Du am schnellsten, ob die Verbindung funktioniert:

kubectl port-forward deployment.apps/mariadb-deploy 3306:3306

mysql -h 127.0.0.1 -P 3306 -u root -p123456

telnet 127.0.0.1 3306

Weitere Möglichkeiten, um mit seinem Container zu interagieren, bietet kubectl mit log und exec. Ersteres zeigt Dir natürlich stdout Deines Pods. exec hingegen wird wohl meistens zum Starten einer interaktiven Shell genutzt. Ähnlich wie bei docker benötigt man die Parameter interactive und tty (-ti), um eine funktionsfähige Bash zu erhalten:

$ kubectl exec -it mariadb-deploy-64bfc599f7-j9twt — /bin/bash

Mit diesen wenigen Befehlen kannst Du Deine im K8s-Cluster abgeschirmten Pods erreichen und debuggen. Anwendungen, die nur innerhalb des Clusters erreichbar sind, machen natürlich nicht immer Sinn. Damit auch andere darauf zugreifen können, benötigst du einen Kubernetes service mit öffentlicher IP. Hinter einem service steckt aber noch viel mehr.

Verbinde deine Pods mit einem service

Ein service bindet eine feste interne IP-Adresse (ClusterIP) an eine Menge von Pods, welche durch Labels identifiziert werden. Im Vergleich zu einem service sind pods sehr kurzlebig. Sobald wir im Beispiel ein Upgrade der MariaDB anstoßen, verwirft unser deployment den vorhanden Pod und startet einen neuen. Da jeder Pod seine eigenen IP-Adresse hat, ändert sich auch die IP-Adresse, unter welcher deine MariaDB erreichbar ist. Dank der Labels findet der service den neuen Pod und der Traffic wird richtig weitergeleitet.
Ein service gewährleistet somit durch die ClusterIP die interne Erreichbarkeit deiner deployments. Zusätzlich kann ein service auch den Typ Loadbalancer haben. Dadurch wird eine öffentliche IP gebunden und sämtlicher Traffic an die ClusterIP weitergegeben. Im folgenden Beispiel siehst siehst Du einen service für deine MariaDB.

Neben API-Version, kind und metadata gibt es wieder den Abschnitt spec. Protocol, port und targetPort definieren, welcher Traffic weitergereicht wird. Im selector wird anhand der Labels festgelegt, welche Pods bedient werden sollen. Mit der optionalen Zeile type: LoadBalancer wird neben einer internen ClusterIP auch eine öffentliche IP gebunden.
apiVersion: v1
kind: Service
metadata:
  name: mariadb-service
spec:
  ports:
  - port: 3306
    targetPort: 3306
    protocol: TCP
    name: mariadb
  selector:
    app: mariadb
  type: LoadBalancer

Im Beispiel ist für einen Pod genau ein Container definiert und unser selector im Server greift auch nur für einen Pod. Was passiert aber, wenn replicas in der Deployment erhöht wird? Zuerst werden natürlich mehrere Pods gestartet und somit auch mehrere MariaDB-Container. Der selector im MariaDB Service findet diese natürlich anhand des Labels und die Verbindungen werden im round-robin Verfahren an die Pods weitergeleitet. Technisch funktioniert dies im Beispiel auch ohne Probleme, solang MariaDB selbst aber nicht als replizierendes Cluster installiert ist, macht dies aber wenig Sinn.

Was kommt als nächstes?

Mit den hier gezeigten Beispielen kann man seine ersten Anwendungen ausrollen und debuggen. Aber Du ahnst bereits, dass wir nur etwas am Lack von Kubernetes gekratzt haben und es stellen sich natürlich noch viele Fragen! Was passiert mit meinen Daten in MariaDB und wie kann ich die kurzlebigen Pods mit einem persistentem Volume verbinden? Brauche ich für jede Anwendung eine eigene öffentliche IP? Wie komme ich an Metriken und Logs meines Clusters und meiner Anwendungen? Diese und weitere Fragen werden wir natürlich in den folgenden Blogposts beantworten. Also dann, bis nächste Woche!

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.