Von sechs geplanten Drift-Regeln gegen einen AKS-Cluster haben am Ende nur zwei getragen, und auch die erst nach einem Umbau. Drei scheiterten an der Plattform, eine blieb aus Risikogründen ungetestet. Der Abstand zwischen dem, was im Handbuch machbar aussieht, und dem, was in einem echten Cluster mit echtem Lifecycle tatsächlich feuert, ist der eigentliche Erkenntnisgewinn eines Praxistests mit Drasi.
Drasi ist eine Plattform für Continuous Queries. Statt Metriken zu pollen oder Admission-Webhooks zu beauftragen, hält Drasi einen materialisierten Graphen des Cluster-Zustands aktuell und bewertet stehende Cypher-Abfragen bei jeder relevanten Änderung neu. Reaktionen hängen an Zustandsübergängen, nicht an Ticks einer Uhr. Diese Übergangslogik macht das Werkzeug für Drift interessant, also für Abweichungen, die erst nach der Admission entstehen und über Zeit an Aussagekraft gewinnen oder verlieren.
Warum bestehende Tools die Lücke nicht schließen
In einem GitOps-Cluster laufen typischerweise drei Klassen von Wächtern parallel. Gatekeeper und Kyverno blockieren unerwünschte Konfiguration zum Admission-Zeitpunkt. Flux und Argo CD melden, wenn der Live-Cluster vom Git-Stand abweicht. Prometheus alarmiert auf Metriken mit einer for:-Bedingung. Keiner davon ist falsch, alle drei ergänzen sich. Ihnen fehlt die Fähigkeit, eine Frage zu beantworten, die mehrere Ressourcentypen relational zueinander in Beziehung setzt.
Solche relationalen Fragen sehen im Kubernetes-Alltag vertraut aus: Läuft dieses Deployment nach fünf Minuten immer noch unter repliziert? Gehört zu diesem Pod ein Image, das nicht aus der zugelassenen Registry stammt? Gibt es in diesem Namespace überhaupt eine NetworkPolicy? Solche Schnitte zwischen Deployment, ReplicaSet, Pod und Namespace lassen sich mit reinen Admission-Regeln oder mit Metriken nur umständlich abbilden. Genau hier setzt Drasi an, mit stehenden Cypher-Queries über den Ressourcen-Graphen, mit temporalen Funktionen wie trueFor und trueLater, und mit einem Resultset, das sich eigenständig aktuell hält.
Wichtig ist die Einordnung gegenüber den etablierten Tools. Drasi ersetzt weder Gatekeeper noch Argo noch Prometheus. Es besetzt eine Nische dazwischen: Laufzeitdrift, der erst nach der Admission entsteht und nur sichtbar wird, wenn man Beziehungen zwischen Ressourcen ausdrücken kann.
Installation und die Frage der Watchliste
Der Einstieg ist unkompliziert. Drasi wird entweder im selben Cluster ausgerollt oder eine externe Instanz wird über ein kubeconfig-Secret an den Zielcluster angebunden. Für die RBAC gilt das übliche Prinzip minimaler Rechte: Die Quell-Credential benötigt ausschließlich list und watch auf den Ressourcentypen, die deine Regeln tatsächlich lesen. Ein Servicekonto für ein Lese-Dashboard ist das passende Vorbild, nicht mehr.
Was sich beim ersten Test als harte Grenze herausstellt, ist die feste Watchliste der Kubernetes-Source. Drasi beobachtet unabhängig von RBAC und unabhängig von deinen Queries genau zwölf Ressourcentypen: Pod, Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, Service, ServiceAccount, Node, Ingress, PersistentVolume und PersistentVolumeClaim. Namespace, NetworkPolicy, PodDisruptionBudget und Secret fehlen auf dieser Liste. Kein RBAC-Grant ändert daran etwas. Wenn deine Regel einen dieser Typen benötigt, lässt sie sich auf der Kubernetes-Source heute nicht ausführen.
Sechs Regeln geplant, zwei haben den ersten Lauf überlebt
Der Praxistest startete mit sechs Regeln, die gegen die Dokumentation formuliert wurden. Jede einzelne wurde anschließend gegen einen Live-Cluster mit absichtlich herbeigeführten Verstößen geprüft. Das Ergebnis war ehrlicher als die Dokumentation vermuten lässt.
Unter-replizierte Deployments funktionierten, mussten aber umgeschrieben werden. Der Grund war handfest: status.readyReplicas ist während eines Rollouts null, und die ursprüngliche Query warf dann auf jedem Mid-Rollout-Deployment einen Fehler. Erst coalesce(status.readyReplicas, 0) macht die Regel alltagstauglich.
Images aus nicht zugelassenen Registries funktionierten, mussten aber ebenfalls umgeschrieben werden. Die gewohnte Cypher-Funktion STARTS WITH parst im gepinnten Parser-Subset nicht. Die tragfähige Form ist left(c.image, N) <> 'prefix'. Was zunächst wie eine Marotte wirkt, ist eine echte Einschränkung der unterstützten Sprachoberfläche.
Namespaces ohne NetworkPolicy ließen sich nicht realisieren. Zwei Probleme stapeln sich hier: Erstens versteht der Parser keine EXISTS { MATCH ... }-Subqueries, zweitens werden Namespace und NetworkPolicy schlicht nicht materialisiert. Die Regel scheitert an der Plattform, nicht an der Query-Logik.
Zertifikatsablauf über TLS-Secrets scheiterte am gleichen Watchlisten-Problem. Secrets gehören nicht zu den zwölf beobachteten Typen. Die Idee hinter der Regel war didaktisch trotzdem wertvoll, denn trueLater ist das Werkzeug der Wahl, wenn ein Alarm zu einem festen Zeitpunkt in der Zukunft feuern soll, ohne Cron-Job.
PodDisruptionBudget-Erschöpfung scheiterte ebenfalls an der Watchliste. PDB ist nicht enthalten. Wer auf PDB-Erschöpfung überwachen will, muss heute einen anderen Mechanismus wählen.
Sustained Node Pressure war als sechste Regel geplant und syntaktisch sauber, aber die Live-Erprobung blieb aus. Der Grund war Risiko: Das Test-Node war ein Shared Control-Plane-Knoten, und ein absichtlich herbeigeführter Memory-Druck hätte die gesamte Drasi-Umgebung mitreißen können. Die Mechanik ist bewiesen, der Übergang in einem echten Störfall nicht.
Drei Ersatzregeln, die ihren Platz im Rulebook verdient haben
Was die nicht realisierbaren Regeln nicht abdecken konnten, übernahmen drei Ersatzregeln. Zwei davon sind gegen echte Verstöße gelaufen, eine nur syntaktisch.
Die Regel für unter-replizierte Deployments ist das Aushängeschild für trueFor. Ein flackernder Zustand während eines normalen Rollouts feuert nicht. Erst eine echte, fünf Minuten anhaltende Verknappung schlägt durch. Wer das in der Praxis schnell erleben will, kann das Fenster im Test verkürzen und einen nodeSelector setzen, der niemals matcht, sodass das Deployment dauerhaft unerfüllt bleibt. Das Ergebnis kam nach Ablauf des Debounce-Fensters sauber als Transition.
Die Image-Registry-Regel nutzt left() als Workaround für das fehlende STARTS WITH. Was zunächst wie eine mechanische Notlösung wirkt, deckt beim ersten realen Lauf zwei Eckfälle auf. Erstens: Dapr-Sidecars melden sich als docker.io/daprio/daprd:1.14.5. Eine rein auf Präfixen basierende Allowlist muss docker.io/daprio/ explizit aufnehmen, sonst flaggt jeder Drasi-Pod mit Sidecar. Zweitens: Calico-Komponenten referenzieren Images als reiner sha256:-Digest ohne Registry-Präfix. Eine präfixbasierte Regel ist an dieser Stelle blind. Das ist kein Randbefund, sondern eine echte Lücke in der Sichtbarkeit, die man benennen sollte, statt sie als Fußnote zu verstecken.
Die Crashlooping-Container-Regel wirkt auf den ersten Blick trivial, benötigt aber eine unwind-Middleware, um die containerStatuses aus jedem Pod in eigene Container-Knoten zu heben. Wer den Middleware-Block versehentlich unter spec: statt unter sources: setzt, bekommt einen lautlosen Apply-Fehler ohne hilfreiche Diagnose. Korrekt eingebunden meldet die Regel sauber jeden Pod, der in CrashLoopBackOff wartet.
Die Replicaless-Deployments-Regel richtet sich gegen Deployments ohne ReplicaSet. Der erste Reflex war wieder eine EXISTS { MATCH }-Subquery, mit dem bekannten Parser-Problem. Die tragfähige Variante ist OPTIONAL MATCH mit count(). In einem gesunden Cluster bleibt das Resultset erwartungsgemäß leer.
Was eine gesunde Regelmenge leistet und was sie nicht leistet
Eine gut justierte Regelmenge ist fast immer langweilig, und genau das ist das Ziel. Auf einem konformen Cluster sitzen alle Regeln leer, ohne Zeilen, ohne Rauschen, und bleiben es auch. Ein Eintrag erscheint nur in dem Moment, in dem ein echter Verstoß seine Schwelle überschreitet, und verschwindet wieder, sobald das zugrundeliegende Problem behoben ist. Nicht nach einem Poll-Intervall, sondern beim nächsten relevanten Übergang im Graphen.
Wenn eine Regel gegen einen gesunden Cluster dauerhaft feuert, liegt das fast immer an der Regel selbst. Eine fehlende coalesce-Behandlung oder ein zu kurzes Debounce-Fenster, das normale Rollouts nicht ausspart, sind die häufigsten Ursachen. Wenn eine Regel hingegen kommentarlos leer bleibt, egal was im Cluster kaputt geht, dann lohnt sich der Blick auf die Watchliste, bevor man dem vermeintlich grünen Zustand vertraut.
Parser-Surface, hart erlernt
Was in der Dokumentation knapp gehalten ist, zeigt sich im laufenden Betrieb deutlich konkreter. Die unterstützten Vergleichsoperatoren sind =, <>, !=, <, <=, >, >=, IN und IS, dazu arithmetische Operatoren. Nicht unterstützt sind STARTS WITH, CONTAINS, ENDS WITH, Regex mit =~ und EXISTS { MATCH }-Subqueries. Unterstützt sind left(), coalesce(), OPTIONAL MATCH mit Aggregation sowie das unwind-Middleware. Der Middleware-Block sitzt unter sources: im Manifest, nicht unter spec:.
Ein nützlicher Nebeneffekt für alle, die das selbst nachvollziehen wollen: Beim Listen der Pod-Images auf dem Test-Cluster tauchen die tatsächlichen Plattform-Komponenten auf, etwa query-container-query-host, query-container-view-svc, query-container-publish-api, source-query-api, source-change-dispatcher, source-change-router. Wer Registry-Probes gegen nackte Namen wie query-host oder view-svc laufen lässt, wird mit 404ern abgespeist, weil die Komponenten in Containern mit eigenem Namensschema leben.
Was das konkret bedeutet
Drasi ist eine sinnvolle Ergänzung im Werkzeugkasten eines GitOps-Clusters, kein Ersatz für die etablierten Wächter. Es füllt eine Lücke, die weder Admission Policy noch Git-Diff noch Metrik-Alerting schließen können, nämlich die relationale, zeitliche Frage über Ressourcen hinweg, nachdem sie admitted wurden. Wer Drasi produktiv einsetzen will, sollte drei Dinge verinnerlicht haben: die feste Watchliste und ihre Grenzen, die Parser-Surface und ihre Eigenheiten, die Tatsache, dass eine gesunde Regelmenge fast nie etwas meldet und gerade dadurch ihren Wert beweist.
Wer im Cluster mit Kubernetes-Secrets, NetworkPolicies oder PodDisruptionBudgets arbeiten will, muss heute auf andere Mechanismen ausweichen oder auf eine Erweiterung der Source warten. Für die zwölf beobachteten Typen jedoch, allen voran Deployments, Pods, Container und Nodes, liefert Drasi eine Form von Sichtbarkeit, die mit Bordmitteln nicht erreichbar ist, ohne Cron, ohne Ticks, mit echtem Übergangsverhalten.
Quelle: luke.geek.nz
