Select Page

NETWAYS Blog

Kubernetes 101: Aufbau eines K8s-Cluster und die Möglichkeiten der API

This entry is part 2 of 7 in the series Alles rund um Kubernetes

In meinem ersten Blogpost ging es zuerst einmal darum zu klären, was Kubernetes denn eigentlich ist. Jetzt, wo wir ergründet haben, welche Ansätze und Ideen Kubernetes verfolgt und warum diese sinnvoll sein können, gehen wir einen Schritt weiter, und schauen uns an, wie diese umgesetzt werden. Dafür wollen wir zwei Aspekte betrachten: Zum Einen der Aufbau eines Kubernetes-Clusters selbst, inklusive aller Teilbausteine, die für den reibungslosen Betrieb benötigt werden. Zum Anderen die im letzten Blogpost bereits mehrfach erwähnte API, wir als Schnittstelle nutzen und die uns eine ganze Bandbreite an API-Ressourcen anbietet, mit denen wir auf Kubernetes arbeiten können. Let’s get going!

Aufbau eines Kubernetes-Clusters

Beginnen wir mit einem sog. “Ten-Thousand Foot View“, um uns den groben Aufbau eines Clusters auf Infrastrukturebene vor Augen zu führen:

Überblick eines Clusteraufbaus, bestehend aus Dataplane, Workernodes und Loadbalancer

Wir sehen hier ein Cluster bestehend aus 8 Nodes – drei sog. Leader-Nodes und fünf Follower-Nodes. Die Leader-Nodes bilden zusammen die sog. Controlplane des Clusters und stellen Dienste wie clusterinternes DNS und die Kubernetes-API bereit. Um die API und damit letzten Endes das Cluster hochverfügbar zu machen, wird der Controlplane ein Loadbalancer vorgelagert. In Cloud-Umgebungen ist dies oft per Default die bereitgestellte Lösung des jeweiligen Providers, in eigenen Rechenzentren oder on-premise kann hierfür auf Lösungen wie HAProxy oder MetalLB zurückgegriffen werden. Best Practices diktieren, dass auf den Leader-Nodes möglichst keine Anwendungen deployed werden sollten, die nicht für den Betrieb des Clusters selbst benötigt werden.

Hierfür sind die fünf Follower-Nodes gedacht, die mit der Kubernetes-API ebenfalls via Loadbalancer interagieren und die für den jeweiligen Node gescheduleten Anwendungen ausführen. Auf diesen Nodes können beliebige Anwendungen entsprechend der jeweils verfügbaren Ressourcen deployed werden. Die API in der Controlplane kümmert sich hierbei um ein passendes Scheduling, damit Ressourcen auf den Follower-Nodes nicht erschöpft werden und angegebene Voraussetzungen wie bspw. spezielle benötigte Hardware (GPU, SSD, etc.) auf dem jeweiligen Node erfüllt werden.
Die letzte im Schaubild dargestellte Komponente stellt eine lokale Terminalsession auf Seiten eines Endnutzers dar. Dieser kommuniziert via kubectl mit der Softwareschnittstelle, dem de-facto Standardtool für Interaktion mit der API von außerhalb des Clusters.

Doch welche Komponenten laufen denn nun auf den jeweiligen Node-Klassen? Gehen wir doch einmal etwas weiter ins Detail:

Wir sehen hier exemplarisch jeweils einen Leader und Follower-Node als VMs in der Detailansicht, mit all den Anwendungen, die auf den jeweiligen Node-Klassen typischerweise installiert sind. Gehen wir die verschiedenen Anwendungen doch einmal durch:

  • etcd – Key/Value-Store für den Zustand und die Historie der Kubernetes-API; Wird normalerweise auf den Leader-Nodes installiert, kann allerdings auch auf externe Maschinen ausgelagert werden
  • kube-apiserver – PI-Server des Kubernetes-Clusters; Wird für Hochverfügbarkeit auf allen Leader-Nodes installiert
  • kube-scheduler – Kümmert sich um das Scheduling der in das Cluster deployten Anwendungen; Wird auf Leader-Nodes installiert
  • kube-controller-manager – Ein Bündel an sog. Kubernetes-Controllern, das sich um die Verwaltung verschiedener Kubernetes-Ressourcen kümmert; Wird auf Leader-Nodes installiert
  • kubeletKommuniziert mit der API und der lokalen Container-Runtime, um Container auf den Nodes auszuführen; Wird auf allen Nodes installiert
  • kube-proxyRoutet Netzwerk-Traffic zu Containern, sobald dieser auf den jeweiligen Nodes ankommt; Wird auf allen Nodes installiert
  • Container Runtime – Im Beispiel containerd; andere Implementierungen sind möglich, bspw. CRI-o; Wird auf allen Nodes installiert

