Manage Kubernetes Resources from Argo Workflows (2026)

Argo Workflows doesn’t just run in Kubernetes, it is a Kubernetes controller, and you can use that to your advantage to manage other Kubernetes resources.

Let’s see it in action. Imagine you have a Kubernetes deployment that needs to be scaled up or down as part of a workflow. Here’s a snippet of an Argo Workflow that does just that:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: manage-k8s-resources-
spec:
  entrypoint: scale-deployment
  templates:
  - name: scale-deployment
    resource:
      action: patch
      manifest: |
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: my-nginx-deployment
        spec:
          replicas: 5

When this workflow runs, the resource template tells Argo Workflows to interact directly with the Kubernetes API. The action: patch means we’re going to modify an existing resource, and the manifest provides the desired state. In this case, we’re patching the my-nginx-deployment to have 5 replicas. Argo Workflows, acting as a Kubernetes controller, will translate this into a PATCH request to the Kubernetes API server.

This capability extends far beyond just scaling deployments. You can create, delete, update, and even get information about any Kubernetes resource. Think about setting up complex environments, performing rolling updates with custom logic, or cleaning up temporary resources after a job completes.

Here’s how it works internally: Argo Workflows uses the Kubernetes client libraries to communicate with the API server. When you define a resource template, Argo translates your declarative manifest and action into specific API calls. For patch, it sends a PATCH request with the provided spec. For create, it sends a POST request. For delete, it sends a DELETE request. The success and failure conditions within the resource template allow you to control the flow of your workflow based on the outcome of these API interactions.

The key levers you control are the action (create, delete, patch, get, apply), the manifest which is a standard Kubernetes YAML definition, and the success and failure conditions. These conditions are powerful, allowing you to check fields within the status of the resource you’re interacting with. For example, you could wait for a deployment’s availableReplicas to reach a certain number before proceeding.

One common pattern people miss is using the get action to retrieve information about a resource and then passing that information to subsequent steps. For instance, you might get a service to obtain its cluster IP and then use that IP in a subsequent container step to perform a health check. This is done by specifying an output parameter in the resource template and referencing fields from the retrieved resource’s status or metadata.

The next logical step after managing individual resources is orchestrating complex, multi-resource deployments and cleanup procedures.