Is Kubernetes CI or CD?

Is Kubernetes CI or CD?

Look, I get why you're asking "is kubernetes ci or cd?" — you've heard the terms thrown around, seen job postings mashing them together, and watched conference talks where "Kubernetes enables CI/CD" gets tossed out like it explains everything.

It doesn't.

Let me kill this confusion fast: Kubernetes is neither CI nor CD. It's an orchestrator. It runs containers. That's the short answer.

The real answer — the one that'll actually help you build better systems — is more interesting. Kubernetes sits between your CI/CD pipeline and your production infrastructure. It's the platform your CI/CD deploys onto. Think of it as the factory floor, not the assembly line or the shipping dock.

I've spent the last 6 years building data infrastructure and production AI systems at SIVARO. We've run Kubernetes clusters that process 200K events per second. We've also watched teams bolt Kubernetes onto pipelines that didn't need it, turning a 10-minute deploy into a 3-hour debugging session.

So let's unpack this. What exactly is Kubernetes? What does CI and CD actually mean? And why are people moving away from Kubernetes when it looks like the obvious answer?

What Exactly Is Kubernetes Used For?

Short version: Kubernetes automates deployment, scaling, and management of containerized applications.

Google's official docs describe it as "a portable, extensible, open source platform for managing containerized workloads and services." That's technically correct but useless for someone trying to decide if they need it.

Here's what it actually does:

• Scheduling — decides which server runs which container
• Scaling — spins up copies when traffic spikes, kills them when it doesn't
• Self-healing — restarts failed containers, replaces unhealthy nodes
• Service discovery — lets containers find each other without hardcoded IPs
• Rollouts and rollbacks — manages version changes with controlled traffic shifts

But here's the thing. Most people think Kubernetes is necessary for production. They're wrong.

Red Hat's explainer makes it sound like the natural evolution of containers — Docker gives you isolation, Kubernetes gives you orchestration. Simple, right?

Except it's not simple. It's a distributed system. Distributed systems are hard. Kubernetes abstracts some complexity while introducing its own.

I've seen teams bring Kubernetes into a 3-service architecture and spend 6 months fighting network policies. They asked "what does kubernetes actually do?" and got sold on features they'd never use.

CI vs CD: The Actual Definitions

Before we can answer "is kubernetes ci or cd?", we need to agree on what those words mean.

CI (Continuous Integration) — developers merge code changes frequently. Each merge triggers automated builds and tests. The goal: catch integration errors early.

CD (Continuous Delivery) — every change that passes CI is automatically deployed to a staging or production environment. The goal: releases become boring, low-risk events.

Some teams practice Continuous Deployment — every change that passes tests goes straight to production. No human gate.

Where does Kubernetes fit?

It doesn't. Not directly.

CI runs on build servers — Jenkins, GitHub Actions, GitLab CI, CircleCI. These compile code, run tests, build container images, push to registries.

CD runs on deployment pipelines — ArgoCD, Flux, Spinnaker, or custom scripts. These take artifacts (like container images) and deploy them to environments.

Kubernetes is the destination. It's where the deployed applications run.

But — and this is where the confusion starts — Kubernetes can act as part of your CD pipeline. Tools like ArgoCD and Flux run inside Kubernetes, watching your Git repo and reconciling the cluster state. So Kubernetes becomes both the deployment target and the deployment engine.

That dual role is why people ask "is kubernetes ci or cd?" — because if your CD tool runs on Kubernetes, the line blurs.

Kubernetes in the CI/CD Pipeline: Where It Actually Sits

Here's a concrete example. A typical pipeline:

Developer pushes code → CI builds image → Image pushed to registry → CD deploys to Kubernetes

Kubernetes enters at step 4. But tools like ArgoCD run on Kubernetes, watching for new images in the registry and applying them automatically.

So Kubernetes is both:

• The target (where your app runs)
• The platform (where your CD agent runs)

This creates a chicken-and-egg problem: you need Kubernetes running to deploy to Kubernetes. It's bootstrappable — you can deploy ArgoCD via a single YAML file — but it's extra complexity.

Here's a minimal ArgoCD application definition:

yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/your-org/your-repo.git'
    path: k8s
    targetRevision: main
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

That YAML tells ArgoCD: "watch this Git repo. When it changes, update the cluster to match."

Notice what's missing? No CI. ArgoCD doesn't build your code or run your tests. It deploys artifacts that already exist.

A complete pipeline looks more like this:

yaml
# GitHub Actions workflow for CI
name: Build and Push
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: docker build -t my-app:${{ github.sha }} .
      - run: docker push registry.example.com/my-app:${{ github.sha }}
      # Update the deployment tag
      - run: |
          sed -i "s|image:.*|image: registry.example.com/my-app:${{ github.sha }}|" k8s/deployment.yaml
          git config user.name "CI Bot"
          git commit -am "Update image tag"
          git push

When that CI job pushes a commit updating the image tag, ArgoCD detects the change and applies it to the cluster. Kubernetes never touched the build phase. It only ran the deployment.

So no: Kubernetes is not CI. It's tangentially CD — it can host your CD tool, but that's a design choice, not a requirement.

Why People Think Kubernetes Is CD (and Why They're Half Right)

The confusion comes from GitOps.

GitOps treats Git as the single source of truth for infrastructure and application configuration. Your cluster state should match what's in Git. If they diverge, the CD tool reconciles them.

This pattern is powerful. I've used it at SIVARO to manage 12 environments across 3 cloud providers. When a developer changes a YAML file in Git, the change propagates automatically. No SSH, no kubectl, no manual approvals.

But GitOps blurs the line between "deployment automation" and "the thing that runs deployments." When people say "Kubernetes is CD," they usually mean "the GitOps tool running on Kubernetes is CD."

They're not wrong — the CD logic executes on Kubernetes. But Kubernetes itself doesn't enforce the pipeline. It's just the runtime.

Here's a Flux CD controller that watches for new container images:

yaml
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageUpdateAutomation
metadata:
  name: flux-image-updater
  namespace: flux-system
spec:
  interval: 1m
  sourceRef:
    kind: GitRepository
    name: flux-system
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        name: Flux
        email: flux@example.com
      messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
  update:
    strategy: Setters
    path: ./clusters/production

This runs on Kubernetes. It polls a container registry every minute. When it finds a new image matching a pattern, it updates the Git repo with the new tag. ArgoCD or Flux then applies that change.

You're looking at CD logic executing on Kubernetes. It's fine to say "Kubernetes enables CD." But it's not accurate to say "Kubernetes is CD."

When Kubernetes Makes CI/CD Worse

Here's the part most articles won't tell you.

Kubernetes can make your CI/CD pipeline slower and more fragile.

Build times increase. If your CI runner is a pod on Kubernetes, spinning it up takes seconds. A bare-metal runner starts in milliseconds. For a 2-minute build, those seconds matter. For 200 builds a day, they add up.

Debugging is harder. A failed build in a Kubernetes pod means digging through pod logs, node logs, and possibly event logs. A failed build on a VM means reading one log file.

State management gets complex. CI needs caches — Maven repos, npm packages, Docker layers. Kubernetes doesn't handle persistent state well. You end up with PVCs, init containers to warm caches, and complex cleanup logic.

I watched a team at a mid-size fintech company spend 3 months migrating from Jenkins VMs to Kubernetes-native CI. Their build times went from 4 minutes to 11 minutes. They switched back.

One company's story of leaving Kubernetes entirely cited operational complexity as the primary driver. They said: "We realized that we spent more time managing Kubernetes than the problems it solved."

The Hacker News thread on "I Didn't Need Kubernetes" is full of similar stories. One commenter said: "We had 3 microservices and a database. Kubernetes added 2 months to our timeline and zero value."

So when someone asks "is kubernetes ci or cd?", the real question is often "should I use Kubernetes in my pipeline?"

The answer depends on scale. Under 10 services? Probably not. Under 50? Maybe. Over 100? Almost certainly.

Why Are People Moving Away from Kubernetes?

This trend is real. It's not just noise from contrarian blog posts.

This video breaks down the use cases clearly: if you're running 5 containers on 3 VMs, Kubernetes is overkill. You don't need self-healing when you can restart services manually in 30 seconds.

The "Why People Hate Kubernetes" article makes a valid point: Kubernetes solves problems you might not have. It was designed for Google-scale — thousands of services, millions of requests per second. If you're running a CRUD app with 1000 users, you're paying for complexity you don't use.

Teams are moving to:

• Managed container services (AWS ECS, Google Cloud Run) — Kubernetes-like benefits without cluster management
• Platform-as-a-Service (Heroku, Railway) — less control, way less operational burden
• Nomad (HashiCorp) — simpler orchestrator for teams that don't need Kubernetes' full feature set
• Just plain VMs — for small teams, this is often the right call

One team I consulted for — 15 engineers, 12 microservices — moved from self-managed Kubernetes to AWS ECS Fargate. Their AWS bill dropped 40%%. Their deploy time dropped from 15 minutes to 3. They lost zero functionality.

Another team — 200 engineers, 400+ microservices — doubled down on Kubernetes. They needed the network policies, the service mesh, the multi-cluster federation. It was the right call for them.

The key insight: Kubernetes isn't a goal. It's a tool. And tools have trade-offs.

How to Decide: A Practical Framework

Here's how I evaluate whether Kubernetes belongs in a CI/CD pipeline:

1. Count your services
< 10: Don't use Kubernetes. Use Docker Compose or a managed container service.
10-50: Consider Kubernetes if you already have ops expertise.
50+: Kubernetes starts making sense.

2. Count your deployments per day
< 10: CI/CD is simple. Bare-metal runners are fine.
10-100: Consider Kubernetes for CD tooling (ArgoCD/Flux).
100+: Kubernetes-native runners might pay off — but test first.

3. Measure your team's Kubernetes experience
No one knows Kubernetes: Don't use it. Period. The first 6 months will be painful.
1-2 people know it: Use managed Kubernetes (EKS, GKE, AKS). Have a clear escalation path.
3+ people know it: Self-managed is viable. You understand the risk.

4. Ask: "What does kubernetes actually do for us?"
If the answer is "run containers," you don't need it.
If the answer is "auto-scale based on queue depth and route traffic across 3 regions," you probably do.

A Reddit thread asked this exact question. The top answer: "Kubernetes lets teams move fast without stepping on each other." That's the right answer for large organizations. For small teams, it's irrelevant.

FAQ: Is Kubernetes CI or CD?

Q: Is Kubernetes CI or CD?
A: Neither. Kubernetes is a container orchestrator. CI builds code. CD deploys it. Kubernetes is where deployed code runs.

Q: Can Kubernetes be part of a CI/CD pipeline?
A: Yes. Most modern pipelines use Kubernetes as the deployment target. Some run CD agents (ArgoCD, Flux) on Kubernetes. But Kubernetes doesn't do CI or CD — it hosts tools that do.

Q: What exactly is Kubernetes used for in CI/CD?
A: Three things: (1) Running CI/CD runner pods, (2) Hosting the CD agent (ArgoCD/Flux), (3) Running the deployed application. Each is optional.

Q: What does kubernetes actually do that Docker doesn't?
A: Docker runs containers. Kubernetes orchestrates containers across multiple machines — handles networking, scaling, self-healing, service discovery, and rolling updates.

Q: Why are people moving away from Kubernetes?
A: Operational complexity. For small-to-medium deployments, the overhead of managing Kubernetes exceeds the benefits. Managed alternatives (Cloud Run, ECS) or simpler orchestrators (Nomad) often work better.

Q: Is GitOps the same as CD?
A: GitOps is a CD pattern. It uses Git as the source of truth and reconciles cluster state automatically. ArgoCD and Flux implement GitOps on Kubernetes.

Q: Should I run CI inside Kubernetes?
A: Generally no. CI needs fast startup times, persistent caches, and simple debugging — all things Kubernetes makes harder. Run CI on dedicated runners. Use Kubernetes only for CD and production workloads.

Q: Can Kubernetes replace my entire CI/CD toolchain?
A: No. You still need a build system (Jenkins, GitHub Actions), a registry (Docker Hub, ECR), and a CD agent. Kubernetes runs applications — it doesn't replace the pipeline.

The Bottom Line

Kubernetes is not CI. Kubernetes is not CD. Kubernetes is the infrastructure that supports your CD pipeline.

The question "is kubernetes ci or cd?" reveals a deeper confusion about what each layer of the stack actually does. CI is about code → artifact. CD is about artifact → running service. Kubernetes is about running services reliably.

When someone asks "what exactly is kubernetes used for?" the honest answer is: it manages containerized workloads at scale. If you don't have scale, you don't need it.

When someone asks "what does kubernetes actually do?" the answer is: it keeps your containers running despite failures, traffic spikes, and human error. That's valuable — if you have those problems.

When someone asks "why are people moving away from kubernetes?" the answer is: because they didn't have those problems. They adopted Kubernetes because it was trendy, not because it solved a real need. And the operational cost showed up quickly.

I've built systems processing 200K events per second on Kubernetes. I've also run a 5-service monolith on a single VM for 2 years with zero downtime. Both were the right choice for their context.

The question isn't "is kubernetes ci or cd?" The question is "do I need what Kubernetes provides?" Answer that honestly, and the technology decision becomes obvious.

---

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.