syseleven

[syseleven]

Der Kubernetes Hype: Mit MetaKube ein eigenes Produkt

Der Hype um Kubernetes ist ungebrochen. Aber was genau bedeutet es, wenn Kubernetes Dein Job ist und Du mit MetaKube einen neuen Kubernetes Dienst aus Deutschland kreiert hast? Wir haben mit den SysEleven Experten Olaf und Simon genau darüber gesprochen und warum es für beide eine gute Sache ist, Teil der SysEleven Familie zu sein.

Was macht das Thema “Kubernetes” für euch so spannend?

Simon: Kubernetes macht einfach mehr richtig als andere Tools. Es kümmert sich beispielsweise darum, dass Deine Applikation lebt, ohne dass wir da eingreifen müssten.

Olaf: Stimmt. Kubernetes verändert unsere traditionelle Operations-Arbeit massiv. Und zwar zum Besseren! Wenn früher zum Beispiel ein Web- oder App-Server abgeschmiert ist, musste ein Kollege aus Operations raus und ihn neu von Hand starten. Oder wenn die Last stieg, musste man nachts raus und ein paar Webserver bauen, um die Last zu verteilen. Das sind ja alles Sachen, die Kubernetes maschinell übernimmt. Und das sogar echt vernünftig inkl. Infrastrukturzuweisung oder einer eigenen API, so dass man eigene Dienste deployen und weiter automatisieren kann.

Simon: Bei Docker bzw. Kubernetes skalierst Du tatsächlich Applikationen. Und das mit einem super geringen Overhead.

Olaf: Aber man muss echt betonen: Ohne Dockerhub wäre der Hype nicht da. Weil “Docker run Ngnix” ist im Endeffekt der Grund, warum es heute so einfach ist zu spawnen oder zu betreiben.

Wie kam es zu der Idee von MetaKube?

Simon: Wir wollten unseren Kunden eine Container-Infrastruktur anbieten. Wir mussten aber relativ schnell einsehen: Wenn wir für jeden Kunden ein Kubernetes-Cluster erstellen, wäre der Wildwuchs nicht mehr weit gewesen. Dann hätten wir auf einmal an die 100 Cluster managen müssen. Da wären wir ja nur noch mit für unsere Kunden ineffizientem Management als mit allem anderen beschäftigt…

Olaf (schmunzelt): Wir sind halt nicht so die klassischen Manager-Typen.

Simon: Genau! Und für den Kunden hätte das unnötige Overheads bedeutet.

Olaf: Dadurch dass wir Control Planes der Kundencluster zentral managen, können wir Ressourcen viel effizienter verwalten. Außerdem können wir unseren Kunden so besser und schneller helfen. Das war ehrlich gesagt das größte Ziel bei MetaKube: Wir wollten es dem Kunden einfach machen, Kubernetes für sich zu nutzen. Quasi den komplizierten Teil abnehmen, so dass der Kunde direkt produktiv sein kann.

Simon: Und das haben wir erreicht. Mit MetaKube hast Du in 5 Minuten Dein eigenes Cluster und kannst loslegen. Wir sind dabei als Team immer im Hintergrund und stehen mit Rat und Tat zur Seite.

Wie ist es für euch, mit MetaKube ein eigenes Produkt aus der Taufe zu heben?

Simon: Es ist cool, wenn man etwas baut, dass die Kunden dann auch benutzen wollen. Und wenn wir positives Feedback bekommen — sowohl vom Kunden als auch den Kollegen.

Olaf: Ja, da fallen mir auch unsere internen und externen MetaKube Workshops ein, die Basti und Du regelmäßig haltet. Da sieht man, dass unser Fachwissen wirklich geschätzt wird und der manchmal mühsame Weg, es zu erlangen, sich gelohnt hat.

Simon: Stimmt. Plus wir haben natürlich viel mehr Freiheiten und Flexibilität, da wir MetaKube entwickeln. Hätten wir zum Beispiel einfach Openshift eingekauft und es würde etwas nicht laufen, dann könnten wir nur ein Ticket beim Hersteller aufmachen und unsere Kunden könnten nicht arbeiten. Das entspricht einfach nicht dem Anspruch von SysEleven.

