Kubecost: Cross-Charging-Kosten von Datenverarbeitungspipelines in einer Data-Mesh-Architektur

Einführung

Da Unternehmen zunehmend Cloud-native Technologien wie Kubernetes einsetzen, wird die Verwaltung der Kosten zu einem immer wichtigeren Thema. Wenn sich mehrere Teams denselben Cluster teilen, kann es eine Herausforderung sein, die Kosten genau zu verfolgen und zu verwalten und einen Überblick über die Ausgaben auf Teamebene zu erhalten.

In diesem Blogbeitrag erfahren Sie, wie Kubecost - ein weit verbreitetes Open-Source-Tool zur Kostenüberwachung und -optimierung - dazu beiträgt, die Kostenunterschiede zwischen zwei Beispielteams aufzuzeigen , die jeweils ihre Airflow-DAG mit unterschiedlichen Ausführungszeiten in einem gemeinsamen Kubernetes-Cluster besitzen und betreiben. Wir gehen auf die Details von Kubecost ein, seine Funktionen und wie es Ihnen helfen kann , Kosten zu optimieren, die Ressourcenauslastung zu verbessern und datengestützte Entscheidungen zu treffen.

Szenario

Unser Szenario umfasst zwei Teams, Team_1 und Team_2, die jeweils ihren eigenen Namensraum in einem gemeinsamen Kubernetes-Cluster haben. Beide Teams verwenden eine gemeinsame Airflow-Instanz, eine Open-Source-Workflow-Management-Plattform, um ihre Workflows zu verwalten und Airbyte-Synchronisierungsaufträge auszulösen. Jedes Team hat seinen DAG (Directed Acyclic Graph), der für eine unterschiedliche Zeitspanne in seinem Namespace läuft. Team_1 DAG läuft kumuliert etwas mehr als 7 Stunden pro Tag, während Team_2DAG kumuliert fast 2,5 Stunden täglich läuft.

Luftstrom-DAGs

Wir werden Abkürzungen erstellen, um den Airbyte-Synchronisierungsauftrag in jedem Team zu imitieren (was in der Regel einige Zeit in Anspruch nimmt, abhängig von der Datenmenge). Wie Sie im Codeblock unten sehen können, wird der Kubernetes Airflow Job-Pod in einem Namensraum bereitgestellt, der von jedem Team gehalten wird (team1 bzw. team2 ). Der Pod selbst führt einen Kettenjob aus: Er löst einen einfachen Airbyte-Job aus, um Daten zwischen Sample Data Faker und S3-Bucket zu synchronisieren, und führt dann einen Stress-Befehl mit Parametern als Impostor für die Airflow-Transformationsstufe aus. Der Job wird dann auf der Grundlage von cron alle 20 Minuten für Team_1 und 30 Minuten für Team_2 ausgelöst. Wir werden drei Tage lang Daten sammeln.

from airflow import DAG
from airflow.providers.airbyte.operators.airbyte import AirbyteTriggerSyncOperator
from airflow.operators.empty import EmptyOperator
from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import  KubernetesPodOperator
import pendulum
from kubernetes import client as k8s

executor_config_airbyte1= {
    "pod_override": k8s.V1Pod(
        metadata=k8s.V1ObjectMeta(
            namespace="team1"
        ),
    )
}

with DAG(dag_id="airbyte_airflow_dag_team1",
         default_args={"owner": "airflow"},
         schedule_interval='*/20 * * * *',
         catchup=False,
         start_date=pendulum.today("UTC").add(days=-1)
         ) as dag:

    trigger_airbyte_sync_1 = AirbyteTriggerSyncOperator(
        task_id="airbyte_trigger_sync_1",
        airbyte_conn_id="airbyte_1",
        connection_id="58410801-eee4-451e-8a8e-8a9af08f2e75",
        asynchronous=False,
        executor_config=executor_config_airbyte1,
    )

    transformation_1 = KubernetesPodOperator(
        namespace="team1",
        image="progrium/stress",
        name="airflow-airbyte-transformation-1",
        task_id="transformation_1",
        is_delete_operator_pod=True,
        cmds=["stress"],
        arguments=["--cpu", "3", "--io", "3", "--vm", "2", "--vm-bytes", "1024M", "--timeout", "360s"],
        get_logs=True,
        executor_config=executor_config_airbyte1,
    )

    end_task = EmptyOperator(task_id="end")

    trigger_airbyte_sync_1 >> transformation_1 >> end_task