Zu erwähnen ist, dass nicht alle Cluster so aussehen müssen. Beispielsweise ließe sich auch eine Controlplane umsetzen, auf der keinerlei Container ausgeführt werden – in diesem Fall könnte man auf die Installation von kubelet, kube-proxy und containerd auf Leader-Nodes verzichten (für eine Referenzinstallation s. Kubernetes the Hard Way auf GitHub). Auf Clustern in der Cloud wird man außerdem fast immer einen sog. cloud-controller-manager auf Leader-Nodes finden, der gewisse Funktionalitäten im Cloud-Bereich integriert, bspw. automatische Provisionierung benötigter Loadbalancer in der hostenden Cloud.

Auch können sich die genauen Ausprägungen einer Kubernetes-Installation je nach Kubernetes-Distribution unterscheiden – momentan listet die CNCF 59 zertifizierte Distributionen. K3s bspw. bündelt die verschiedenen Komponenten in eine Binary, was den Betrieb im Alltag etwas erleichtern kann und den Ressourcen-Fußabdruck des Clusters senkt.

Die Kubernetes’ API – endlose Weiten

Haben wir unser Cluster nun wie oben skizziert (oder ganz anders) installiert, möchten wir natürlich mit ihm interagieren – hierfür gibt es verschiedene Möglichkeiten, angefangen bei cURL über das offizielle Kubernetes Dashboard bis zu Wrappern für das lokale Terminal. Letzteres ist der gängigste Weg – fast alle Tutorials und technische Dokumentationen zu Kubernetes und darauf zu installierende Anwendungen erwähnen kubectl, was sich auf jedem gängigen Betriebssystem paketiert installieren lassen sollte. Haben wir kubectl lokal installiert und eingerichtet (wir benötigen eine sog. kubeconfig, die Verbindungsinformationen für unser(e) Cluster enthält), können wir uns zum ersten Mal die API anschauen:

beispielhafter Aufruf von kubectl api-resources mit wordcount nach Zeilen: 70

Je nach Cluster (im Beispiel ein Rancher Desktop Cluster) scheint uns Kubernetes zwischen 60 und 70 verschiedene API-Objekte anzubieten! Wo also anfangen und wo aufhören? Oder gleich alle 70 behandeln? Fangen wir doch einfach mit der kleinsten Einheit an Workload an, die K8s für uns bereit hält – dem Pod. Ein Pod kapselt einen oder mehrere Container in einem Bündel, das sich Netzwerk- und Speicherressourcen teilt.

Daraus folgt, dass alle Container eines Pods immer auf demselben Node gescheduled werden. Ein Pod alleine profitiert allerdings noch nicht von Kubernetes’ Orchestrierungsmöglichkeiten – ist bspw. der hostende Node nicht erreichbar, können wir auch die in unserem Pod laufenden Anwendungen nicht mehr erreichen.

Wir benötigen also eine weitere Abstraktionsebene, die es uns erlaubt, mehrere identische Pods auf verschiedene Nodes zu schedulen: das sog. Deployment. Ein Deployment definiert ein Pod-Template, sowie eine Anzahl an gewünschten Repliken und weitere Konfiguration, die von Kubernetes zur Orchestrierung des Deployments genutzt wird. Unter der Haube wird dann vom API-Server ein ReplicaSet erzeugt, das die gerenderte Version des Pod-Templates enthält.

Auf diese Weise ermöglicht eine Deployment-Ressource uns nicht nur die Ausführung mehrerer Repliken eines einzelnen Pods, sondern auch eine Versionierung verschiedener ReplicaSets – wieviele genau von der API gespeichert werden, hängt von den Einstellungen des API-Servers zusammen. Hier nochmal ein Schaubild zu den Zusammenhängen:

Ein Überblick der Zusammenhänge zwischen Deployments, ReplicaSets und Pods in Kubernetes

Zu sehen ist ein Deployment mit drei dazugehörigen ReplicaSets, die sich in der Anzahl der definierten Replicas unterscheiden (Kubernetes erstellt bei jeglicher Änderung eines Deployments ein neues ReplicaSet, nicht nur bei Änderung der Replicas). Das momentan aktive ReplicaSet wiederum verwaltet der Konfiguration entsprechend fünf Pods.

Möchte man seine deployten Anwendungen nun untereinander oder für Endnutzer außerhalb des Clusters verfügbar machen, kommen Services ins Spiel. Ein Service ist eine API-Ressource, die einen gewissen Pool an Pods als Endpoints definiert und für diese als Round-Robin Loadbalancer fungiert. Auf diese Weise benötigt man nur eine IP, um zuverlässig einen funktionalen Pod eines Deployments zu erreichen. Kubernetes kümmert sich hierbei automatisch darum, Traffic nur zu funktionalen Pods weiterzuleiten.
Es gibt drei Arten von Services:

  • ClusterIP – der Service erhält eine innerhalb des Clusters erreichbare IP-Adresse, ist von außerhalb des Clusters aber nicht ohne Weiteres zu erreichen
  • NodePort – der Service wird auf jedem Node auf einem zufälligen, hohen Port (ca. 30.000+) verfügbar gemacht
  • Loadbalancer – eine Erweiterung des NodePort-Typs, wobei den Ports ein Loadbalancer vorgelagert wird; funktioniert am reibungslosesten in Public Clouds