Olaf: Wir setzten ja auf dem Produkt Kubermatic unseres Partners Loodse auf. Hier haben wir zum Beispiel Quellcode-Zugriff, obwohl es nicht rein OpenSource ist. So können wir nicht nur Request stellen, sondern entwickeln auch selber neue Lösungen zum Beispiel für Backup, Monitoring oder WebUIs.

Simon: SysEleven ist auch als einer der wenigen in Deutschland als Certified Hosting Provider der CNCF gelistet — und der damit die Vorgaben erfüllt. Das macht uns schon stolz.

Wie ist es eigentlich für Euch, direkten Kundenkontakt zu haben?

Simon: Das ist super. Natürlich mag es auf den ersten Blick etwas beängstigend sein, weil theoretisch ja auch negative Kritik kommen kann. Aber das ist bis jetzt Gott sei Dank noch nicht vorgekommen.

Olaf: Wir entwicklen ja für den Kunden und nicht fürs stille Kämmerlein. So verstehen wir auch unseren Support: Pro aktiv und nachhaltig. Wenn wir im Monitoring erkennen, dass etwas im Kundencluster nicht stimmt, dann fixen wir es — oft bevor der Kunde es überhaupt festgestellt hat — und erklären dann dem Kunden, was wir gemacht haben. Das sind immer gute Gespräche auf Augenhöhe und am Ende werden so alle nur besser.

Letzte Frage: Was macht SysEleven für Euch besonders als Arbeitgeber?

Olaf: Ich hab echt das Gefühl, dass wir den Kunden weiterbringen können. Und das ist ein gutes Gefühl. Außerdem ist SysEleven selbst finanziert und wir können deshalb ohne Investorendruck arbeiten — ich glaube das ist in Berlin wirklich selten geworden. Außerdem sind wir echt ein richtig gutes Team!

Simon: Bei SysEleven kann ich mit MetaKube etwas bauen, dass Menschen wirklich benutzen wollen. Außerdem können wir uns hier mit Gleichgesinnten austauschen. Das Fachwissen der Kollegen ist bemerkenswert und zudem fahren wir regelmäßig auf internationale Konferenzen, um uns weltweit zu vernetzen und Wissen zu teilen. Für uns gilt: Je mehr Kommunikation, desto leichter fällt es, besser zu werden.

Gerne zeigen Dir Simon, Olaf und der Rest des Teams, wie Du mit Kubernetes erfolgreich sein kannst. Zum Beispiel bei unseren Workshops oder bei einem Kaffee in Berlin-Friedrichshain! Du möchtest Teil des Teams werden? Dann findest Du hier alle IT-Jobs, die wir aktuell ausgeschrieben haben.

Mehr News aus der IT-Welt auf: www.syseleven.de/blog

#Metakube #kubernetes #kubernetescluster #Docker

[syseleven]

Verbesserungen der Shared-Secrets-Webanwendung

Vor etwas mehr als drei Jahren hatten wir hier im Blog die Open-Source-Veröffentlichung unserer Shared-Secrets-Webanwendung bekannt gegeben und damit genau das erreicht, was wir erreichen wollten: Mehr Augen schauten auf die Anwendung und fanden Probleme mit der eingesetzten Logik. Die Sicherheit der eigentlichen Verschlüsselung stellte nie das große Problem dar, da mit GnuPG auf einen etablierten Standard gesetzt wurde. Auf Basis von GnuPG die Nur-Einmal-Lesen-Eigenschaft aufzubauen, führte jedoch wiederholt zu Anpassungsaufwänden.

Die Änderungen über die Zeit teilen sich grob in zwei Kategorien — auf der einen Seite die Änderungen, die Feature-Verbesserungen mit sich brachten und auf der anderen Seite Änderungen, die erforderlich waren, um Schwächen in der gewählten Verschlüsselung zu umgehen.

