Run Drone CI Pipelines as Kubernetes Pods (2026)

Drone CI is a powerful automation server that can be configured to run your CI/CD pipelines as native Kubernetes pods. This allows you to leverage the full power of Kubernetes for your build and deployment processes, including scaling, resource management, and isolation.

Here’s how it works:

When a pipeline is triggered, Drone doesn’t execute the steps directly on the Drone server. Instead, it instructs the Kubernetes API to create a new pod for each pipeline step. These pods are scheduled and managed by Kubernetes, just like any other application.

Let’s see this in action. Imagine you have a simple .drone.yml file like this:

kind: pipeline
type: kubernetes
name: my-kubernetes-pipeline

steps:
  - name: build
    image: golang:1.19
    commands:
      - go build
      - go test

  - name: deploy
    image: alpine:latest
    commands:
      - echo "Deploying..."
      - sleep 10

When this pipeline runs, Drone will:

1. Create a pod for the build step: Kubernetes will pull the golang:1.19 image and run the go build and go test commands within that pod.
2. Create a pod for the deploy step: Once the build pod completes successfully, Kubernetes will pull the alpine:latest image and run the echo "Deploying..." and sleep 10 commands in a new pod.

You can observe these pods being created and terminated in your Kubernetes cluster using kubectl:

kubectl get pods --watch

You’ll see pods with names like drone-build-xxxxxx and drone-deploy-yyyyyy appear and disappear as the pipeline progresses.

The Mental Model: Dynamic Pods for Dynamic Workloads

The core problem Drone solves here is decoupling the CI execution environment from the Drone server itself. Instead of the server managing build agents or containers directly, it delegates this responsibility to Kubernetes. This offers several advantages:

• Scalability: Kubernetes can automatically scale the number of pods based on demand, ensuring your pipelines have the resources they need without manual intervention.
• Isolation: Each pipeline step runs in its own isolated pod, preventing conflicts between different builds and ensuring a clean environment for each task.
• Resource Management: You can define resource requests and limits for your pipeline pods (CPU, memory) directly in your Kubernetes configuration, allowing for better control and predictability.
• Flexibility: You can use any container image available in your registry for your pipeline steps, giving you immense flexibility in choosing the tools and environments for your builds.

Key Configuration Levers

When configuring Drone for Kubernetes, you’ll primarily interact with the Drone server’s configuration and your .drone.yml pipeline definitions.

Drone Server Configuration (drone.yml or environment variables):

• DRONE_KUBERNETES_NAMESPACE: Specifies the Kubernetes namespace where pipeline pods will be created.
  • Example: DRONE_KUBERNETES_NAMESPACE=drone-builds
• DRONE_KUBERNETES_IMAGE_PULL_POLICY: Defines how Kubernetes should pull images for pipeline pods (e.g., always, if-not-present, never).
  • Example: DRONE_KUBERNETES_IMAGE_PULL_POLICY=if-not-present
• DRONE_KUBERNETES_NODE_SELECTOR: Allows you to specify node selectors for scheduling pipeline pods.
  • Example: DRONE_KUBERNETES_NODE_SELECTOR='{"disktype":"ssd"}'
• DRONE_KUBERNETES_SERVICE_ACCOUNT: The Kubernetes service account that Drone will use to create pods. This account needs appropriate RBAC permissions.
  • Example: DRONE_KUBERNETES_SERVICE_ACCOUNT=drone-builder

Pipeline Configuration (.drone.yml):

• type: kubernetes: This is the crucial setting in your .drone.yml to tell Drone to use the Kubernetes executor.
• image: The container image to use for a specific pipeline step.
• commands: The shell commands to execute within the container.
• environment: Environment variables to set within the pipeline pod.
• resources: Define Kubernetes resource requests and limits for the pod.

  steps:
    - name: test
      image: node:18
      resources:
        requests:
          cpu: "200m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"
  

The most surprising thing about running Drone on Kubernetes is how seamlessly it integrates, often requiring minimal changes to your existing .drone.yml files if you were previously using Docker. The type: kubernetes switch is the primary indicator, and Kubernetes handles the rest. The complexity shifts from managing Drone’s build agents to managing Kubernetes RBAC and resource allocation for the pipeline pods.

Once you’ve mastered running basic pipelines, you’ll naturally want to explore how to manage persistent storage for your build artifacts or how to integrate with Kubernetes secrets for sensitive information.