OpenShift · ASPICON Newsarchiv

Suse Rancher/RKE vs. Red Hat OpenShift

The hidden DBA — Wed, 04 Aug 2021 06:31:51 +0000

Home → OpenShift

Suse Rancher/RKE vs. Red Hat OpenShift

Verfasst von The hidden DBA
04 August 2021
08:31
Kubernetes, OpenShift, Red Hat, SUSE Rancher

Ausgangslage

Wir vergleichen die zwei größten Kubernetes Distributionen am Markt hinsichtlich der Faktoren Support, Security, Installation, Lizenzierung, Updates/Upgrades, Partnerunterstützung und Einhalten der Standards der CNCF.

Red Hat OpenShift, wir betrachten ausschließlich Version 4.X, kommt als All-in-One Lösung und bietet sowohl die Kubernetes Engine, als auch alle Management Tools (Web Console, CLI, Umfangreiche Developer Tools) im Gesamtpaket.

SUSE Rancher ist hingegen zunächst einmal eine Management Platform für verschiedene Kubernetes Distributionen. D.h. Rancher wird entweder außerhalb oder innerhalb einer bestehenden Kubernetes Cluster Umgebung installiert und kann sich dann an diesen Cluster anknüpfen und diesen verwalten. Weiterhin können mit Rancher auch weitere Kubernetes Cluster installiert werden, wenn der Infrastrukturanbieter unterstützt wird (vSphere, AWS, …).

Damit der Vergleich gelingt, wird eine Red Hat OpenShift Container Platform als UPI (User-provisioned infrastructure) und eine SUSE Rancher Installation auf einem SUSE RKE Cluster (Rancher Kubernetes Engine) verglichen. RKE ist die Kubernetes Engine für den Cluster, den die Rancher Installation verwalten wird.

Laut dem Forrester Wave Report 2020, liegt Red Hat OpenShift sowohl in der Strategie, als auch im aktuellen Angebot vor allen anderen Anbietern, inklusive SUSE Rancher.

Quelle: Forrester WAVE LEADER 2020 Report, https://more.suse.com/fy21-global-web-landing-page-forrester-new-wave-enterprise-container-platform

Installationsaufwand

Die Installation eines produktiven Kubernetes Cluster im eigenen Rechenzentrum ist immer mit einigen Aufwand Verbunden. Wir rechnen für den Vergleich der beiden Lösungen die Vorbereitung und Anbindung der Ressourcen wie Netzwerk, Storage und Authentication nicht mit in den Vergleich ein. Betrachtet wird die Installation eines 6 Knoten Cluster, bei dem 3 Knoten als Master und 3 Knoten als Worker konfiguriert sind.

Red Hat OpenShift

OpenShift bietet, je nach dem auf welche Plattform installiert werden soll, verschiedene Möglichkeiten des Deployments an. Um einen Vergleich zu ermöglichen, wird hier die Bare Metal “UPI” (User Provided Infrastructure) betrachtet.

Für die Installation wird eine Bootstrap Maschine benötigt, auf der eine beliebige Linux Distribution, vorzugsweise aber ein Derivat von Red Hat Enterprise Linux, ausgeführt werden kann.

Die Installation geschieht dann über einen TFTP und DHCP Mechanismus, mit vorbereiteten Ignition Files. Die gesamte Red Hat OpenShift Installation basiert auf Red Hat Enterprise Linux CoreOS (RHCOS) Maschinen, die zentral vom OpenShift System verwaltet werden. Es ist nicht gedacht oder gewünscht, sich direkt auf die Red Hat CoreOS Maschinen zu verbinden, außer für Troubleshooting Aktivitäten. Die Maschinen werden über zentrale MachineConfigs im OpenShift Cluster gesteuert und konfiguriert.

Bei einer UPI Installation müssen folgende Punkte vorbereitet sein:

Virtuelle oder Physische Maschinen erstellt (nicht installiert)
Loadbalancer für API Adressen, etc. konfiguriert
DNS konfiguriert
Netzwerkverbindungen bestehen

Wenn die Vorbereitungen vollständig sind, kann die Installation innerhalb weniger Stunden (2–3) durchgeführt werden.