Feature-Verbesserungen

Kommen wir erstmal zu den Featureverbesserungen:

Es wurde der Wunsch nach einer zusätzlichen lokalen Verschlüsselung laut, damit der Server zwar die Nur-Einmal-Lesen-Eigenschaft durchsetzt, selbst das eigentliche Geheimnis jedoch nicht mitlesen kann.

Intern wurde festgestellt, dass die Base64-Encodierung aufgrund der unüblichen Sonderzeichen die Links in Mails kaputt machten, sodass diese nicht mehr einfach angeklickt werden konnten. Daher wurde auf URL-safe Base64-encodierte Links gewechselt.

Wir selbst haben die Anwendung immer nur mit NGINX betrieben. Plötzlich war ein Nutzer da, der gern Apache verwenden wollte und in Probleme mit den langen URLs geriet. Mit einem kleinen Bugfix konnte das Problem aus der Welt geschafft werden.

Verschlüsselungsrelevante Verbesserungen

Als nächstes sehen wir uns einmal an, welche verschlüsselungsrelevanten Themen über die Jahre bearbeitet wurden:

Um die API zur Nutzung von GnuPG ordentlicher zu gestalten, wurde der Support für das GnuPG-PECL eingeführt. Es stellte sich jedoch bald heraus, dass das GnuPG-PECL Integritätsfehler nicht korrekt zurückgab, was direkte Auswirkungen auf die Nur-Einmal-Lesen-Eigenschaft von Shared-Secrets hatte. Daher führten wir zuerst eine Warnung ein, das GnuPG-PECL nicht zu nutzen und schalteten schlussendlich den GnuPG-PECL Support vollständig ab.

In diese Zeit fiel auch das Finding eines Bloglesers, dass durch Anfügen von Parametern an die URL eine URL mehrfach abrufbar wurde. Das Problem wurde durch verbessertes Parsen der URL behoben, doch erst nach dem initialen Fixen der Lücke wurde uns klar, dass eigentlich die fehlende Integritätsprüfung des GnuPG-PECL diese Lücke geöffnet hatte.

Im Jahr 2018 wurde die Efail-Lücke bekannt. URLs, die direkt von der Anwendung generiert wurden, waren nicht betroffen, lokal erzeugte URLs jedoch potentiell schon. Daher bauten auch wir einen weiteren Check ein und verweigerten das Entschlüsseln von nicht integritätsgeschützten URLs.

Mit neueren GnuPG-Releases wurde zusätzliche Konfiguration erforderlich, um die verbliebene Aufrufmöglichkeit weiterhin nutzen zu können. Die Erkenntnis und die dokumentierte Lösung kamen hierbei von extern.

Modification Detection Code

Wie man an der Auflistung erkennt, wurde ein großer Teil der Arbeit darauf verwandt, die verwendete GnuPG-Verschlüsselungsbasis abzusichern und um die Unzulänglichkeiten der Integritätssicherung herumzuarbeiten. Die Efail-Lücke letztes Jahr hat uns an dieser Stelle die Augen geöffnet, genauer gesagt ein Schlagwort, das dabei immer wieder in sämtlichen Nachrichtentiteln gefallen ist: der Modification Detection Code (MDC). Beim initialen Entwickeln der Shared-Secrets-Webanwendung war die Annahme, dass GnuPG die erzeugten Nachrichten entsprechend des Stands der Technik (sprich: vollständig) integritätssichern würde. Mit Blick auf den RFC 4880 stellt man jedoch fest, dass der MDC sich nur auf die symmetrisch verschlüsselten Daten bezieht:

The Modification Detection Code packet contains a SHA-1 hash of plaintext data, which is used to detect message modification. It is only used with a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place.

