Im Rahmen unserer /mid-Week hatten wir die Gelegenheit, uns mit einem beliebigen Thema tiefer auseinanderzusetzen. Unsere Wahl fiel auf das Advanced Cluster Management (ACM), ein Tool von Red Hat u.a. für die Verwaltung und Erstellung von Kubernetes sowie OpenShift Cluster. Dieser Artikel geht näher darauf ein, was wir dabei herausgefunden haben.
Cluster Management
Wie bereits erwähnt, können mit ACM Kubernetes und OpenShift Cluster verwaltet werden. Aber was genau ist möglich?
Bereits existierende Cluster können in ACM importiert werden. Die sich daraus ergebenden Verwaltungsmöglichkeiten sind allerdings sehr begrenzt, was die Infrastrukturebene betrifft. Selbst dann, wenn es sich beim verwalteten Cluster um OpenShift handelt. Die deutlich beste Integration wird erreicht, wenn ein Cluster aus ACM heraus auf unterstützter Infrastruktur installiert wird. So können Cluster nicht nur aktualisiert werden, sondern auch relevante Informationen wie u.a. kubeconfig oder kubeadmin-Passwort ausgelesen werden.
Bis zu einem gewissen Grad kann ACM aber dennoch überlistet werden, importierte Cluster besser zu integrieren. Wird auf dem Hub Cluster für einen importierten OpenShift Cluster eine ClusterDeployment-Ressource und die darin referenzierten Secrets erstellt, wird insbesondere die Anzeige von Cluster-Informationen erreicht. Diese bleiben ansonsten den aus ACM heraus erstellten vorenthalten.
Weitere Anpassung wie bspw. das Hinzufügen der API URL oder das Verwalten der aktivierten Addons sind hingegen mit weniger Aufwand verbunden und gut dokumentiert. Unter diese Kategorie fällt auch das Erstellen bzw. Aktualisieren der sog. ClusterImageSet-Ressourcen. Beim Erstellen eines neuen Clusters bilden diese die Quelle für die möglichen, zu installierenden Versionen.
Updates von OpenShift 4-Clusters können wenig überraschend auch von ACM aus ausgelöst werden. Neu gibt es zudem die Möglichkeit, den OpenShift Update Operator auf Disconnected Clusters einzubinden. Dies hat den Vorteil, dass verfügbare Updates auf der Web Console angezeigt werden, wie man sich dies von direkt mit dem Internet verbundenen Clusters gewohnt ist.
Der Zweck eines Cluster-Imports ist und bleibt aber hauptsächlich die durch ACM zur Verfügung gestellten zusätzlichen Funktionen, die genutzt werden können.
Cluster Observability
So bietet ACM bspw. die Möglichkeit, mittels MultiClusterObservability– Custom Resource die “Observability” über die verwalteten Cluster zu aktivieren. Unter der Haube werden dazu Prometheus-Metriken mit Hilfe von Thanos aggregiert und in einem Grafana Dashboard visualisiert.
Die Anleitung in der Red Hat Dokumentation zeigt die nötigen Schritte auf, um die Cluster Observability einzuschalten.
Die bereitgestellten Dashboards geben insbesondere Auskunft über folgende Metriken:
- Control Plane Health
- Compute-Ressourcen und deren Optimierungspotential
Policies
Die Policies stellen vermutlich den umfangreichsten Teil von ACM dar. Dieser Eindruck wird alleine aufgrund der Möglichkeiten verdeutlicht, die mit Policies überprüft werden können:
- Gültigkeit von Zertifikaten
- Maximale Anzahl von IAM ClusterRoleBindings
- Image Vulnerabilities (auf Grundlage von
ImageManifestVulnRessourcen) - LimitRanges
- Existierende Namespaces & Pods
- PodSecurityPolicies (keine privileged Pods, Port Ranges, etc.)
- Definierte Roles & RoleBindings
- Status von SecurityContextConstraints (SCC)
- etcd-Verschlüsselung
Dabei können die verschiedenen Überprüfungen beliebig kombiniert werden.
Werden definierte Policies verletzt, kann entweder darüber informiert oder aber gleich auf dem Cluster umgesetzt werden. Das Umsetzen funktioniert je nach Cluster- und Policy-Typ nicht in jedem Fall.
Der Status einer Policy kann entweder über das Web Interface von ACM oder aus der Policy-Ressource auf dem Hub-Cluster ausgelesen werden.
Applications
ACM erlaubt es, Applikationen über mehrere Cluster hinweg zu deployen. Applikationen sind hier nicht nur im Sinne von klassischen Deployments zu verstehen, sondern vielmehr auch als eine Menge an Kubernetes-Ressourcen, welche auf den Ziel-Clustern erstellt und verwaltet werden können. D.h. eine Applikation kann auch Rollen, Secrets und mehr beinhalten.
Das Deployment einer Applikation findet auf dem Hub-Cluster statt, welcher sich anschliessend um das Rollout auf den Ziel-Clustern kümmert.
Die zu deployenden Kubernetes-Ressourcen können aus diversen Quellen, sogenannten Channels, bezogen werden. Als Quelle unterstützt wird:
- Git Repository
- Helm Repository
- Object Store
- Namespace (scheint allerdings nur für Secrets zu funktionieren)
Welche Applikation wo laufen soll, kann über Labels gesteuert werden. Jeder Cluster hat Labels, welche in sogenannten PlacementRules definiert werden. Darüber können auch die Anzahl der Replicas kontrolliert oder beispielsweise “production” vs. “disaster recovery” Szenarien abgebildet werden. Auch blue/green Deployments wären durch diese Labels abbildbar.
Eine weitere wichtige Custom Resource ist die Subscription: Diese verknüpft unter anderem das “Was” (Channel) mit dem “Wo” (PlacementRule). Zudem erlaubt die Subscription diverse weitere Konfigurationen und Overrides zu definieren, wie bspw. Helm-Chart Values.
Eine Application, welche von ACM verwaltet wird, besteht letztendlich aus einer oder mehreren Subscriptions, welche via Labels selektiert wird.
Als Tech-Preview gibt es auch eine Ansible Integration. Diese wurde von uns nicht genauer getestet. Diese soll es jedoch erlauben, vor bzw. nach Subscription deployments (nur Typ Git), via Ansible Tower bestimmte Playbooks zu triggern.
Fazit
Die Autoren dieses Artikels sind sich alle einig: ACM hat noch seine Kanten und Ecken, hat aber sehr grosses Potential, sich als unverzichtliches Management- und Compliance-Tool für Unternehmen mit mehreren Kubernetes und OpenShift Clusters zu mausern. Dies zeigt auch die geplante Roadmap von Red Hat.
Referenzen
Weiterführende Informationen können u.a. unter den folgenden Links gefunden werden:
- Blogposts über ACM
- Ein Applikations- und ein Policy-Beispiel zum ausprobieren
- Produktdokumentation
- Upstream Dokumentation