Team_2 Die DAG ist eine Kopie der oben gezeigten, mit dem Unterschied, dass der Namespace und die Befehlsargumente stress ausgewählt wurden:

arguments=["--cpu", "1", "--io", "2", "--vm", "1", "--vm-bytes", "128M", 
"--timeout", "160s"]

Beide DAG-Dateien werden in das Git-Repository übertragen, so dass Airflow seine Inhalte synchronisieren und die DAGs laden kann. Dadurch werden sie für die Benutzer zugänglich, damit sie die Jobs innerhalb der Airflow-Oberfläche anzeigen, verwalten und auslösen können. Natürlich wurde Helm zur Installation von Airflow verwendet:

helm repo add airflow https://airflow.apache.org

helm install airflow apache-airflow/airflow

--namespace airflow --values=airflow-values.yaml

--create-namespace=true

Die Wertedatei ist mit dieser kleinen Änderung voreingestellt:

gitSync:
    enabled: true
    credentialsSecret: gitlab-credentials-secret
    # git repo clone url
    # ssh example: git@github.com:apache/airflow.git
    # https example: https://github.com/apache/airflow.git
    repo: https://gitlab.com/getindata/devops/dags.git
    branch: main
    rev: HEAD

Legen Sie anschließend die Portweiterleitung von airflow-webserver pod innerhalb von Kubernetes fest, um die Airflow-Benutzeroberfläche zu erreichen, und bestätigen Sie, dass die DAG-Synchronisierung erfolgt ist und Sie in den DAG-Details navigieren können.

Einrichtung von Kubecost und Airbyte

Um die Kosten und die Ressourcennutzung zu verfolgen, haben wir Kubecost eingerichtet, das detaillierte Metriken für die Kostenzuweisung und die Nutzung liefert und uns ermöglicht, die Kosten nach Namespace, Bereitstellung und sogar einzelnen Pods aufzuschlüsseln.

Stellen Sie Kubecost mit Helm auf unserem Kubernetes-Cluster bereit:

helm repo add kubecost https://kubecost.github.io/cost-analyzer/

helm install kubecost -n kubecost kubecost/cost-analyzer

--values=kubecost-values.yaml --create-namespace=true

In der Wertedatei gibt es nichts Ausgefallenes: nur ein deaktiviertes Grafana, da es derzeit nicht benötigt wird.

Airbyte geht einen ähnlichen Weg: eine saubere Installation, aber in zwei verschiedenen Namespaces:

helm repo add airbyte https://airbytehq.github.io/helm-charts

helm install airbyte airbyte/airbyte --version 0.64.81 -n team1

helm install airbyte airbyte/airbyte --version 0.64.81 -n team2

Kubecost Übersicht

Kubecost ist eine umfassende Plattform zur Kostenüberwachung und -optimierung, die speziell für Kubernetes-Umgebungen entwickelt wurde. Sie bietet eine breite Palette von Funktionen, mit denen Benutzer die Kosten nach Namespace, Bereitstellung, Service und mehr aufschlüsseln können, und zwar für alle wichtigen Cloud-Anbieter oder Kubernetes-Umgebungen vor Ort. Es kann auch dabei helfen, die Nutzung von Kubernetes-Ressourcen zu optimieren, Kosten zu senken und die Gesamteffizienz zu verbessern.

Die wichtigsten Funktionen von Kubecost:

Weiter zum Kostenvergleich