Das heißt, dass es bisher — trotz des Einsatzes des MDC — möglich gewesen wäre, eine Shared-Secrets-URL zu parsen, die GnuPG-Nachricht mit weiteren Paketen zu ergänzen und im Anschluss die geänderte URL erneut abzurufen, da die hinzugefügten Pakete nicht Teil der Integritätsprüfung gewesen wären. Bei dieser Erkenntnis ist uns klar geworden, dass GnuPG für den angestrebten Zweck nicht sinnvoll einsetzbar ist, denn dieser besteht daraus, Nachrichten eindeutig erkennen und deren erneuten Abruf unterbinden zu können.

Unsere Anforderungen an das neue Verschlüsselungssystem

Gleichzeitig wollten wir den bisherigen Vorteil der Shared-Secrets-Webanwendung nicht verlieren: Bisher war es möglich, Shared-Secrets-URLs lokal in der Shell zu erzeugen, die kompatibel zum Abruf mit der Webanwendung sind. Das bedeutete für uns, dass die neue kryptographische Basis der Anwendung so gebaut sein musste, dass diese möglichst ohne unübliche Tools lokal realisierbar ist. Unsere Wahl fiel daher auf OpenSSL und ein eigenes Nachrichtenschema, das die Vorteile von GnuPG aufwies, ohne dessen Nachteile mitzubringen:

Die Verschlüsselung sollte hybrid erfolgen: Durch den asymmetrischen Anteil der Verschlüsselung sollte sichergestellt sein, dass man Nachrichten lokal verschlüsseln kann, diese jedoch nur vom Server wieder entschlüsselt werden können.

Der gesamte Nachrichteninhalt inklusive aller erforderlichen Metadaten sollte mit einem Message Authentication Code (MAC) versehen sein, sodass alle Änderungen an der verschlüsselten Nachricht auffallen würden.

Vorteile des neuen Verschlüsselungsschemas

Das Ergebnis der Überlegungen ist in einem separaten technischen Dokument beschrieben. Es wurden konservative Verschlüsselungs- und Hashalgorithmen gewählt, die dank einer enthaltenen Versionierung der Nachrichtenformate zukünftig aktualisiert werden können. In der Implementierung haben sich durch das neue Verschlüsselungsschema einige Vorteile ergeben:

Es kann nun verhindert werden, dass Nachrichten an mehrere Empfänger entschlüsselt werden, was die Nur-Einmal-Lesen-Eigenschaften bisher zerstört hat.

Der Fingerprint zum Erkennen von bereits gesehenen Nachrichten ist nun direkt der Message Authentication Code der verschlüsselten Nachricht.

Dank des eindeutig definierten Nachrichtenformats können nun zu erwartende Nachrichtenlängen direkt berechnet werden. Dadurch war es möglich, die unterstützte Maximallänge von Nachrichten zu verlängern und mehrzeilige Geheimnisse zuzulassen.

Da wir auch ein Nachrichtenformat für rein symmetrische Nachrichten definiert haben, konnten wir für die Browser-basierte lokale Verschlüsselung von 3rd Party JavaScript-Krypto-Libraries auf die inzwischen existierende Web Cryptography API des W3C wechseln. Dank des wesentlich besseren Einblicks in das Verschlüsselungsschema ist es nun sogar möglich, die im Browser stattfindende Zusatzverschlüsselung auch lokal in der Shell abzubilden.

Natürlich haben wir auch weiterhin an den damals gesetzten Zielen festgehalten: Die Instanz, die wir unter secrets.syseleven.de betreiben, hat weiterhin A+ Ratings sowohl von Qualys SSL Labs als auch vom Mozilla Observatory.

Wir hoffen, mit der kritischen Betrachtung der Sicherheitseigenschaften und dem Neubau der kryptographischen Basis der Shared-Secrets-Webanwendung einen weiteren Beitrag zur Sicherheit unserer Kunden und externen Partner geleistet zu haben.

Mehr News aus der IT-Welt auf: www.syseleven.de/blog

#Shared-Secrets-Webanwendung #Featureverbesserungen #Verschluesselungssystem #Verschluesselungsschemas #itsicherheit

[syseleven]

SysEleven bezwingt Nextcloud Verschlüsselung

