ArgoCD 🐙

Overview

The Argo CD add-on in Komodor connects your Argo CD server(s) and surfaces application status, sync/health right alongside your Kubernetes data—all in one place. 
While the Argo CD UI is great for GitOps workflows, investigating issues through it can be hard and it often lacks critical Kubernetes context across clusters and namespaces. 
Komodor bridges that gap so teams can move smoothly from deploy → operate → troubleshoot, reach root cause analysis faster, and run one-click Sync or Rollback actions directly from Komodor.

Prerequisites 

  • Argo CD controller installed on at least one cluster that Komodor tracks.
  • Komodor Agent ≥ 0.2.158 on clusters with Argo CD apps.
  • Permissions in Komodor:
    • To configure the integration: manage:integrations
    • To run Argo CD actions: manage:argocd

Integration Set Up

Integration for actions

Enabling Argo CD actions like Sync and Rollback (N-1) from Komodor requires API access to your Argo CD server.

  1. In Settings → Integrations → Argo CD, click Add Argo Server.
    argo cd integration card.pngactions add argo server integrations.png
  2. Fill in:
    1. Cluster Name – The management cluster where this Argo CD server runs.
    2. Argo CD server URL – The URL as seen by the Komodor agent from the cluster. In most setups this is the Kubernetes Service that exposes the Argo CD API/server. Example: https://argocd-server.argocd.svc.cluster.local
    3. Bearer token - 
      Create an Argo CD token and paste it here.
      CLI (example):

      argocd login <ARGOCD_SERVER> --username admin --password <PASSWORD> --insecure # if needed
      argocd account generate-token --account admin

      Copy the token output and paste it into Komodor.
       

      argo server connection example integrations.png
  3. Click Test connection to verify.
  4. Click Save.
  5. Ensure users who should run actions have the manage:argocd permission.
  6. All actions are audited and will appear in the audit log.
    mich.png

Known issues & fix

If you encounter TLS errors when triggering actions (e.g., certificate unknown / x509: certificate signed by unknown authority), you can allow the Komodor agent to skip TLS verification for outbound HTTP requests to your Argo CD server.

argo integration error .png

Helm value (agent chart):

  • Key: capabilities.tasks.httpRequests.skipTlsVerify

  • Type: bool

  • Default: false

  • Effect: sets the HTTP_REQUESTS_SKIP_TLS_VERIFY environment variable

How to enable (only if required):

# values.yaml (Komodor agent)
capabilities:
  tasks:
    httpRequests:
      skipTlsVerify: true

Or via CLI:

helm upgrade --install komodor-agent <repo/agent-chart> \
  --namespace komodor --create-namespace \
  --set capabilities.tasks.httpRequests.skipTlsVerify=true

⚠️ Security note: Skipping TLS verification reduces connection security and should be used only as a temporary workaround (e.g., while fixing certificates or adding the proper CA). Prefer installing a valid certificate or configuring trusted CAs whenever possible.

 

Applications Mapping

Komodor automatically detects your Argo CD apps; to get the full end-to-end experience, you only need to configure a few mapping fields (destination cluster info) in the Argo CD integration.

Argo CD often runs the controller in one “management” cluster while deploying resources to other destination clusters. Komodor needs to know which destination cluster each app belongs to.

  1. Go to Organization Settings → Integrations → Argo CD and click Configure.
    argo cd integration card.png
    apps mapping 1 atgo.png
  2. Recommended: Annotation-based Mapping (skip most manual work)
    Add this annotation to each Application to auto-populate the mapping:

    app.komodor.com/cluster-name: <komodor-cluster-name>

    Komodor will read this annotatation and fill Komodor Cluster Name automatically.

  3. If you are choosing to go manually, You’ll see a mapping table with four columns:
    1. Management Cluster (Argo server runs here) – The cluster hosting the Argo CD controller. (read-only)
    2. Destination Cluster Name (from Application YAML) – Logical name from the Argo CD Application spec. (read-only; may be empty)
    3. Destination Cluster URL (from Application YAML) – Server URL from the Application spec. (read-only; may be empty)
    4. Komodor Cluster Name – The Komodor cluster that actually runs the app’s resources. This is the important mapping and the only editable field.apps mapping argo cd.png

      Note: Columns 2 (Destination Cluster Name) and 3 (Destination Cluster URL) are mutually exclusive—an Application usually specifies one or the other.

      Fill Komodor Cluster Name (column 4) for each row so Komodor can resolve the app’s destination cluster.

      By default, rows that already have a Komodor cluster mapping are hidden. Check “Show mappings with existing Komodor cluster names” to reveal those mapped entries.

      checkbox cluster mapping argo.png


      Unmapped apps will show Cluster: N/A.

      cluster NA.png
       

