Das OpenShift 4 Release steht vor der Tür. Zeit die neuen Features zu beleuchten. In diesem Artikel gibt es einen Überblick/Ausblick der neuen Features. In weiteren Artikeln behandeln wir dann die jeweiligen Features etwas genauer.
CoreOS
Das wichtigste zuerst: Wie vielleicht alle interessierten mitbekommen haben hat RedHat die Firma CoreOS übernommen. CoreOS hat einige sehr wichtige Produkte mit ins Boot gebracht, die konsequent von RedHat in OpenShift integriert werden. Im speziellen sind das CoreOS als Container Betriebssystem, Tectonic (die Kubernetes Plattform von CoreOS) und Quay als Container Registry. Alle Drei Produkte werden in OpenShift 4.0 integriert und lösen teilweise OpenShift eigene Konstrukte ab, wie z.B. die Registry. Das Operator Framework war schon in OpenShift 3.11 am Start (hierzu auch später ein Artikel).
Installer
OpenShift 4.0 kommt mit einem Installer, der die Installation in ausgesuchten Clouds wesentlich vereinfachen soll. In der Version 4.0 unterstützt der Installer nur AWS (und on-prem) und übernimmt auch die Infrastruktur Provisionierung eines Best Practice OpenShift Clusters. Ab 4.2 werden auch GKE und Azure unterstützt. Ab 4.1 kann man auch OpenShift auf selbstprovisionierten Infrastrukturen installieren (VmWare, AWS und BareMetal). OpenStack Unterstützung kommt ab 4.3.
Der Installer ist ein CLI Tool und das Aufsetzen eines Clusters ist so einfach wie:
$ openshift-install create install-config
$ openshift-install create manifests
$ openshift-install create ignition-configs
$ openshift-install create clusterCluster API Objekte
Neue Cluster API Objekte, um deklarativ das Cluster zu managen:
- MachineDeployment
- MachineSet
- Machine
Over-the-air updates
Dies ist ein etwas komplizierteres Thema. In Kurzversion:
Auf jeder Maschine läuft ein neues, reduziertes Betriebssystem, Red Hat Enterprise Linux (RHEL) CoreOS, inspiriert von dem Zukauf von CoreOS. RHEL CoreOS ist die unveränderliche Container-Host-Version von Red Hat Enterprise Linux und verfügt über einen RHEL-Kernel mit standardmäßig aktiviertem SELinux. Dazu gehören das Kubelet, der Kubernetes-Nodeagent, und die CRI-O-Container-Laufzeit, die für Kubernetes optimiert ist. Jede Control Plane Machine in einem OpenShift 4-Cluster muss RHEL CoreOS ausführen. Es enthält ein wichtiges Initial-Boot-Bereitstellungstool namens CoreOS Ignition, das es dem Cluster ermöglicht, die Maschinen zu konfigurieren. Betriebssystem-Updates werden als Atomic OSTree Repo geliefert, das in ein Container-Image eingebettet ist, welches wiederum über einen Operator über den gesamten Cluster verteilt wird. Tatsächliche Änderungen des Betriebssystems werden vor Ort auf jeder Maschine als atomare Operation mit rpm-ostree durchgeführt. Zusammen ermöglichen diese Technologien OpenShift, das Betriebssystem wie jede andere Anwendung im Cluster durch In-Place-Upgrades zu verwalten, die gesamte Plattform auf dem neuesten Stand zu halten und die Betriebsteams zu entlasten.
Operator Framework
Ein sehr mächtiges Konzept, ebenfalls von dem CoreOS Team initiiert und auch für Kubernetes verfügbar. Es geht darum, das Applikationspezifische Wissen, welches notwendig für das Deployment, Betrieb und Upgrade einer Applikation ist zu bündeln und in Software zu giessen. Damit ist es möglich eine komplexe App ganz einfach im Cluster zu deployen und am laufen zu halten. Vorreiter sind z.B. ein etcd- und ein Prometheus-Operator (auch in OpenShift 3.11 und Kubernetes). Damit kann man beispielsweise ein Prometheus Stack mit Altermanager und Grafana deployen welches sämtliche Konfiguration mitbringt, selbstheilend ist, sich selbst updated und backuped. In OpenShift 4.0 ist der OperatorHub integriert, wo man ganz einfach von Drittanbietern Software installieren kann, die auch einen Operator zu verfügung stellen. Es ist möglich mit Hilfe des Operator Framework SDK eigene Operator zu schreiben.
Developer Catalog
Dieser aggregiert alle Services der Operator, Service Catalog, Broker und S2I an einer zentralen Stelle von dem aus Entwickler einfach eine vorkonfigurierte App installieren können.
Service Mesh
Ab 4.0 ist Istio als GA verfügbar. Istio auf OpenShift behandeln wir in einem späteren Artikel im Detail.
Container Native Virtualization
Mit Hilfe von CRI-O und kubevirt ist es möglich, dass OpenShift (und natürlich auch Kubernetes) Viruelle Maschinen welche als Disk Images vorliegen zu launchen und den Lebenszyklus aus OpenShift zu administrieren.
Metering and Chargeback
Installiert per Operator sammelt es Daten über die Nutzung von Ressourcen und generiert Reports. Diese können benutzt werden, um Kunden des Clusters separat Nutzung in Rechnung zu stellen. Eng verwandt ist dieses Projekt: https://github.com/project-koku
Cluster Monitoring
Über den Prometheus Operator haben wir bereits weiter oben gesprochen. Ab 4.0 ist dieser in dem OperatorHub integriert und kann von dort installiert werden.
Quay Registry
Ab 4.0 wird das hinzugekaufte CoreOS Produkt Quay als Container registry eingesetzt. Quay bringt sein eigenes Security Scanning Tool namens Clair mit.