Zusätzlich gibt es die Möglichkeit, HTTP-Traffic anstatt mittels Loadbalancer auf L4 mit einem sog. Ingress auf L7 zu routen – die Konfiguration unterscheidet sich hierbei abhängig vom genutzten IngressController.

Weitere nennenswerte, grundlegende API-Ressourcen innerhalb von Clustern wären bspw. Namespaces zur Trennung von anwendungslogisch zusammenhängenden Deployments etc. sowie zur Umsetzung von role-based access control (RBAC), Secrets zur Bereitstellung vertraulicher Daten wie bspw. Passwörtern, Zertifikaten, oder Token, und ConfigMaps für häufig genutzte Konfigurationssnippets. Wer mitgezählt hat wird merken, dass wir gerade erst bei 7 von den oben angezeigten 70 Ressourcentypen angekommen sind – und das ist noch lange nicht das Ende der Fahnenstange, da eine der Stärken der Kubernetes-API schließlich ihre Erweiterung durch sog. CustomResourceDefinitions (CRDs) ist. Für einen ersten Einblick soll der momentane Stand trotzdem fürs Erste genügen.

kubectl – das Schweizer Taschenmesser für Kubernetes

Bereits im letzten Absatz eingangs erwähnt, ist jetzt der Moment für kubectl gekommen, das offizielle Kommandozeilentool für den täglichen Umgang mit Kubernetes und seiner API. Ich könnte an dieser Stelle mehrere 1000 Wörter über den Gebrauch schreiben und trotzdem noch sehr viel unerwähnt lassen, und genau aus diesem Grund folgt nun gemäß dem Motto “Ein Bild sagt mehr als tausend Worte” lediglich eine Auflistung einiger gängiger und oft genutzter kubectl Kommandos, um einen ersten Eindruck von der Nutzung des Tools zu bekommen.

Screenshot eines Terminals mit mehreren Ausgaben von kubectl

Hier zu sehen sind einige der häufigsten Kommandos, zu denen neben get und create wohl auch noch apply, logs und describe gehören dürften. Neben dem expliziten (imperativen) Erstellen von API-Ressourcen via CLI können mit kubectl auch bestehende Kubernetes-Manifeste (in YAML oder JSON) in das Cluster “gepusht” werden, was einem deklarativen Ansatz entspricht und in der Praxis der gängigere Weg ist.

Für heute war das aber genug trockene Theorie rund um Architektur, API-Aufbau und Clusterkomponenten – im nächsten Teil der Serie werden wir uns genauer anschauen, wie wir uns denn nun basierend auf der in diesem Artikel erläuterten Architektur unser eigenes Cluster installieren können, entweder auf lokaler Infrastruktur, in der Cloud (z.B. Managed Kubernetes bei NMS), oder auf deinem persönlichen Rechner! Abonniere also gerne auch den RSS-Feed unseres Blogs und sei bereit für den nächsten Artikel der Kubernetes 101 Reihe!

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Kubernetes 101: Was ist eigentlich Kubernetes?

This entry is part 1 of 7 in the series Alles rund um Kubernetes

Egal, ob du bereits einmal versucht hast, online begehrte Tickets zu ergattern, dir bei einschlägigen Onlineshops einen Raspberry Pi zu sichern, oder in letzter Zeit einfach nur einmal ChatGPT ausprobieren wolltest, eine Sache hatten diese drei (völlig frei erfundenen) Szenarien mutmaßlich gemeinsam – die Websites waren langsam, crashten, oder ließen dich minuten- bis stundenlang in einer Warteschlange sitzen. Das liegt in den meisten Fällen ganz einfach daran, dass die Webserver bzw. dahinter gelagerten Backends der Flut an Anfragen nicht gewachsen sind. Hat man seine Anwendungen “traditionell” auf VMs oder direkt auf Hardware installiert, fällt es mitunter schwer, kurzfristig auf solche Anfragespitzen zu reagieren. Die Folge aus Nutzersicht sind u.a. Serviceausfälle, Timeouts oder Drosselungen, was es natürlich zu vermeiden gilt. Hierbei kann Kubernetes helfen, und Ausfallsicherheit ist einer der am öftesten genannten Vorteile des Betriebs von Anwendungen auf Kubernetes – doch was ist Kubernetes überhaupt?

Was ist Kubernetes – und was ist es nicht?