Argo CD Actions In Komodor

Where you’ll see them:

  • Argo CD Apps page → per-row Actions menu
  • App drawerSync / Rollback buttons

    argo actions.png

Available actions:

  • App Sync (full app only)

    aync argo.png
  • Rollback (N-1)
    rollback argo.png

Argo CD Apps

Global Apps page

Go to left nav → Add-ons → Argo CD

argoCD left nav.png

What you’ll see:

  • Summary widgets: Total apps, Out of Sync, Degraded, Healthy.
  • Argo CD apps table:
    • App name
    • Cluster (destination cluster; may be N/A until mapped)
    • ApplicationSet (if applicable)
    • Argo Health Status
    • Argo Sync Status
    • Last Sync Time
    • Actions (Sync, Rollback - if enabled)
  • Filters: Cluster, Application Set, Health Status, Sync Status
    argo cd apps table.png
  • Status latency: Sync and Health may be delayed by up to ~5 minutes. A live update mode is in progress.

App drawer

Overview

  • Metadata: App name, Cluster (destination), Namespace, Git repository, Application Set.
  • Current status: Sync Status, Health Status, Last Sync (timestamp), Auto-Sync (On/Off).
  • Actions: Sync, Rollback (if enabled).
  • Ask Klaudia - ask klaudia any question about this Argo app

Resources

  • Table of all resources in the app: Kind, Name, Namespace, Argo Health, Sync Status, Reliability risks.
  • Click a resource to open its resource drawer. For unsupported kinds you’ll get proper message
  • Argo actions are app-level only (no per-resource Argo actions).

    app drawer resources.png

Klaudia RCA

  • Automatic RCA when an app is OutOfSync or Degraded—including related unhealthy resources and likely causes.
  • Presented in a dedicated RCA tab within the app drawer.
    Klaudia rca app drawer.png

YAML Tab
Get the Argo application YAML

yaml tab app drawer.png

Service View 

When a service belongs to an Argo CD application, the Service View shows an Argo CD section with:

  • A shortcut to open the related Argo CD app in Komodor

! Note (requirement): To display Argo CD context here, the service must include either the label argocd.argoproj.io/instance or the annotation argocd.argoproj.io/tracking-id.

Klaudia AI Support

Klaudia understands Argo CD context end-to-end, including both individual Applications and the ApplicationSets that generate them:

  • Full RCA on Argo CD apps and ApplicationSets
    • Automatic RCA when an app is OutOfSync or Degraded - including related unhealthy resources and likely causes.
    • When the affected Application is managed by an ApplicationSet, Klaudia surfaces the parent ApplicationSet as context, helping identify whether the issue is isolated to a single generated Application or is a template-level problem that may impact the entire set.
    • Presented in a dedicated RCA tab within the app drawer.
      Klaudia rca app drawer.png
       
  • “Ask Klaudia” on every app
    ask klaudia cTA argo cd.png
    • A free-chat entry point scoped to the app or ApplicationSet - ask things like:
      • "Which resources are out of sync?"
      • "When was the last successful sync and which commit?"
      • "Is auto-sync enabled?"
      • "Which other Applications are generated by this ApplicationSet, and are any of them also affected?"
      • "Is this issue isolated to this Application or is it a pattern across the ApplicationSet?"
    • Klaudia answers using app context, recent state, and where relevant - the broader ApplicationSet configuration and its generated siblings.
      ask klaudia argo cd.png
       
  • Availability investigations with Argo context

    During incident workflows, Klaudia recognizes when a service is part of an Argo CD Application and whether that Application is managed by an ApplicationSet. Klaudia uses the full Argo context - including the ApplicationSet template, generator configuration, and sibling Applications - to determine blast radius, suggest appropriately scoped actions (e.g., Sync or Rollback on the specific Application vs. a template fix on the ApplicationSet), and avoid remediation that could inadvertently affect other generated Applications.


 

 

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.