pixel
Seite wählen

NETWAYS Blog

4 Dinge, die neu sind bei NWS Kubernetes

Getreu dem Motto: “you answered – we listened” hat unser NWS-Platform-Team diese Woche für unsere Kunden neue Optionen zum Erstellen von Managed Kubernetes Clustern eingeführt, die im folgenden kurz erläutert und vorgestellt werden:

 

1. Neue Kubernetes Versionen

Das neueste Kubernetes Major Release 1.21 ist jetzt – einen Monat nach dem offiziellem Release – auch für NWS Kunden einsatzbereit! Änderungen und Neuigkeiten findet man wie gewohnt im offiziellen Changelog.

Neben der aktuellen Version 1.21 gibt es weiterhin die Möglichkeit, Kubernetes Cluster in den Versionen 1.18, 1.19 und 1.20 zu erstellen. Die Version 1.18 ist  jedoch bereits “End of Life” und deswegen nicht mehr unbedingt zu empfehlen.

 

Kubernetes Cluster erstellen

2. Private Cluster

Beim Erstellen eines Clusters kann man ab sofort zwischen einem “Private” oder einem “Public” Cluster wählen. Damit wird die Erreichbarkeit der Kubernetes-API des Clusters gesteuert. Ein privater Cluster hat nur eine interne IP und keine weitere öffentliche Floating-IP und ist dementsprechend nur von innerhalb der Kundenumgebung (OpenStack- oder Kubernetes-Projekt) erreichbar oder via VPN.

 

3. Individuelle Subnetze

Ebenso kann beim Erstellen eines neuen Clusters das Subnetz – in dem die Nodes kommunizieren – frei gewählt werden. Das ist insbesondere dann hilfreich, wenn man einen privaten Kubernetes Cluster per VPN mit einem bestehenden Firmennetz verbindet!

 

4. Rotate CA

Das Rotieren der Kubernetes CA kann jetzt über die Web-Oberfläche angestoßen werden. Es wird eine neue Cluster CA erzeugt und entsprechend neue Schlüssel und Zertifikate für Service-Accounts und Kubernetes-Nodes verteilt. Die bestehende kubeconfig-Datei des Administrators muss dann durch eine neue ausgetauscht werden.

 

Kubernetes Tutorials

Wer sich nochmal eine genaue Anleitung, wie man schnell und einfach sein Managed Kubernetes bei NWS aufsetzt, durchlesen möchte, der findet diese und viele weitere Kubernetes Tutorials auf unserer Website. Gerne mal vorbeischauen!

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

NWS bekommt einen neuen Anstrich

Harte Arbeit, “Blut” und Schweiß und ein Ergebnis, das sich sehen lässt: Nach unserer Website erscheint nun auch das Kundeninterface in neuem Glanz!

Neben purer Ästhetik für Farben und Formen ging es uns natürlich auch darum, die Bedienung komfortabler und intuitiver zu gestalten. Zudem wurde es mit dem ein oder anderen neuen Feature beschenkt. Geburtstag wurde schließlich auch gefeiert. Aber der Reihe nach. Seit dem Start unserer NWS-Plattform im März 2017 sind ziemlich genau 4 Jahre vergangen.

 

Happy Birthday NWS!

 

 

Nun zum Kundeninterface:

 

Die Idee

Wie bei einem Kleinkind in diesem Alter sind viele – nicht alle – Kinderkrankheiten bereits überstanden und die ersten Gehversuche liegen hinter uns. Die Welt wird neugierig und furchtlos erkundet. Um in dieser Bildsprache zu bleiben: Wir haben unsere Kinderschuhe nun zur Seite gelegt und unser erstes Paar neue Sneakers geschnürt. Nachdem unsere Website bereits vor geraumer Zeit komplett überarbeitet wurde, war es letztendlich nur die logische Konsequenz, auch das Kundeninterface anzupassen. Neben unseren eigenen Ideen wurden unsere Erkenntnisse aus den letzten Jahren – und das wertvolle Feedback unserer immer größer werdenden Kundschaft – umgesetzt.

 

Bedienung