Suse Rancher

Da Rancher an sich nur eine Verwaltungssoftware für Kubernetes Cluster ist, muss diese auf einer Infrastruktur (Docker, virtuelle Maschine, K3S, Kubernetes Cluster) installiert werden. Für unser Beispiel wird vor der eigentlichen Rancher Installation also ein Kubernetes Cluster mit “RKE” installiert. Da RKE ebenfalls von SUSE bzw. von Rancher stammt, ist dies die bevorzugte Kubernetes Engine für Rancher.

Um RKE installieren zu können, müssen die entsprechenden Knoten als Hardware oder virtuelle Maschinen mit einem unterstützten Linux Betriebssystem installiert sein. Dies kann, wenn Automatisierungstools wie Kickstart Dateien und Ansible genutzt werden, innerhalb 1–2 Stunden erledigt sein. Bei manueller Installation und Konfiguration der Knoten, kann dies 3–6 Stunden in Anspruch nehmen. Unterstützte Betriebssysteme für RKE sind:

SUSE Linux Enterprise Server
openSUSE
Red Hat Enterprise Linux
Oracle Enterprise Linux
CentOS
Ubuntu

Upgrade

Kubernetes ist ein Softwareprodukt mit häufigen Release Zyklen und mit einer Vielzahl an Komponenten die zusammenspielen müssen. Dadurch ist es für Anbieter eine Herausforderung, sowohl eine stabil funktionierende Distribution, als auch aktuelle Software Versionen anzubieten.

Red Hat Openshift

Red Hat veröffentlicht etwa alle 3 Monate eine neue Hauptversion der OpenShift Container Platform (OCP). Aktuell ist 4.8 (Release Datum am 27.07.2021). Die Updates lassen sich bequem über die Web Konsole oder das Commandline Interface “oc” einspielen.

Hier genügt ein

oc adm upgrade --to=4.7.19

um auf die gewünschte Version zu aktualisieren. Soll ein Upgrade auf die nächste Major Version (4.7 → 4.8) geschehen, muss vorher der aktuelle Channel gewechselt werden (von stable‑4.7 auf stable‑4.8).

! Upgradepfad

Nicht jede Version kann zu jeder Version aktualisiert werden. Um die korrekte Zielversion von der aktuell installierten Version zu ermitteln, bietet Red Hat entsprechende Tools an. Die einfachste Möglichkeit ist der Update Graph:

https://ctron.github.io/openshift-update-graph/#stable‑4.6

Ein Upgrade kann, je nachdem wie viele Knoten installiert sind, von mehreren Stunden bis zu einigen Tagen andauern.

Suse Rancher / RKE

Ein Upgrade per Rancher RKE ist recht simpel. In der vorliegenden “cluster.yml” Datei, muss die Kubernetes Version angepasst werden (kubernetes_version: “v1.20.9‑rancher1‑1”).

Danach kann mit

rke up --config cluster.yml

das Update angestoßen werden.

Je nach Knoten Anzahl kann das Update mehrere Stunden in Anspruch nehmen, ist aber in der Regel deutlich schneller fertig im Vergleich zu OpenShift.

Continous Integration / Continous Deployment

Ein Kern Feature der Container basierten Software ist es, dass die Integration in CI/CD und GitOps sehr gut möglich und sinnvoll ist. Dies beschleunigt die Entwicklungs- und Updatezyklen und vermeidet individuelle Fehler durch Standardisierung.

Red Hat Openshift

Aus der Sichtweise eine Software Entwicklers hat Kubernetes an sich einige Vorteile, die in diesem Artikel nicht intensiv dargestellt werden sollen. Im direkten Vergleich der beiden Lösungen, hat Red Hat OpenShift die Nase vorn, wenn es um das Toolset für Entwickler Out-of-the-Box geht. Leider geht Red Hat an der ein oder anderen Stelle (S2I und Red Hat Marketplace mit Operators) einen eigenen Weg, ab von dem in der Community etablierten Mechanismen (Dockerfiles, Helm Charts), welche aber ebenfalls ohne Einschränkungen in OpenShift genutzt werden können.