Photo by Glenn Carstens Peters (npxXWgQ33ZQ-unsplash)

Anfang des Jahres stießen wir mit unserer internen Nextcloud-Instanz auf folgendes Problem: Dateien, die zwischen Ordnern verschoben werden sollten, gingen kaputt. Da wir zeitgleich einen weiteren Bug im Desktop-Client fanden, gingen wir erst einmal davon aus, dass es sich auch hierbei um ein Problem des Clients handelte. Auch nahmen wir an, dass viele Dateien gleichzeitig verschoben werden müssten, um den Fehler auszulösen.

Das änderte sich, als der Fehler erneut auftrat, obwohl die Person die Dateien über die Weboberfläche verschieben wollte. Ab dem Zeitpunkt war uns klar, dass es sich um einen Bug im Nextcloud-Server selbst handeln musste. Zur gleichen Zeit hatte eine weitere Person einen ähnlichen Bug gemeldet, an den wir uns bei unserer eigenen Spurensuche nun anhingen.

Vom Bugfixing zum Notfall-Toolset

Im Laufe der Bearbeitung des Problems grub sich unser Security-Team in die serverseitige Verschlüsselung von Nextcloud ein, da das Problem der defekten Dateien direkt mit der Verschlüsselung in Verbindung zu stehen schien. So wurden Stück für Stück Skripte entwickelt, um die Ver- und Entschlüsselung ohne einen Nextcloud-Server durchführen zu können. Diese Skriptsammlung ist inzwischen unter dem Namen nextcloud-tools als Open-Source-Projekt auf Github veröffentlicht worden. Ebenso warf das Team einen Blick auf die Konfiguration der Verschlüsselung und erarbeitete hierfür eine vollständig funktionierende Einrichtungsanweisung.

SysEleven erweitert die Nextcloud Dokumentation

Nachdem das eigentliche Problem identifiziert und behoben war, machte sich das Security-Team daran, eine umfassende Dokumentation der serverseitigen Verschlüsselung von Nextcloud zu erarbeiten. Da das initiale Sammeln dieses Wissens einige Zeit benötigt hatte, war es nicht hinnehmbar, dass es einfach wieder verloren gehen könnte. Die dabei entstandene Beschreibung hat nun vor kurzem sogar Einzug in die offizielle Nextcloud-Dokumentation gehalten und steht inzwischen allen interessierten Administratoren und Entwicklern zur Verfügung.

Wir als SysEleven sind stolz, eine ganze Reihe von IT-Experten im Unternehmen zu haben, die sich bis auf Design- und Codeebene in Anwendungen einarbeiten, Probleme finden und beheben können. Als aktiver Nutzer von Open-Source-Software geben wir im Anschluss auch gern unser Wissen und unsere Erkenntnisse an die Community zurück.

Mehr News aus der IT-Welt auf: www.syseleven.de/blog

#nextcloud #nextcloud Dokumentation #Open-Source-Software #it-experten

[syseleven]

Managed Hosting - Zertifikatsketten und Zertifikate

Zum Managed Hosting gehört mehr als nur der Betrieb von Servern. Dazu gehören auch komplexe Themen wie HTTPS und Zertifikatsketten. Wir erklären, wie sie funktionieren, welche Fehler dabei am häufigsten gemacht werden und wie wir diese Fehler beheben.

HTTPS und Zertifikatsketten

Verschlüsselung ist heikel. An ihr hängen die Vertrauenswürdigkeit einer Seite und die Sicherheit von Kundendaten. Auch die Performance kann beeinflusst werden. Für die Sicherheit sind folgende drei Aspekte entscheidend:

verwendete Protokolle (SSL vs. TLS)

zugelassene Cipher

benutzte Zertifikatsketten (Root-CAs, Intermediates und Zertifikate)

Bei den Protokollen (SSL/TLS) gilt immer TLS1.0 oder höher. Es gibt Ausnahmen, aber die machen wir bei SysEleven nicht ohne auf die Gefahren hinzuweisen. Die Cipher sind für die Verschlüsselung zuständig. Hierbei setzen wir auf Sicherheit und Verfügbarkeit: mit weit verbreiteten Ciphern und Prefer Server Cipher Order.