Kubernetes ist ein ursprünglich von Google entwickelter Container-Orchestrator und war ursprünglich als interner Nachfolger für Borg gedacht. Mitte 2014 wurde Kubernetes dann von Google als Open Source Software releast. Im Rahmen des Releases der Version 1.0.0 am 21. Juli 2015 wurde es an die CNCF (Cloud Native Computing Foundation) überschrieben, eine Tochter-Foundation der Linux Foundation, die inzwischen eine große Anzahl an Projekten betreibt und verwaltet (s. CNCF Landscape). Die bei Veröffentlichung dieses Artikels aktuelle Version von Kubernetes ist v1.26. Wie der Begriff Container-Orchestrator bereits erahnen lässt, kümmert sich Kubernetes um den Betrieb von in Containern laufenden Anwendungen innerhalb eines sog. Clusters, also einer verteilten Umgebung auf mehreren Nodes, die bspw. auf VMs aufgesetzt werden und gemeinsam die Ressourcen des Clusters bereitstellen. Aspekte, um die sich Kubernetes kümmert, betreffen u.A.

  • Netzwerk: Wie können Container miteinander kommunizieren? Wie können Endnutzer und andere Dienste außerhalb des Clusters mit Cluster-internen Diensten kommunizieren?
  • Scheduling: Wie müssen/sollen/dürfen Container auf die verschiedenen Cluster-Nodes verteilt werden, sodass sie möglichst ausfallsicher/ressourceneffizient/gleichmäßig verteilt sind?
  • Berechtigungen: Welche Entität (Nutzer, Service, Systemaccount) darf in welchem Kontext was?
  • Servicediscovery: Welche Services sind in einem Cluster zu finden und reagieren auf (Nutzer-)Anfragen?
  • Flexibilität: Wieviel Last müssen meine Services gerade verarbeiten? Wie soll auf Spitzen reagiert werden?

Worum sich Kubernetes hingegen nicht kümmert, ist der tatsächliche Betrieb der Container auf den jeweiligen Nodes des Clusters – ganz im Gegenteil. Kubernetes ist zu einem großen Teil agnostisch gegenüber der genutzten Container-Runtime, sie muss lediglich konform zur von Kubernetes definierten Plugin-Schnittstelle CRI (Container Runtime Interface) sein. Das ermöglicht die Nutzung verschiedener Container-Runtimes wie bspw. containerd oder CRI-o je nach Anforderungen und Vorlieben.

Kubernetes kümmert sich ebenso wenig um Speicherverwaltung oder die Etablierung eines Cluster-internen Netzwerks, auch hierfür definiert es allerdings Schnittstellen, die von Plugins genutzt werden können, um solche Dienste zu ermöglichen: CSI (Container Storage Interface) bzw. CNI (Container Network Interface). Wichtig ist außerdem darauf hinzuweisen, dass Kubernetes deine Anwendungen nicht “magisch” ausfallsicher macht – die Anwendungen müssen von vornherein dahingehend entworfen und entwickelt werden, dass sie Ausfallsicherheit bieten können, Kubernetes unterstützt dann bei der Realisierung.

Die Existenz der gerade besprochenen Schnittstellen für Runtimes, Netzwerk und Speicherverwaltung ist ein gutes Beispiel für eine von Kubernetes größten Stärken – der Abstrahierung und Standardisierung einer ganzen Bandbreite an Fähigkeiten und Voraussetzungen für den alltäglichen Betrieb von Anwendungen. Möglich macht das eine umfangreiche und bei Bedarf frei erweiterbare API, die den momentanen (und teilweise historischen) Zustand des Clusters für berechtigte Akteure zugänglich und manipulierbar macht. Mehr dazu gibt es im kommenden Blogpost zur Architektur von Kubernetes.

Container, Docker, Kubernetes – Warum der Hype?

Betrachtet man den Fokus auf Konferenzen rund um Softwareentwicklung- bzw. -betrieb seit ca. 2017/8, sind Themen im Blickpunkt fast immer Kubernetes, Docker, Container, oder alle drei gemeinsam. Softwareentwicklung befindet sich seitdem im Wandel, weg von sog. Monolithen, die sämtliche Bestandteile einer Applikation als ein “Bündel” beinhalten, hin zu einer Flotte an Microservices, die voneinander unabhängig entwickelt, getestet, installiert und skaliert werden können. Aufgrund der abgespeckten Größe dieser Microservices bietet sich eine Installation in von Betriebssystemen weitestgehend unabhängigen Containern an, was die Flexibilität weiter erhöht.

Der de-facto Standard sowohl für die Definition und Paketierung dieser Container in sog. Images als auch für die Entwicklung der beinhalteten Software auf den lokalen Rechnern der Entwickler ist Docker. Benötigt man im alltäglichen, produktiven Betrieb der Microservices in ihren Kombinationen dann eine Vielzahl von Containerinstanzen, wird es Zeit für einen Orchestrator: Kubernetes. Aus diesen Zusammenhängen ergibt sich die seit Jahren steigende globale Popularität und Adaptierung von Containern, Docker und Kubernetes bei vielen Unternehmen, von Fortune 10 Companies bis zu Startups.