Gerade im Bereich des sich etablierenden “GitOps” Modells des Deployments, hat Red Hat die OpenSource Lösungen “ArgoCD” und “Tekton” als “OpenShift GitOps” und “OpenShift Pipelines” offiziell in die Distribution ab Version 4.7 aufgenommen. Damit kann aus Entwickler und Administrator Sicht eine schnelle und saubere Deployment Strategie aufgebaut werden.

Suse Rancher / RKE

Rancher bietet mit dem neuen “Continuous Delivery” Tool ebenfalls ein nützliches GitOps Tool Out-of-the-Box. Damit können Ressourcen aus Git Repositories in definierten Namespaces deployed werden. Ebenfalls können im Rancher verwalteten Kubernetes Cluster auch “ArgoCD” und “Tekton” mit wenig Aufwand installiert und verwendet werden.

Support

Ein wichtiger Punkt für den Einsatz in Enterprise Umgebungen ist der verfügbare Support durch Hersteller und Partner. Gerade bei Plattformen, die recht häufig neue Software Releases veröffentlichen, können mögliche Probleme mit kompetenten Partnern und einem guten Hersteller Support schnell gelöst werden.

Red Hat Openshift

Der Herstellersupport von Red Hat genießt einen sehr guten Ruf und glänzt durch einen sehr hohe Expertise für die angebotenen Produkte. Im Problemfall wird schnell geholfen, sodass Unterbrechungen minimiert werden können.

Einen Hauptteil des Support decken allerdings sehr gut qualifizierte Partner, wie die ASPICON GmbH, für die Endkunden ab. Hier kann eine Betreuung ab der Planung bis zum Betrieb hin angeboten werden.

Suse Rancher / RKE

Der Herstellersupport umfasst hier, neben den Kernprodukten Rancher und RKE auch das Kubernetes Kernsystem. Auch SUSE baut die Partnerlandschaft strategisch aus und qualifiziert die Partner für den umfassenden Support der Rancher Umgebungen.

Lizenzierung

Red Hat Openshift

Die OCP Plattform berechnet die Support Kosten pro zugewiesener CPU auf den Worker Knoten. Die CPUs der Master werden dabei nicht betrachtet.

Suse Rancher / RKE

Die Supportgebühr berechnet sich hierbei nach der Nummer der Knoten. Die installierten CPUs oder vCPUs werden dabei nicht betrachtet.

Windows Container

Für eine mögliche Migration hin zu Container basierten Applikationen, sind auch Windows native Container ein wichtiger Baustein. Vor allem, wenn Software auf Basis von älteren .NET Frameworks geschrieben ist, kann diese mit Hilfe von Windows Containern auf einen Kubernetes Cluster migriert werden. Um Windows Container im Kubernetes Cluster betreiben zu können, müssen entsprechende Windows Server als Worker Knoten dem Cluster hinzugefügt werden.

Red Hat Openshift

Ab Version 4.6 Unterstützt die OpenShift Container Platform den Betrieb von Windows Servern als Worker Knoten im Cluster. Bedingung ist hierbei, dass die Installer Provided Infrastructure Methode für die Installation des OCP Clusters gewählt wurde. Die User Provided Infrastructure wird nicht unterstützt.

Somit können Windows Server Knoten beispielsweise in der Amazon AWS, Microsoft Azure oder auch im eigenen Rechenzentrum auf einem VMware vSphere Cluster installiert und betrieben werden.

Suse Rancher / RKE

Auch mit Rancher lassen sich Windows Server als Kubernetes Worker Knoten betreiben. Dafür muss der Cluster bei der Erstellung für Windows Support aktiviert werden. Die Master, bzw. Controlplane Knoten müssen dabei, wie im OCP Cluster, mit einem Linux Betriebssystem betrieben werden. Die Container Engine auf den Windows Server Knoten muss dabei eine Docker Enterprise Edition sein.

Sicherheit