Die Navigation und das Bedienungskonzept standen zu Beginn im Vordergrund. Die größte Herausforderung war sicher, alle unterschiedlichen Produkte unter einen Hut zu bekommen. Eher einfache Produkte wie Jitsi – auf der einen Seite – und eher komplexe wie Managed Kubernetes oder unsere Cloud auf Basis von OpenStack, auf der anderen: Alle Produkte sollten einem Prinzip folgen und sich in der Bedienung und im Konzept ähnlich verhalten. Viele Stunden Brainstorming und einige Diskussionen später stand unsere Entscheidung fest: Sämtliche Produkte organisieren sich in unserer Hauptnavigation – egal, ob es bereits gebuchte oder neue Produkte sind. Gebuchte Produkte ordnen sich allerdings zuerst ein, da sie schließlich das Wichtigste für den Bedienenden sind. Wählt man eines aus, erhält man eine zweite Navigationsleiste, die nur Menüpunkte für das Produkt beinhaltet. Die dritte und letzte Ebene ist der jeweilige ausgewählte Inhalt. Durch die klare und nicht allzu tiefe Hierarchie ist es einfach und nachvollziehbar, wo man sich gerade in der Applikation befindet. Zusätzlich verliert man – durch die beiden stillstehenden Navigationen – seinen Fokus nicht und wird nicht unnötig abgelenkt.

 

 

Farben und Formen

Der neue Stil ist clean und simpel. Unsere Farbpalette der NETWAYS Web Services wurde übernommen und rundet das Erscheinungsbild ab. Die gewählte Schriftart “Montserrat” wirkt modern. Wiederkehrende Elemente wurden im Backend durch dynamische Templates gestaltet und helfen dem einheitlichen Erscheinungsbild. Die Icons unserer Produkte wurden per Hand neu gezeichnet.

 

 

 

Features

Neben der neuen Benutzerführung gibt es viele kleine Verbesserungen für bereits etablierte Elemente. Unser MyEngineer-Service hat einen omnipräsenten Navigationspunkt bekommen, um stets Zugriff auf seine Tickets, Zeiten und den Kontakt zu unseren Kollegen zu haben. In der Übersicht gibt es neben einem “Activitiy Log”, das die letzten Nutzeraktivitäten darstellt, außerdem Informationen über anstehende oder akute Wartungsarbeiten oder Ausfälle und weitere Informationen, wie beispielsweise hilfreiche Tutorials. Jedes Produkt hat jetzt eine Übersicht, in der die wichtigsten Schritte, weiterführende Links oder teilweise kurze und prägnante Tipps für die Verwendung des Produkts zu lesen sind.

 

 

 

Ausblick

Mit dem Ergebnis sind wir wirklich zufrieden und stolz. Ich denke, unsere Kunden werden es ebenso mögen. In den nächsten Wochen stehen bereits die nächsten geplanten Releases an, die unter anderem die Bedienung unserer Cloud betreffen. Mehr soll aber jetzt noch nicht verraten werden.

 

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Edge-Cloud-Computing – Cloud to the Edge

Während man in Deutschland immer noch und immer wieder in Funklöchern sitzt und oftmals nur 2G als Datenübertragung nutzen kann, bereitet sich die Welt – auch Deutschland – auf den nächsten Standard vor: 5G. Die neue Generation besticht durch hohe Bandbreiten (~1-20Gbps), niedrige Latenzen und eine hohe mögliche Dichte von Geräten auf neuen Frequenzbändern, die natürlich heiß begehrt sind. Braucht man aber solch hohe Bandbreiten und niedrige Latenzen um seine E-Mails zu checken oder Social Media Inhalte zu betrachten? Wohl eher nicht. Diese neuen Anforderungen an das Netzwerk benötigen aber Anwendungen, die in Zukunft vermutlich nicht mehr wegzudenken sind und maßgeblich unsere Welt verändern könnten – so zumindest die Vision. Autonomes Fahren, künstliche Intelligenz, Augmented- und Virtual-Reality und Internet of Things sind nur einige Anwendungsbereiche, die durch den neuen Standard ihre Möglichkeiten besser ausschöpfen können.