Erfahre mehr im SysEleven Blog

#managed hosting #Zertifikatsketten #zertifikate #authentifizierung

[syseleven]

GAIA-X - Die Europäische Cloud

Die jüngsten Ereignisse in Bezug auf Datenschutz und Datensouveränität machen es unabdingbar, dass wir uns vor dem langen Arm der US-Konzerne und damit einer vollständigen Überwachung unserer personenbezogenen Daten schützen. Mit dem neusten EuGH-Urteil ist das “EU-US Privacy Shield” Geschichte. Daher ist es für uns ein Anliegen “Die Europäische Cloud”, GAIA-X, als vollwertiges Day-1-Mitglied zu unterstützen und den digitalen Fortschritt für Europa voranzutreiben. Die Europäische Cloud wird unverzichtbar Der „Privacy Shield“ und die sogenannten Standardvertragsklauseln (SCC) stehen auf der Kippe. Das bedeutet, dass ein neues Licht auf die Vertrauenswürdigkeit von CDN-basierten IT-Sicherheitslösungen US-amerikanischer Hersteller geworfen werden muss. Damit rückt die europäische Cloud eine Alternative für den EU-Cloud-Markt in den Fokus. Das Projekt GAIA-X vom Bundesministerium für Wirtschaft und Energie wird nicht nur von der Politik beeinflusst, sondern auch von Vertretern aus Wirtschaft, Verbänden und mittlerweile von 300 Unternehmen aus Europa. Als Cloud- und Kubernetes-Anbieter aus Deutschland wollen wir als SysEleven einen wichtigen Teil für mehr Datensouveränität und -sicherheit leisten. 59 % der Unternehmen sehen Gefahren durch einen Datenzugriff durch die USA 

Erfahre mehr im SysEleven Blog

#EU-US Privacy Shield #Gaia-X #Datenschutz #cloud

[syseleven]

Rocketchat - Unsere Alternative zu Slack

Muss es immer Slack sein???

“Es muss nicht immer Slack sein” titelte golem.de unlängst. Dies nehmen wir zum Anlass, unsere Chatlösung auch einmal vorzustellen. Anfang 2015 startete SysEleven mit Hipchat, was zu diesem Zeitpunkt noch von Atlassian vertrieben wurde. Das erschien uns als eine gute Lösung, weil auch andere Produkte von Atlassian eingesetzt wurden und auch immer noch werden. Mittlerweile ist Hipchat bekanntermaßen von Slack übernommen worden. Das betraf uns jedoch nicht mehr, denn Mitte 2016 stürzten wir uns in das Experiment Rocketchat, das zu diesem Zeitpunkt gerade mal Version 0.36.0 erreicht hatte.

Warum Rocketchat? Erfahre mehr im SysEleven Blog

#Unternehmenskommunikation #Unternehmenschat #Rocketchat

[syseleven]

Auswirkungen des EuGH gekippten EU-US Privacy Shield

Photo by Matthew Henry (fPxOowbR6ls-unsplash)

Nachdem am 06. Oktober 2015 das Safe-Harbor-Abkommen für ungültig erklärt wurde, folgt nun das “EU-US Privacy Shield”. Der Europäische Gerichtshof hat den transatlantischen Datenpakt für ungültig erklärt. Dieses Urteil wird drastische Auswirkungen auf viele Unternehmen haben und den gesamten Markt kräftig aufrütteln.

Doch was ist genau passiert und was bedeutet das?