Wenn Anwendungen als Container bereitgestellt werden, erhöht sich zunächst einmal die Komplexität im Gesamtkonstrukt, da hier mehrere Komponenten zusammenspielen müssen. Das kann leicht dazu führen, dass Sicherheitsaspekte außer Augen gelassen werden, oder einfach nicht mehr im Fokus stehen. Die Hersteller bieten verschiedene Möglichkeiten diese Themen zu adressieren.

Red Hat Openshift

Im OCP Cluster gibt es Out-of-the-Box mehrere Features, die die Sicherheit im Cluster erhöhen. Das sind beispielsweise “Security Context Constraints”, die verhindern, dass sich Container per default als “root” oder im erhöhten Rechten starten können. Weiterhin ist RBAC per default aktiviert und steuert den Zugriff per RoleBindings im Cluster. Im OpenShift gibt es weiterhin die Möglichkeit Groups anzulegen, denen User zugewiesen und die wiederum in RoleBindings referenziert werden. Jedes neue Projekt bekommt einen Bereich von User- und GroupIDs zugewiesen, die in den jeweiligen Pods verwendet werden sollten. Auch der Einsatz von NetworkPolicies ist eine Option, die die Sicherheit im Cluster erhöht.

Suse Rancher

Auch bei Suse Rancher wird RBAC automatisch im Cluster aktiviert. Die User können über Identity Provider (wie auch im OpenShift) gesteuert werden, so dass eine Anmeldung über Active Directory möglich ist. Rancher bietet darüber hinaus die Möglichkeit, die User Verwaltung über mehrere Cluster an einem zentralen Punkt zu steuern.

Darüber hinausgehende Einschränkungen für Pods, bspw. im Bezug auf Security Contexte, sind nicht per default aktiviert, können aber im Rahmen der Unterstützung der Kubernetes Engine, nachkonfiguriert werden.

Fazit

Ein eindeutiger Sieger kann im Vergleich nicht ausgemacht werden. Generell sollte im Enterprise Bereich eher auf Red Hat OpenShift gesetzt werden, da die Partner- und Herstellersupportleistung zum aktuellen Zeitpunkt etwas umfangreicher ist. Zudem ist Red Hat OpenShift auf große Umgebungen und Skalierungen ausgelegt.

Wenn ein bestimmter Teil der Applikationen in einem kürzeren Zeitraum in einer bestehenden Infrastruktur bereitgestellt werden soll, ist Suse Rancher wohl die bessere Wahl. Auch ist der Migrationsaufwand im Vergleich zu OpenShift nicht ganz so hoch, da viele Sicherheitsfeatures, die Red Hat bei OpenShift eingeführt hat, nicht vorhanden sind. Daher ist dies näher an den Kubernetes Installationen der Public Cloud Provider, bietet aber nicht die Sicherheit wie ein OpenShift Cluster.

Interessiert? Hier gibt es weitere Posts zum Thema Kubernetes, OpenShift oder Rancher .

Share this article

Der Beitrag Suse Rancher/RKE vs. Red Hat OpenShift erschien zuerst auf ASPICON.

OpenShift Pipelines und OpenShift GitOps generell verfügbar

The hidden DBA — Mon, 31 May 2021 09:30:01 +0000

Home → OpenShift

OpenShift Pipelines und OpenShift GitOps generell verfügbar

Verfasst von The hidden DBA
31 Mai 2021
11:30
Kubernetes, Linux, OpenShift, Red Hat

In unseren heutigen News werfen wir einen Blick auf OpenShift Pipelines und OpenShift GitOps. Dazu gab es kürzlich einen interessanten Blogbeitrag von Red Hat. Die wichtigsten Informationen daraus, haben wir hier für euch zusammengefasst.

Der Bedarf, Anwendungen schneller und mit besserer Qualität bereitzustellen, ist über alle Branchen hinweg weit verbreitet und steigt zunehmend. Damit wächst auch die Nachfrage nach Automatisierungsmöglichkeiten der Anwendungsbereitstellung. OpenShift, die Enterprise-Kubernetes-Plattform für Entwickler, bietet Unternehmen genau diese Möglichkeiten durch DevOps-Praktiken wie Continuous Integration und Continuous Delivery (CI/CD). Seit einiger Zeit werden dazu die Tools “Tekton” für Pipelines und “ArgoCD” für GitOps entwickelt. Mit der aktuellen Version von OpenShift 4.7, sind diese nun als “OpenShift Pipelines” (Tekton) und “OpenShift GitOps” (ArgoCD) als offizielle und von Red Hat unterstützte Produkte verfügbar.