Ein völlig autonom fahrendes Auto, gespickt mit mehreren hundert Sensoren und vielen Kameras, produziert eine gewaltige Menge an Daten, die in einer Cloud zum Beispiel zur Koordination anderer Fahrzeuge eingespeist und verarbeitet werden. Ein weiteres Beispiel wäre die Videoüberwachung in einer U-Bahn kombiniert mit den Aufzeichnungen der Kameras vom Bahnsteig, die in Echtzeit menschliche Verhaltensmuster analysiert oder gar erlernt und entsprechend entscheidet. Benötigt es eine Vollbremsung, weil ein Passant gerade am Bahnsteig mit böser Absicht geschubst wird oder ist es eher eine harmlose Situation unter Freunden? Damit das funktioniert, benötigt man nicht nur ein schnelles Mobilfunknetz sondern auch Edge-Cloud-Computing.

Edge-Cloud-Computing

Edge-Cloud-Computing ist zu Recht einer der letzten und heißesten Trends im Bereich Cloud-Computing. Dabei gilt es, seine zentrale Cloud an den Rand (Edge) zu bewegen – also näher an den Kunden. Mit anderen Worten eine verteilte Cloud. Was genau jetzt der Rand sein soll ist noch nicht so ganz klar, man nimmt einen Bereich an, der nicht weiter als 20ms vom Endgerät entfernt ist. An diesem Rand ist es also nun notwendig, seine Cloud-Compute-Ressourcen verfügbar zu haben und nutzen zu können, um entsprechende Workload darauf zu betreiben. Ob die Workload in Containern, VMs oder Bare-Metal betrieben wird ist eher nachrangig zu betrachten, der Mix wird es sein. Dabei stützt man sich auf bestehende Technologie-Komponenten wie etwa Ceph, Qemu, Kubernetes, DPDK, OpenVSwitch und so weiter. 5G alleine wird also ohne Edge-Computing vermutlich nicht reichen, um zukünftigen Anwendungen gerecht zu werden.

Die beiden Open-Source Cloud-Lösungen, OpenNebula und OpenStack, die wir auch bei NETWAYS im Einsatz haben, sind natürlich bereits auf den Hype-Train aufgesprungen. OpenNebula hat gleich ihr gestriges Release 5.8 dem Codenamen “Edge” verpasst und OpenStack hat mit StarlingX sein eigenes Projekt und ein “Edge Computing Group” Gremium ins Leben gerufen.

Man kann wirklich gespannt sein was die Zukunft bringen wird und wie die Herausforderungen technisch realisiert werden.

Anwendungen, die ohne 5G und Edge auskommen, können aber auch schon heute in unserer Cloud basierend auf OpenStack modern, zeitgemäß und zukunftssicher betrieben werden.

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Road to OpenStack