Jetzt, wo Kubecost in Betrieb ist, können wir detaillierte Kosteninformationen für jedes Team sehen. Das Übersichts-Dashboard bietet eine klare Aufschlüsselung der Kosten nach Namespace, so dass wir leicht feststellen können, welches Team die meisten Ausgaben verursacht. Wir können auch einen kurzen Blick auf die Seite Cluster-Details werfen:

Wenn Sie zu Monitor > Allocations navigieren und die Daten, an denen wir interessiert sind, auf der Grundlage des Namensraums und des Drei-Tage-Zeitraums filtern, können wir schnell die Gesamtkosten von Team_1und Team_2mit einer Aufschlüsselung für jede Bereitstellung sehen:




Um - in diesem Fall - eine Gruppe von Ressourcen unter einem recht verdächtigen Namen Uncontrolled workloads zu untersuchen, brauchen wir nur auf den Namen zu klicken, um zu sehen, dass sich hinter diesem Namen nur airflow-transformations-Pods verbergen - dies ist der Schritt, bei dem wir den Befehl stress ausführen. Diese Art von Pods sind unter einem unkontrollierten Namen gruppiert, weil kubescaller sie nicht unterstützt.



Und nun zurück zur Analyse.

Wie erwartet führt Team_1 bei längeren und häufiger laufenden DAGs zu höheren Gesamtkosten. Da für diese Übung nur eine Einzelknotenkonfiguration verwendet wurde, habe ich beschlossen, die gemeinsam genutzten und die Idle-Kosten, die im Abschnitt __idle__ in der Kostenaufschlüsselung gekapselt und dargestellt werden, zu überspringen, um die Unterschiede hervorzuheben.

Jetzt können wir einen genauen Kostenunterschied zwischen zwei Teams ermitteln, wenn beide Namensräume unter einem einzigen Filter kombiniert und nach Namensraum aggregiert werden, wie unten dargestellt.

Durch die Analyse der Kostentreiber können wir erkennen, dass die Airflow-Transformationsaufträge den größten Anteil an den Kosten haben Team_1 und Team_2. Diese Informationen können zur Optimierung der Arbeitsabläufe, zur Kostensenkung und zur Verbesserung der Gesamteffizienz genutzt werden.

Wir können auch ein Budget für jedes Team / jeden Namensraum einrichten, indem wir zu Govern > Budgets navigieren.

So behalten Sie den Überblick über den aktuellen Verbrauch im Vergleich zu dem vereinbarten Wert. Benachrichtigungen können auch so konfiguriert werden, dass Benutzer über das Erreichen eines bestimmten Schwellenwerts informiert werden und eine Nachricht per E-Mail an Slack oder MS Teams gesendet wird.

Fazit

Kubecost bietet wertvolle Einblicke in die Kostenunterschiede zwischen Teams in einem gemeinsamen Kubernetes-Cluster. Durch die Verfolgung der Kosten und der Ressourcennutzung können Teams Bereiche mit Optimierungsbedarf identifizieren und datengestützte Entscheidungen zur Kostensenkung treffen. In diesem Szenario haben wir gesehen, wie Kubecost uns geholfen hat, Kostenunterschiede zwischen zwei Teams aufzudecken, die Airflow DAGs mit unterschiedlichen Ausführungszeiten betreiben und Budgets für jeden Team-Namensraum einrichten. Ob Sie nun Entwickler, DevOps-Ingenieur oder Finanzanalyst sind, Kubecost ist ein unverzichtbares Tool für jeden, der die Kosten in einer Kubernetes-Umgebung verwalten möchte.

Durch den Einsatz von Kubecost können Teams:

Möchten Sie mit Artikeln, Tipps und Anleitungen voller praktischer Inhalte auf dem Laufenden bleiben? Melden Sie sich für unseren Newsletter an, in dem wir einmal im Quartal nur die besten Inhalte veröffentlichen, wie diesen Artikel, den Sie gerade gelesen haben.