OpenShift Pipelines: Cloud-Native Continuous Integration

Schauen wir uns zuerst das Produkt OpenShift Pipelines näher an. Mit Tekton ist es nun möglich, Pipelines zur Anwendungserstellung direkt als Pods im Kubernetes Cluster zu erstellen. Beispielsweise kann somit eine Java Applikation aus dem Git Repository erstellt, anschließend in einen Container gepackt, als Helm Paket erstellt und zum Schluss getestet werden.

Tekton baut dazu direkt auf Kubernetes Konzepte auf und ermöglicht es den Teams somit, die Pipelines im Kubernetes Cluster unabhängig von zentralen Werkzeugen oder Serverapplikationen wie Jenkins zu betreiben. Damit werden Entwicklern mehr Freiheiten eingeräumt und eventuelle Konflikte bei Pipeline Prozessen vermieden.

OpenShift Pipelines stellt eine Reihe von Templates für vorgefertigte Abschnitte (Tasks) bereit, mit denen der Aufbau einer Pipeline effektiv beschleunigt werden kann. So bietet OpenShift Pipelines vorgefertigte Tasks für Maven, Dotnet, Java, Node.js, Perl, PHP, Python und noch weitere Sprachen, um die Erstellung der Anwendung zu vereinfachen. Obendrein bildet der graphische Pipeline Builder ein nützliches Tool bei der Erstellung und Parametrisierung einer Pipeline für den Entwickler.

Weiterhin gibt es eine Reihe von Client Tools für Tekton. So kann auf der Kommandozeile die Tekton-CLI genutzt werden. Für Visual Studio Code und IntelliJ gibt es jeweils ein Tekton Plugin.
Über den Tekton Hub können weitere vorgefertigte Tasks bezogen werden.

OpenShift Pipelines enthält aktuell:

Pipeline log aggregation im zentralen Log Management OpenShift Logging
Automatische proxy Konfiguration bei TaskRuns
Aktivierung von TLS für EventListeners Pods
ClusterTriggerBindings für BitBucket und GitLab
Jenkins-to-Tekton Migration Guide
Log aggregation im zentralen Log Management OpenShift Logging
Integration der Authentication mit Red Hat SSO und OpenShift
Dynamische Erstellung von Argo CD Applications mit ApplicationSets (Tech Preview)
Sammlung von Argo CD metrics durch Prometheus aus dem OpenShift Monitoring Stack
OutOfSync alerts in OpenShift Monitoring Stack AlertManage

OpenShift GitOps: Continuous Delivery mit GitOps

Git gilt in der Softwareentwicklung schon sehr lange als etablierter Standard für die Versionierung und Aufbewahrung von Sourcecode. Mit GitOps wird dieses Konzept noch weiter gedacht. Die Benefits, die sich hieraus ergeben, schauen wir uns im Folgenden an.

Mit OpenShift GitOps wird jegliche Infrastruktur und Konfiguration als Code in einem oder mehreren Git Repositories abgelegt. Dadurch können die Standardisierung vorangetrieben, Fehlerquellen vermieden und eine Wiederholbarkeit der Installationen gewährleistet werden. Im Kubernetes Bereich geschieht das entweder über YAML Dateien oder Helm Pakete.

OpenShift GitOps ist dabei um die Software “ArgoCD” gebaut. Diese deklarative GitOps Engine erlaubt es GitOps Workflows auch über mehrere OpenShift Cluster oder auch andere Kubernetes Cluster bereitzustellen. Mit ArgoCD können sowohl automatische als auch manuelle Deployments konfiguriert werden. Bei den automatischen Deployments überwacht ArgoCD das angegebene Repository und wendet Änderungen aus dem jeweiligen Branch im Kubernetes Cluster an. Dazu wird immer darauf geachtet, dass die im Git definierten Objekte auch genau so im Kubernetes Cluster erstellt sind. Das hat den Vorteil, dass dadurch unauthorisierte oder unerwünschte manuelle Änderungen der Objekte verhindert werden. ArgoCD selbst kann dabei über ein eigenes RBAC Konzept gesteuert werden.