Seit bereits sieben Jahren betreiben wir bei NETWAYS eine Private Cloud Installation auf Basis von OpenNebula. Damals starteten wir gerade einmal mit drei Hypervisor Servern und einem NFS-Datastore, bereitgestellt aus einer Netapp 3140. Bis heute hat sich daran natürlich einiges verändert. Die Technologien haben sich geändert, als auch die notwendigen Ressourcen sind deutlich gestiegen. Heute laufen zum Beispiel unsere virtuellen Maschinen nicht mehr auf NFS sonder auf Ceph RBDs. Das Ceph-Cluster, verteilt über zwei Standorte, umfasst aktuell knapp ein halbes Petabyte Storage Kapazität.
OpenNebula hat uns während dieser Zeit der Transformation immer gut und zuverlässig zur Seite gestanden. Sämtliche Upgrades verliefen meist tadellos. Deshalb ist es fast ein bisschen Schade, diesem tollem Open-Source-Projekt den Rücken zu kehren und von nun an mit dem Platzhirsch OpenStack zu liebäugeln. Einer der Hauptgründe diesen Schritt zu gehen – neben beispielsweise der oft besseren und breiteren Verfügbarkeit an Integrationen und Tools von Dritten (z.B. Foreman, Puppet, Terraform usw.) – ist Software Defined Networking. Kurz SDN. Natürlich gibt es hierfür auch gute Ansätze und eine Basis-Unterstützung im OpenNebula Projekt. Theoretisch gibt es sogar die Möglichkeit fast jeden SDN Provider in OpenNebula, dank seiner Erweiterbarkeit, zu integrieren, aber leider nicht ohne selbst vorher ordentlich Pionierarbeit leisten zu müssen. Bei OpenStack hat man eher die Qual der Wahl, welcher SDN Provider für sein Setup passt.
Mit SDN virtualisiert man in einem Overlay Netzwerk ein künstliches und unabhängiges Netzwerk, ohne dass man das Underlay, die tatsächliche Hardware z.B. Switches und Router, auf die jeweiligen Umstände und Anforderungen anpassen muss. Die Vorteile liegen dabei auf der Hand: Im Underlay hat man ein stabiles Trägernetzwerk, dass man im Prinzip nur noch skalieren und robust betreiben muss und im Overlay werden die Anforderungen der Kunden realisiert. Wir setzen hierbei im Underlay auf Cumulus Linux in Kombination mit Mellanox Hardware und im Overlay auf die SDN Lösung von Midonet. Beides harmoniert gut miteinander und kann entsprechend verknüpft werden.
In unserer neuen Cloud-Installation ist es für uns und unsere Kunden dann dadurch möglich im Self-Service sich Netzwerke, Router, VPNs, Load-Balancer und Firewall-Regeln zu erstellen, ohne hierfür vom Administrator Hilfe und Beistand einzufordern. Auch überlappende private Netzwerke sind dann kein Problem und eine Pflege und penible Vergabe von IPs und Subnetzen bzw. VLANs fallen somit vom Tisch.
Klar ist, der Self-Service Part könnte mit OpenNebula in unserer bisherigen Installation ebenfalls gelöst werden, allerdings beeindruckt insbesondere die technische Umsetzung und das sehr raffinierte und intelligente Konzept der SDN Lösung von Midonet. Wie das ganze technisch funktioniert erklären wir im Blog in einem unserer nächsten Artikel.

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Docker Overlay Network

In den letzten Versionen von Docker hat sich im Bereich Netzwerk einiges getan. Man konnte sich zwar schon seit längerem mit Projekten wie Calico, Flannel oder Socketplane ein Multihost Docker Netzwerk schaffen, aber seit dem Zusammenschluss von Docker und Socketplane und dem daraus gewachsenem libnetwork gibt es jetzt Multihost Docker Networking out of the box.
Damit man es nutzen kann benötigt man neben einer sehr aktuellen Docker Version auch einen zentralen Key-Value Store wie Zookeeper, Etcd oder Consul. Sofern alles richtig konfiguriert ist, erstellt man ein Netzwerk vom Typ ‘Overlay’ mit dem Docker-CLI oder wer es braucht über die Docker API.
docker network create --driver overlay --subnet=10.0.9.0/24 my-net

Ein Container, der sich diesem Netz anschließen soll wird dann ebenfalls wie gewohnt gestartet, jedoch zusätzlich mit dem Zusatz --net, der das entsprechende Netzwerk bestimmt.
docker run -itd --name=web --net=my-net nginx

Ein zweiter, dritter oder x-ter Container auf anderen Hosts wird nach dem gleichem Schema gestartet und schon hat man in dem angegeben IP-Subnetz ein eigenes und neues isoliertes Netzwerk über mehrere Hosts hinweg, über das die Container direkt miteinander kommunizieren können, ohne Umwege wie z.B. über einen Service-Discovery Loadbalancer machen zu müssen.
Das ganze wirkt fast schon magisch und ist für ein so komplexes Thema super leicht zu konfigurieren und zu nutzen. Hinter den Kulissen wird über den VxLAN Standard ein Layer2 Netzwerk (10.0.0.9/24) über Layer4 (UDP) hinweg getunnelt. Das Virtual extensible LAN verhält sich ähnlich zu einem gewöhnlichen Layer2 VLAN, hat jedoch in sehr großen Umgebungen seinem etabliertem VLAN Namensvetter einiges voraus. Die Anzahl der möglichen VLANs wächst von 4094 auf über 16 Millionen. Broadcast Traffic wird zu Multicasts gemapped und vieles mehr.
Wer mehr zu dem Thema wissen will und in entspannter Atmosphäre und isolierten Testumgebung ausprobieren möchte, dem sind unsere Docker Trainings und auch der Docker Workshop vor der OSDC sehr zu empfehlen.

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.