Nach dem lang erwarteten Urteil des EuGH ist eine der wichtigsten Rechtsgrundlagen für den Transfer personenbezogener Daten europäischer Bürger in die USA für nichtig erklärt worden. Dies geht zurück auf einen Rechtsstreit zwischen dem österreichischen Juristen Max Schrems und Facebook. Schrems hat in den letzten 5 Jahren einen Kampf gegen Facebook Irland geführt. Insbesondere, das Facebook Irland seine Daten an den Mutterkonzern in die USA weiterleitet, obwohl diese personenbezogene Daten nicht angemessen gegen US-Überwachungsprogramme gesichert sind. Facebook ist in den USA dazu verpflichtet, an US-Behörden wie der NSA und FBI Zugang zu Daten zu gewähren – ohne dass Betroffene dagegen vorgehen können.

Das Urteil liest sich im ersten Moment wie ein revolutionärer Schritt in Richtung EU-Datenschutz und -Sicherung für personenbezogene Daten. Doch mit einem Blick auf weitere Details wird es noch spannender:

Erfahre mehr im SysEleven Blog

#EU-US Privacy Shield #Datenschutz #DSGVO

[syseleven]

Management Summary Kubernetes für Entscheider

In der IT-Welt ist derzeit viel von Containern und Automatisierung die Rede. Aus gutem Grund: Mit Containern lassen sich Applikationen leichter entwickeln und sie schonen Ressourcen. Doch müssen sie richtig verwaltet werden, damit ihr Einsatz etwas bringt. Vor allem bei hochverteilten Systemen ist diese Container-Orchestrierung schwierig. Die Technologie "Kubernetes" gibt hierauf aktuell die besten Antworten. Gerade in Verbindung mit der freien Software Docker ist Kubernetes das derzeitig ideale Werkzeug, um Software für verteilte Systeme in einem produktiven Szenario zu betreiben.

Allerdings ist Kubernetes nicht einfach zu handhaben, weswegen SysEleven einen Dienst entwickelt hat, das dem Kunden die komplizierten Komponenten von Kubernetes abnimmt: MetaKube. Für Entscheider sind unseres Erachtens folgende Vorteile von Kubernetes besonders wichtig: Erfahre mehr im SysEleven Blog

#Kubernetes #MetaKube #cloudnative #cncf

[syseleven]

Guide für den Start mit Managed Kubernetes — die ersten Schritte

Photo by Maximilian Weisbecker (Esq0ovRY-Zs-unsplash)

Mein Kubernetes ist da!

Du hast Dich für ein Managed Kubernetes entschieden? Herzlichen Glückwunsch! Jetzt kann die Zukunft losgehen.

Mit einem Managed Kubernetes ist es am Anfang wie mit einer neuen Cloud-Umgebung: Es ist aufregend, ohne Frage. Die Anbindung und Einrichtung muss trotzdem gut geplant werden. Hier kommt nämlich die Magie zum Einsatz, die sich so viele wünschen.

Im folgenden Artikel listen wir einmal die wichtigsten Arbeitsbereiche für die grundlegende Einrichtung auf, die auf einen Besitzer einer Kubernetes-Umgebung zukommen können.

Das umfasst

Das Netzwerk

Das Storage Management

die Nutzung von Proxies

Wir gehen davon aus, dass Du bereits Deine eigenen Anwendungen als Docker-Images vorliegen hast und über die Integration in einen Kubernetes-Cluster nachdenkst.

Die gesamte Infrastruktur ist automatisch — aber was heißt das genau?

Erfahre mehr im SysEleven Blog

#Metakube #kubernetes #managedkubernetes

[syseleven]

SysEleven GmbH

Für SysEleven heißt Hosting: Verantwortung übernehmen. Verantwortung dafür, dass die Applikationen und Onlineshops unserer Kunden laufen, wirtschaftlich betrieben werden und auch bei unerwarteten Lastspitzen funktionieren. Seit 2015 betreibt SysEleven erfolgreich eine native Cloud und stellt diese seinen Kunden im Rahmen einer Public Cloud zur Verfügung. Es handelt sich um eine Open-Source-Lösung, die Basis bildet OpenStack. Weitere Informationen unter www.syseleven.de

#hosting #cloud #openstack #it #infrastructure as a service #kubernetes #managedhosting #berlin #kreuzberg #ecommerce #public cloud #docker #application #opensource