In der Theorie ermöglicht die bereits erwähnte umfangreiche Kubernetes-API in Kombination mit den offenen, wohl-definierten Schnittstellen den für den Betrieb der Cluster zuständigen Plattformteams, je nach Bedarf vorhandene oder interne Dritt-Software einzubinden, um gewünschtes Verhalten der Plattform als Ganzes zu erzielen oder existierendes Verhalten zu erweitern oder zu präzisieren.
Gleichzeitig ermöglicht es Entwicklern, sich durch die Kapselung von Software in Microservices sowie die Abstraktion der späteren Laufzeitumgebung durch Kubernetes, sich voll und ganz auf ihre Software zu konzentrieren und gleichzeitig schneller Feedback zu bekommen – CI/CD (Continuous Integration/Continuous Delivery) ist gelebter Alltag auf und mit Kubernetes. In der Praxis ist das “Unterfangen Kubernetes” natürlich nicht ganz so einfach – sonst würde ich nicht hier sitzen und diese Artikelserie schreiben.

Ist Kubernetes etwas für mich und meine Anwendungen?

Als Consultant muss ich hier natürlich antworten “Das kommt darauf an…” – nutzt du/dein Unternehmen evtl. bereits heute Container für den Betrieb von Applikationen bspw. mittels Docker Compose oder Docker Swarm? Dann ist Kubernetes lediglich der nächste logische Schritt, zumal die beiden genannten Lösungen ab einer gewissen Größe und einem gewissen Anforderungsproblem nicht mehr flexibel und skalierbar genug sein werden.
Erfahrung zeigt, dass gerade zustandslose (“stateless”) Applikationen verhältnismäßig einfach auf Kubernetes migrierbar sind und enorm von den “Bordmitteln” eines Kubernetes-Clusters profitieren (Loadbalancing, Scheduling auf verschiedene Nodes, Servicediscovery, usw.). Doch auch wenn ihr größtenteils zustandsbehaftete (“stateful”) Applikationen im Einsatz habt oder noch “klassisch”, ohne den Einsatz von Containern, deployed, ist das im Jahr 2023 kein zwingendes Argument gegen Kubernetes mehr.

Grundsätzlich bist du sicherlich gut damit beraten, dir Kubernetes einmal anzuschauen, wenn du von mindestens einem der oben erwähnten Vorteile (Containernetzwerk, Scheduling, Berechtigungsmanagement, Servicediscovery, Flexibilität) im Gegensatz zu der momentan im Einsatz befindlichen Infrastruktur (Hypervisors, Baremetal, Cloud ohne Kubernetes) profitieren könntest. Es gibt Ressourcen, Tools und Hilfsmittel für fast alle denkbaren Szenarien rund um Anwendungsentwicklung und -betrieb, und ansonsten sind wir mit unserem Schulungs– und Beratungsangebot rund um Kubernetes ja auch noch da. Und nicht zuletzt folgen noch einige Blogartikel in dieser Serie, die hoffentlich das ein oder andere Fragezeichen wegwischen werden.

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Ab in den Wald!

This entry is part 9 of 11 in the series Just fit – Just awesome

Kurzer Abriss

Wir Deutschen besitzen eine tiefe Verbundenheit zu unseren Wäldern. Das spüren wir wenn wir durch ihn durch spazieren. Damit meine ich jetzt nicht nur die “historische” Verbundenheit wie z.B. Versorgung, Okkultismus, Dämonen oder Wölfe. Bereits in meinem kurzen Leben geht es immer mal wieder um den Wald. Da gab es z.B. die Katastrophe von Tschernobyl, welche bis heute Auswirkungen auf das Waldleben hat. Dann hatten wir einige ominöse Waldsterben in den 80er Jahren welche plötzlich verschwunden sind und wir haben mehr oder minder erfolgreiche Aufforstungspläne miterlebt. In Deutschland werden gerne auch mal Bäume gezählt, inventarisiert (Bundeswaldinventur) oder mit Barcodes ausgestattet.

Das eigentlich Positive oder “Warum denn der Wald für uns wichtig ist”, war immer nur ein Gefühl wenn man ihn betritt. In den letzten Jahren allerdings rückt der Wald immer stärker in den gesundheitlichen Fokus. Das könnte auch daran liegen, dass wir einfach mehr über dessen Ökosystem und Lebensformen wissen und wir nach und nach einen verständigeren Blick entwickeln. Aber auch Bücher wie “Das geheime Leben der Bäume” von Peter Wohlleben tragen dazu bei, dass man sich wieder mehr mit dem Wald beschäftigt.

Was macht er denn nun, der Wald

Er wirkt positiv auf uns Menschen – und das ganz massiv. Das merkt man immer dann wenn Menschen keinen Zugang zum Wald haben. Was bei allgegenwärtiger Urbanisierung nicht besonders schwer sein dürfte.