OpenShift GitOps enthält aktuell:

Log aggregation im zentralen Log Management OpenShift Logging
Integration der Authentication mit Red Hat SSO und OpenShift
Dynamische Erstellung von Argo CD Applications mit ApplicationSets (Tech Preview)
Sammlung von Argo CD Metriken durch Prometheus aus dem OpenShift monitoring stack
OutOfSync alerts in OpenShift monitoring stack AlertManager

Unser Fazit

Auch wenn es im ersten Moment ein wenig komplex wirkt, überzeugen die vorgestellten Neuerungen den Profi mit einer Reihe von Vorteilen.

Mit einem auf Tekton und ArgoCD ausgelegten Entwicklungs- und Deploymentprozess, kann die Geschwindigkeit der Releases nochmals deutlich erhöht werden, wobei gleichzeitig die Fehleranfälligkeit verringert wird. Durch die Speicherung aller notwendigen Konfigurationen in einem Git Repository, fällt hier die Wiederholbarkeit deutlich leichter und auch eine Dokumentation ist zukünftig einfacher erstellt.

Alle, die sich mit Containern und Kubernetes beschäftigen, sollten sich unbedingt beide Tools anschauen.

Hier findest du weitere Posts zu den Themen Red Hat OpenShift oder Kubernetes.

Share this article

Der Beitrag OpenShift Pipelines und OpenShift GitOps generell verfügbar erschien zuerst auf ASPICON.

Neuerungen in Red Hat OpenShift 4.7

The hidden DBA — Wed, 31 Mar 2021 14:35:20 +0000

Home → OpenShift

Neuerungen in Red Hat OpenShift 4.7

Verfasst von The hidden DBA
31 März 2021
16:35
Kubernetes, Linux, OpenShift, Red Hat

Unser aktueller Praxistipp gibt einen Überblick zu interessanten Neuerungen in Red Hat OpenShift 4.7.
Mit OpenShift bietet Red Hat seit einigen Jahren eine Enterprise Kubernetes Distribution an, die sich wachsender Beliebtheit erfreut. OpenShift kann dabei sowohl als Service eines Cloud Providers bezogen, als auch On Premise als “OpenShift Container Platform” installiert werden.

Seit Ende Februar ist die Version Red Hat OpenShift 4.7, welche auf Kubernetes 1.20 (cri‑o 1.20) basiert, nun verfügbar. Nachfolgend gehen wir auf relevante Verbesserungen dieser Version ein.

Windows Container

Schon Ende 2020 wurde der lang ersehnte Support für Windows Container für OpenShift eingeführt und mit der Version 4.7 wird dieser nun noch einmal erweitert. Zusätzlich zu dem bereits bestehenden Support für Windows Container in Microsoft Azure und Amazon AWS, wird nun auch VMware vSphere für On Premise Installationen unterstützt. vSphere wird hierbei mit IPI (Installer Provided Infrastucture) bereitgestellt.
Windows Container können für viele Windows Anwendungen eingesetzt werden, die z.B. auf dem Windows .NET Framework aufsetzen.

Assisted Installer (Technology Preview)

Mit dem Assisted Installer soll die automatisierte Installation in Bare Metal Umgebungen deutlich vereinfacht werden. Moderne Applikationen, die auf künstlicher Intelligenz oder Machine Learning aufbauen, Telekommunikations- oder 5G Applikationen, sowie High Performance Computing (HPC) können von Bare Metal Installationen profitieren. Grund hierfür ist, dass die Virtualisierungsschicht eingespart wird.

Horizontal Pod Autoscaler (General Availability)

Software Entwickler können mit dem Horizontal Pod Autoscaler (HPA), basierend auf dem Arbeitsspeicherverbrauch, automatische Skalierungen der Applikationen konfigurieren.

Scheduling Profiles (Technology Preview)

