CI/CD vs CI + GitOps: Why Kubernetes Demands a Different Deployment Model

It’s one of the most common missteps we see when teams adopt Kubernetes: they bring their existing CI/CD architecture with them. The same Jenkins pipelines, the same kubectl apply scripts, the same deployment triggers, just pointed at a Kubernetes API instead of a VM or staging server.

And on the surface, it works. CI builds the container, CD pushes it into the cluster. Job done, right?

Not quite.

What’s often missed is that Kubernetes wasn’t designed for push-based deployments. It was designed to work with a declarative state model, where the system itself constantly reconciles toward a desired state. When you treat Kubernetes like a traditional deployment target instead of a self-managing platform, you forfeit many of its most powerful capabilities: continuous reconciliation, drift correction, easy rollback, and Git as the single source of truth.

This is where GitOps enters the picture, not as a buzzword, but as an architecture pattern that aligns with how Kubernetes was meant to be operated.

The problem is, people still call it all “CI/CD", and that’s where the confusion begins.

Let’s clear that up, not with theory, but with technical facts.

CI/CD: Push-Based Delivery, External Control

In the traditional CI/CD world, deployment is an action. Once your code is built and tested, a CD tool takes over and executes a sequence of steps to push that release into the target environment.

These steps might include:

• Applying Kubernetes manifests via kubectl

• Running Helm commands

• Invoking deployment scripts

• Performing validation or health checks post-deploy

The pipeline contains all the deployment logic and acts as the executor. The cluster is passive; it receives the instructions, applies the changes, and returns control.

While this model can be adapted for Kubernetes, it imposes several constraints:

• It requires the CD tool to have direct access to the Kubernetes API.

• It relies on the pipeline to track and apply state, which can lead to drift.

• It lacks native rollback unless explicitly implemented.

• It treats deployments as a point-in-time event, not an ongoing state.

This model works fine in VM-based environments and even for some simple Kubernetes workloads. However, it's not aligned with how Kubernetes is designed to manage applications.

CI + GitOps: Declarative Delivery and Continuous Reconciliation

GitOps takes a different approach.

Rather than pushing changes into the cluster, the CI pipeline’s role ends after building and publishing the artifact. Any change to deployment configuration (like a new image tag) is committed to Git. From there, a GitOps controller running inside or next to the cluster (e.g., natively inside Portainer, or externally with ArgoCD/Flux) continuously monitors the Git repo and reconciles the cluster's live state to match.

It works like this:

1. CI builds the image and pushes it to a registry.

2. CI optionally updates a manifest (e.g. a Deployment.yaml file) with the new image tag and commits it to Git.

3. The GitOps controller detects the change via webhook or polling.

4. It pulls the latest state from Git and applies it to the cluster declaratively.

5. The controller continues to watch for drift and reapply state if needed.

This model embraces Kubernetes’ design principles:

• Declarative configuration stored in Git

• Continuous reconciliation of actual vs. desired state

• No need for CI/CD tools to have cluster credentials

• Rollbacks via Git revert or tag switch

Critically, deployment is not a one-off action, it’s an ongoing process managed by a control loop.

CI/CD vs CI + GitOps: A Technical Comparison

Don’t Confuse the Terms: Precision Matters

GitOps is not a flavor of CI/CD. It is not “CD via Git.” It’s a distinct model that moves the control plane from external tools into the cluster’s trust boundary. It aligns directly with Kubernetes' control loop principles.

Yet many still describe their CI + GitOps pipelines as “CI/CD,” lumping them under the same category as imperative deployment pipelines. This leads to architectural misunderstandings, poor access control patterns, and misaligned expectations between Dev and Platform teams.

More dangerously, some legacy CD vendors now advertise GitOps-like features, but still operate in a push model, executing pipelines externally with Git merely as a trigger. These are not GitOps workflows. They may improve your deployment process, but they do not offer the benefits of declarative, continuously reconciled state.

Naming It Right

If you build containers and deploy them into Kubernetes via Git-managed manifests and a reconciliation engine like Portainer GitOps, Argo CD or Flux, you’re using CI + GitOps.

Not CI/CD.

This distinction isn’t pedantic, it’s operational. It affects how you secure your clusters, structure your teams, debug production, and audit changes. Precision in naming reflects precision in architecture.

So when you're building a Kubernetes delivery pipeline, be clear about what you’re doing, and call it what it is.

CI/CD still has its place. But CI + GitOps is how Kubernetes was meant to be operated.