Menschen, die sich häufig im Wald aufhalten leiden weniger an den typischen Zivilisationskrankheiten, also z.B. Bluthochdruck, Krebs oder Depressionen. Das hat besonders mit beruhigenden Faktoren zu tun: Der Wald dämpft Geräusche, beruhigt das Auge und besitzt ein eigenes Mikroklima. Die Gedanken kommen zu ruhe und die Luft erfrischt unseren Körper. Dadurch sinkt der Cortisolspiegel und wir fühlen uns weniger gestresst. Auch stellt der Wald komplexe Gerüche für unsere Nase bereit. Diese Terpene (Phytonzide) werden von Pflanzen als Kommunikationsmittel oder als Insektenschutz verwendet. Uns Menschen inspirieren diese “harzigen” Gerüche und steigern nach­ge­wie­se­ner­ma­ßen die Menge der Abwehrzellen in unserem Körper. Durch mäßige körperliche Aktivität wird außerdem das Herz-Kreislauf-System positiv gefördert.

Es gibt mittlerweile zig Studien, welche die oben genannten positiven Eigenschaften belegen und noch viele mehr aufzeigen. Ich wage es allerdings zu bezweifeln, dass ein so komplexes System wie der Wald in seine einzelnen Wirkbestandteile aufgeteilt werden kann und sollte. Es gibt aber einen nachgewiesenen Unterschied zwischen einem Stadtspaziergang, einem Sonnenbad in einer Heidelandschaft und dem Verweilen im Wald – Das ist wichtig!

Fazit

Deutschland ist ca. zu einem Drittel mit Wald bedeckt und das sollten wir nutzen. Hin und wieder einen Spaziergang im Wald, vielleicht Pilze sammeln (und jemand fragen der sich mit Speisepilzen auskennt) und ein positives Verhältnis zum Wald und dessen Bewohner aufbauen. Das entspannt Körper, Geist und Seele und hält fit. Jogger oder Radfahrer können ihre Runden im Wald drehen. Und wer die Möglichkeit hat, kann auch mit dem Laptop ins Gehölz gehen, ein Buch lesen, picknicken oder die nächste Yoga-Session in den Wald verlegen – oder neudeutsch: “Waldbaden”

Man wird im Allgemeinen überrascht sein, was man alles dort erleben kann!

Für mich persönlich ist es einfacher und außerdem nachhaltiger in den “eigenen” nächstgelegenen Wald zu gehen als mit dem SUV 100km in die nächste Therme zu brettern, um sich zu entspannen.

Marius Hein
Marius Hein
Head of ITSM

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.

Von Eulen und Lerchen

This entry is part 8 of 11 in the series Just fit – Just awesome

In unserer Blog-Reihe „Just fit – just awesome“, haben wir bereits einiges darüber erfahren, wie wir durch aktive kleine Umstellungen im Alltag unseren Körper fit halten können. In diesem Beitrag möchte ich auf einen Gesundheitsaspekt eingehen, der von den Genen vorbestimmt ist und zwar unsere innere Uhr.


In der Chronobiologie (Wissenschaft der zeitlichen Organisation physiologischer Prozesse) wird zwischen zwei Chronotypen unterschieden: Den Morgenmenschen, die „Lerchen“ und den Spätmenschen, die „Eulen“ genannt werden. Das heißt nicht zwangsläufig, dass Spätmenschen mehr und Morgenmenschen weniger schlafen, denn die Schlafdauer ist von Mensch zu Mensch unterschiedlich. Sondern, dass sich der Aktivitätsmodus der beiden deutlich unterscheidet.
Lerchen können in den Morgenstunden Bäume ausreißen. Ihre Leistungskurve steigt kurz nach dem Aufstehen an, erreicht in der Mittagszeit einen kurzen Tiefpunkt und hat am Nachmittag wieder eine Hochphase. Dafür ist dieser Chronotyp in den frühen Abendstunden schon ausgelaugt, müde und nicht mehr sonderlich produktiv. Generell kommt Lerchen der frühe Schul- und Arbeitszeitbeginn entgegen, Nachtschichten bekommen ihnen dagegen nicht so gut. Eulen hingegen werden in den Nachmittags- und Abendstunden aktiv und können da hochkonzentriert arbeiten, kommen aber morgens kaum aus dem Bett, selbst wenn sie ausgeschlafen sind. Ihre Leistungsphase tritt später ein, dementsprechend schlafen sie auch später und stehen später auf. Sie machen den größeren Teil der Bevölkerung aus, werden aber in dem oft vorgegebenen morgenbetonten Lebensrhythmus meist benachteiligt.


Da in der heutigen Welt kaum Rücksicht auf die verschiedenen Schlaftypen genommen wird, führt das bei vielen zu einer zunehmenden Stressbelastung, die auf lange Sicht krank machen kann. Menschen, die kontinuierlich gegen die innere Uhr leben, sind anfälliger für Depressionen, leiden häufiger an Diabetes oder Herz-Kreislauferkrankungen und sogar Krebs. Auch Schlaf – und Konzentrationsstörungen, Abgeschlagenheit, Gereiztheit, Appetitlosigkeit oder Übergewicht können die Folge sein.