Scheduling Profiles stellen eine Neuerung dar, mithilfe derer Administratoren das Verhalten des Schedulers anpassen können. Dafür stehen verschieden Kriterien, wie die Ressourcen Nutzung, die Hochverfügbarkeit oder die Performance zur Verfügung.

Descheduler (General Availability)

Der Descheduler erlaubt es Administratoren, Pods aufgrund vordefinierter Richtlinien zu verschieben. So können Pods, basierend auf den aktuellsten Scheduling Profiles neu im Cluster erstellt werden.

OVN-IPSec

Wenn OVN (Open Virtual Network) als Network Plugin benutzt wird, kann damit der gesamte Traffic im Cluster mit IPSec verschlüsselt werden.
Das erhöht die Sicherheit und ist gerade in co-location Umgebungen sinnvoll.

OpenShift GitOps (Technology Preview)

Mit “OpenShift GitOps” gibt es nun einen offiziellen Operator von Red Hat für ArgoCD. Damit ist es möglich, definierte Kubernetes Ressourcen aus einem Git oder Helm Repository im Cluster bereitzustellen. Das ergänzt sich sehr gut in Verbindung mit den Tekton Pipelines, die schon länger als “OpenShift Pipelines” verfügbar sind.

Und mehr …

Über die hier geschilderten Verbesserungen hinaus, gibt es viele weitere Neuerungen, die in den offiziellen Release Notes nachzulesen sind. Diese betreffen u.a. Themen wie die OpenShift Console und Kern Strukturen, wie Storage oder Network.

Zusammengefasst lässt sich sagen, dass Red Hat OpenShift 4.7 einige interessante Verbesserungen sowohl für DBAs als auch Software Entwickler bietet. Von daher lohnt sich auf jeden Fall ein zeitnahes Upgrade auf die Version 4.7

Hier findest du weitere Posts zu den Themen Red Hat OpenShift oder Kubernetes.

Share this article

Der Beitrag Neuerungen in Red Hat OpenShift 4.7 erschien zuerst auf ASPICON.

Fachvortrag Datenbanken auf Kubernetes

Dirk Melzer — Wed, 24 Mar 2021 15:37:14 +0000

Home → OpenShift

Fachvortrag Datenbanken auf Kubernetes

Verfasst von Dirk Melzer
24 März 2021
16:37
Datenbank, Kubernetes, MariaDB, MongoDB, OpenShift, PostgreSQL, SQL Server

Im aktuellen Beitrag dreht sich alles um das Spezialthema “Datenbanken auf Kubernetes”.

Kubernetes erfreut sich seit 2015 stetig wachsender Verbreitung und bietet auch im Bereich der Datenbankinfrastruktur vielseitige Möglichkeiten.

Mit unserem Fachvortrag auf den “Chemnitzer Linux-Tage 2021″ haben wir einen guten Überblick zu diesem sehr spannenden Thema. Mehr als 220 begeisterte Linux- und Open Source Fans folgten dieser insgesamt etwa 1 stündigen Video-Präsentation inklusive Praxis Demo. Bereits während der Präsentation gab es zahlreiche Fachfragen in einem regen Austausch mit dem Vortragenden.

Nun stellen wir allen Interessierten, die an den Chemnitzer Linux Tagen nicht teilnehmen konnten, diesen Fachvortrag als Videomitschnitt zur Verfügung. So bieten wir die Möglichkeit, einen umfangreichen Einblick in das Thema “Datenbanken auf Kubernetes” zu gewinnen.

Für den besseren Überblick haben wir die Präsentation in 2 Teile unterteilt.

Teil 1 – Datenbanken auf Kubernetes: Geeignete Software Systeme auf Kubernetes und deren Anforderungen, die Wartung, Aktualisierung und Sicherung

Inhalt des Teil 1

Wir geben zunächst eine Einführung in die Begriffe Container und Kubernetes. Für Kubernetes, als System zur Orchestrierung und Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container Anwendungen, werden verschiedene Distributionen angeboten. Für den On Premise-Bereich sind die Red Hat OpenShift Container Platform, SUSE Rancher sowie Vmware vSphere 7 mit Kubernetes (Tanzu) zu nennen. Zu den Cloud Lösungen für Kubernetes gehören Azure AKS, Google GKE und Amazon EKS.