Wer also versucht im Einklang mit der inneren Uhr zu leben, lebt gesünder und kann produktiver und effizienter arbeiten. Ein wichtiger Taktgeber unseres Biorhythmus ist das Sonnenlicht. Wer tagsüber genug davon tankt, unterstützt einen gesunden Tages-Nacht-Rhythmus. Deshalb ist es auch wichtig sich abends vor dem biologisch starkwirksamen blauen Licht des Fernsehers, Computers oder Smartphones fernzuhalten, da das die Melatoninausschüttung hemmt und der Tag sich so künstlich nach hinten verschiebt. Außerdem sollte die Schlafens- und Aufstehzeit stets dieselbe sein, mit einer maximalen Abweichung von einer halben Stunde, da ein unregelmäßiger Schlafrhythmus die innere Uhr durcheinanderbringt. Wer sich seine Arbeitszeiten selbst einteilen kann oder Gleitzeit im Job hat, kann seinen Arbeitsbeginn so verschieben, dass die persönlichen Hoch- und Tiefphasen bestmöglich genutzt werden. Auch die Ernährung spielt eine Rolle und hilft unsere innere Uhr im Takt zu halten. Kalorienreiche Nahrungsmittel, wie Zucker, Alkohol und fetthaltige Speisen sollten möglichst komplett gemieden werden. Es empfiehlt sich drei Mahlzeiten täglich zu essen, wobei abends auf kohlenhydrathaltige Kost verzichtet werden sollte, da diese abends wesentlich schlechter verwertet werden kann als tagsüber. Allgemein kann man sagen, dass regelmäßige Strukturen im Alltag und ein achtsamer Umgang mit belastenden Einflüssen dazu beitragen mit unserer inneren Uhr im Gleichgewicht zu leben.
Unter dem Strich lässt sich also sagen: Egal, ob du eine Lerche oder eine Eule bist, beides birgt Vor- und Nachteile. Lebt euren Tag so, wie es sich für euch richtig anfühlt und ihr den größtmöglichen Nutzen daraus zieht.

Stephanie Kotilge
Stephanie Kotilge
Accountant

Steffi ist seit 2011 bei NETWAYS. Sie fing als Office Managerin an und unterstützt seit 2017 als Accountant das Finance & Administration Team in allen buchhalterischen Belangen. In ihrer Freizeit ist sie mit ihrem Sohn immer auf der Suche nach den schönsten Spielplätzen in Nürnberg oder plant den nächsten Familientrip.

Just fit – just awesome: Rückenschule

This entry is part 5 of 11 in the series Just fit – Just awesome

In unsere Serie „Just fit – just awesome“ ist ja schon einiges passiert, Julia hat uns erzählt warum Bewegung wichtig ist. Vanessa erklärte uns, wieso es gesund ist, richtig zu atmen. Und Andreas und Janina haben darüber berichtet, weshalb wir viel trinken müssen und auf unsere Ernährung achten sollen.

Und heute verrate ich euch, warum wir auf unsere Haltung bei der Arbeit und auf unseren Rücken achten sollten.

An einem durchschnittlichen Tag ist der Mensch 16 bis 17 Stunden wach, und davon sitzt er bis zu 11 Stunden, egal ob im Büro, im Auto, beim Mittagessen oder abends auf der Couch. Seien wir mal ehrlich: Wer kennt das nicht, dass man lange sitzt und zwischendurch nicht aufstehen kann – oder es vielleicht auch vergisst? Und, dass man dann Rückenschmerzen hat!?

Bei einem derartigen Lebenswandel ist die Gefahr für Rückenschmerzen und spätere Schäden am Rücken sehr hoch. Und um dies zu vermeiden, sind eine richtige Körperhaltung, Übungen und Pausen vom Sitzen wichtig.

Im Grunde weiß das jedes Kind. Aber weil der Mensch ja vergesslich und der Körper bequem ist, schadet es nicht, sich dieses Wissen immer mal wieder ins Gedächtnis zu rufen. Und vor allem, ein paar Übungen parat zu haben, die schnelle Abhilfe bei Steifheit schaffen und Verspannungen vorbeugen.

Sitzt du gut?

Gesundes Sitzen am Schreibtisch ist besonders wichtig, da wir an unserem Schreibtisch die meiste Zeit des Tages verbringen. Richtig sitzt man, wenn das Becken nach vorne gekippt ist und der Oberkörper aufrecht ist. Wenn du jetzt das Gefühl hast, du machst ein Hohlkreuz, dann ist dein Becken in der richtigen Position. Die Muskulatur von Bauch und Rücken sollen gleichermaßen angespannt sein.

Man kann das kontrollieren, indem man eine Hand auf den Rücken und eine Hand auf den Bauch legt. Wenn du nach vorne kippst sollten sich die Rückenmuskeln anspannen, wenn du nach hinten kippst spannen sich die Bauchmuskeln an. Sind die Bauchmuskeln angespannter als die Rückenmuskeln, kann das irgendwann zu Rückenschmerzen führen.

Wichtig ist auch die Position von Armen und Beinen, sind diese nicht mindestens im 90-Grad-Winkel, kann es zu Durchblutungsstörungen kommen. Das passiert zum Beispiel, wenn deine Beine überkreuzt sind und das ist – du ahnst es – schädlich für den Rücken!

Dynamisches Sitzen ist ebenfalls sehr wichtig, denn wenn wir starr vor unserem Bildschirm sitzen, wird unsere Wirbelsäule monoton belastet. Das heißt, dadurch wird die Bandscheibe nicht richtig durchblutet und die Rückenmuskulatur arbeitet schwerer und wird überbelastet. Das hat zur Folge, dass wir unter Kopf- und Rückenschmerzen, Verspannungen und abfallender Leistungsfähigkeit leiden. Studien belegen sogar, dass langes und falsches Sitzen die Lebensdauer verkürzt!

Wechsle zwischen diesen drei Sitzhaltungen!

Es gibt drei Sitzpositionen, die gut für den Rücken sind und wir sollten alle 15 Minuten die Sitzposition ändern, damit wir dynamischer Sitzen:

Vordere Sitzhaltung:
Man beugt sich mit dem Oberkörper leicht nach vorn. Oberschenkel sind leicht nach hinten gebeugt und die Unterarme stützen den Körper auf dem Schreibtisch ab.

Aufrechte Sitzhaltung:
Ober- und Unterarm, sowie die Ober- und Unterschenkel bilden einen 90 Grad Winkel. Die Fersen stehen parallel zu den Kniekehlen und sind fest auf dem Boden.

Hintere Sitzhaltung:
Hier ist der Oberkörper weit nach hinten gelehnt und die Beine bilden einen offenen Winkel.

Stärke deine Muskeln

Und um den Rücken dann noch zu stärken, hier fünf Übungen, die innerhalb weniger Minuten direkt am Arbeitsplatz gemacht werden können:

1. Übung – Kopfdreher:

  • Setz dich gerade hin und leg deine Hände auf die Oberschenkel
  • Wenn du einatmest, hebst du die Knie an und drehst den Kopf leicht nach rechts
  • Beim ausatmen den Kopf wieder zurück in die Ausgangsposition drehen
  • Einatmen, den Kopf nach links

Diese Übung kannst du fünfmal pro Seite durchführen

2. Übung – Rückendehner:

  • Setz dich wieder gerade auf den Stuhl und lehn dich an
  • Beim Einatmen gehen die Hände senkrecht nach oben
  • Und beim Ausatmen wieder langsam zurück nach unten

Diese Übung sollte auch fünfmal wiederholt werden

3. Übung – Brustdehner:

  • Eine aufrechte Haltung auf dem Bürostuhl einnehmen und die Arme seitlich ausstrecken
  • Wenn du einatmest, die Arme nach hinten strecken und Brustkorb öffnen
  • Fünf Sekunden halten und dann langsam lösen

Diese Übung kann fünfmal wiederholt werden

4. Übung – Oberkörperdehner

  • Oberkörper nach vorne beugen und auf den Schenkeln ablegen
  • Den Kopf locker hängen lassen und einen Katzenbuckel machen
  • Die Fußgelenke mit den Händen umfassen und richtig dehnen
  • Diese Haltung 30 Sekunden halten und dann langsam Wirbel für Wirbel aufrollen

5. Übung – Muskeldrücker

  • Gerade hinsetzen und Arme hinter dem Rücken übereinanderlegen
  • Bauch- und Gesäßmuskeln anspannen und die Arme beim Einatmen gegen die Lehne drücken, dabei tief atmen
  • Beim Ausatmen den Druck lösen und entspannen

Diese Übung kann ebenfalls fünfmal wiederholt werden

 So und jetzt ran an den Rücken und strecken, dehnen, stärken!

Nadja Myers
Nadja Myers
Manager Finance & Administration

Nadja hat bei NETWAYS eine Ausbildung zur Kauffrau für Bürokommunikation absolviert. Als Manager Finance & Administration sorgt sie jetzt gemeinsam mit ihrem Team für die Gewährleistung des internationalen Buchhaltungsmottos "Keine Buchung ohne Beleg". In ihrer Freizeit genießt sie die Zeit mit ihrem verschmusten Kater Watson (benannt nach Sherlock Holmes' Partner Dr. Watson). Außerdem reist Nadja sehr gerne mit ihrem Mann nach Italien um dort die schöne Landschaft und die kulinarischen Köstlichkeiten zu genießen.