Im Anschluss wird auf NoSQL Datenbanken wie beispielsweise Cassandra, CouchDB oder auch mongoDB eingegangen. Für den Bereich relationaler Datenbanken betrachten wir kurz PostgreSQL Cluster und Microsoft SQL Server Big Data Cluster als geeignete Datenbanksysteme für Kubernetes Cluster. Zur Abrundung des kleinen Überblicks schauen wir uns noch auf die NewSQL Datenbanken CockroachDB, Vitess und TiDB.

Sicherlich kann man aufgrund der Kürze der Zeit und auch durch die Fülle der Informationen nicht jede Datenbank betrachten. Aber bereits der kleine Rundgang durch die genannten Datenbanken zeigt das unglaubliche Spektrum, welches mit Kubernetes adressiert werden kann.

Im Anschluss werden noch folgende Fragen zum Thema Kubernetes besprochen:

Wie stellt man am besten persistenten Speicher bereit?
Welche Unterschiede gibt es zwischen Cloud und On Premise Kubernetes Cluster im Betrieb?
Wie werden Backup und Wartungsjobs an Datenbanksystemen angewendet?
Wie gestaltet sich der Update Prozess?
Können die Datenbanksysteme in DevOps Deployment Pipelines integriert werden?

Mit Referenz zu Storagelösungen wird tiefergehend auf den CSI Treiber NetApp Trident eingegangen. Zudem wird erläutert, weshalb bei Cloud Clustern der Kostenfaktor und bei On Premise Lösungen die Zusammensetzung der Hardware Komponenten beachtet werden sollte.

Nach den weiterführenden Informationen zur Sicherung und Wartung der Datenbanksysteme im Kubernetes über das sogenannte CronJob Objekt wird der erste Teil des Fachvortrages mit Tipps zum Deployment und Update von Datenbank Cluster Installationen über Helm Chart, Operator oder das entsprechende Client Tool abgeschlossen.

Teil 2 – Datenbanken auf Kubernetes : Datenbank Deployments auf Kubernetes mit OpenShift

Inhalt des Teil 2

Die Demo zeigt was im Kubernetes Cluster mit Datenbanken heute bereits möglich ist. Beispielhaft wird dazu ein Microsoft SQL Server 2019 Big Data Cluster mit dem Command Line Tool “azdata” installiert. Neben der Information über das spezifische Docker Images des Microsoft SQL Servers, wird der Deployment Prozess auf einem Red Hat OpenShift 4.6 Cluster gezeigt.

Im nächsten Schritt wird eine Verbindung zum SQL Server Big Data Cluster mit dem Azure Data Studio hergestellt, welches sowohl auf Linux und Mac als auch auf Windows verfügbar ist. Im Anschluss daran wird eine Dotnet Core Anwendung über eine Tekton Pipeline im Cluster erstellt. Diese verbindet sich dann zur Datenbankschnittstelle des SQL Server Big Data Clusters.

Der letzte Teil der Demo zeigt, wie ein MariaDB Galera Cluster installiert wird, auf das anschließend eine Nextcloud Installation zugreift.
Hierbei handelt es sich um ein Cluster, der 3 Pods über 3 Worker Knoten mit einem StatefulSet verteilt und damit ein hochverfügbares MySQL Datenbanksystem zur Verfügung stellt. Der Cluster wird über einen Helm Chart installiert und erstellt anschließend einen Service für die Datenbankverbindungen. Im letzten Schritt wird noch die Applikation Nextcloud, die sich mit dem Datenbank Cluster verbinden kann, ebenfalls über ein Helm Chart installiert.

Sofern du die Präsentationsfolien erhalten möchtest, schicke uns bitte eine kurze Email an “linux@aspicon.de”

Hier findest du weitere Posts zu den Themen Red Hat OpenShift oder Kubernetes.

Share this article

Der Beitrag Fachvortrag Datenbanken auf Kubernetes erschien zuerst auf ASPICON.