CI/CD for Kubernetes

Your pipeline can deploy.
Teach it to verify.

Keep GitHub Actions, GitLab CI, or whatever you run today. Add a CLI that validates cluster changes on a pull request, waits for a real rollout on merge, and explains a failure well enough to act on.

Start Free Copy the pipelines

Kubeconfigs in CI

1 line

CLI install

Agents to copy

The gap between "pipeline green" and "it works"

Most Kubernetes pipelines are a build step, a credential nobody is comfortable with, and a deploy step that cannot tell you whether it worked.

A kubeconfig in your CI secrets

Cluster-admin credentials sitting in a runner that also executes code from pull requests. Everyone knows it is wrong; nobody has a smaller credential to swap it for.

Deploys that exit 0 before anything rolled out

The pipeline goes green when the API accepted the change, not when the pods are healthy. The first person to find out it failed is a user.

A red X with no root cause

The build failed, the Slack message says so, and finding out why still means someone opening a terminal and starting from scratch.

The cluster is your YAML linter

Chart references, addon dependencies, and plaintext secrets are only discovered at apply time, in the environment you were trying to protect.

Rebuilding the pipeline per provider

Every new cloud or on-prem cluster means new registry auth, new deploy keys, new controller setup. Half a day each time, and none of it is transferable.

Reviews that cannot see the cluster

A reviewer reads a diff of YAML with no idea that the addon being reparented is mid-rollout or the node group being scaled is already at 85% memory.

What you add to the pipeline you have

No orchestration layer, no framework, no vector database. A trigger, a few deterministic CLI calls, and a write to somewhere humans actually look.

One CLI, installed in a line

The Ankra CLI drops onto any runner from a single curl. Validate, apply, draft, query metrics, list operations - all non-interactive, all with machine-readable output.

Validate before the cluster sees it

ankra cluster validate -f runs structural and dependency checks locally, then server-side checks you cannot do offline: do the referenced charts exist, do parent references resolve, is anything a plaintext secret. --strict-secrets turns that last one into a failed job.

Deploys that block until they are real

ankra cluster apply is asynchronous by default. Pass --wait with a --timeout and the job holds until the rollout finishes and health verifies, so your exit code means something.

An AI step that already knows the cluster

ankra chat is one-shot and scriptable, and the model has server-side access to logs, events, manifests, stack history, operations, and metrics. Your pipeline never holds a model API key or a kubeconfig.

Agents propose; humans ship

ankra cluster draft -f stages every stack in a file as reviewable drafts instead of deploying them. A pipeline can suggest a fix without ever having a path to mutate the cluster outside Git.

Scoped tokens, not cluster admin

ankra tokens create issues a token for a dedicated machine user with the minimum org role. No kubeconfig, no cloud credential, and forked pull requests never receive it.

.github/workflows/deploy.yml

- name: Deploy
  env:
    ANKRA_API_TOKEN: ${{ secrets.ANKRA_API_TOKEN }}
  run: |
    ankra cluster select production
    ankra cluster apply -f cluster.yaml --wait --timeout 15m

- name: Verify and report
  if: always()
  run: |
    ankra chat health > report.md
    ankra cluster operations list | head -n 20

Four triggers, one CLI

What each job actually does

Every one of these is a plain CI job you can paste into a repo today. Nothing here needs a platform team to operate it.

on: pull_requestReview

Comment on the PR with what will actually change

The job validates the cluster definition against the live platform, then asks one question with the diff in the prompt and the cluster state on the server side. The answer lands as a PR comment: what changes, what restarts, what is risky right now.

--strict-secrets fails the job on a plaintext secret, not a warning

Forked PRs get no secrets, so the agent simply does not run there

on: push (main)Deploy

Apply, wait, verify, report

ankra cluster select production runs non-interactively by name, then apply --wait --timeout 15m holds the job until the rollout settles. Health and metrics are checked afterwards, and the result goes to Slack.

Without --wait the command exits 0 the moment the platform accepts the change

The apply is the same GitOps change your engine was going to reconcile anyway

on: failureDiagnose

Post a root cause instead of a red X

The failure path collects the apply output and the recent operations as raw facts and hands the diagnosis to the AI, which can also see the operation's jobs, pod events, and container logs. The prompt insists on one verdict: retry, or broken change.

The on-call human gets the decision, not a log dump

No log grepping or error-string parsing to maintain

on: scheduleWatch

A watcher that stays quiet when things are fine

Every 30 minutes, independent of CI, a job checks for failed or stuck operations and degraded workloads. It posts to Slack only when something is actually wrong, which is the only way an alert channel keeps its meaning.

Silence is the healthy state - no daily green report to tune out

Runs on a schedule, so it catches drift no deploy would have surfaced

The net effect

Infra pull requests get a reviewer who has read the live cluster. Merges block until the rollout is genuinely healthy. Failures arrive with a verdict. And the runner holds one scoped token instead of the keys to production.

Guardrails worth keeping

An agent in your pipeline is still automation with credentials. These four rules are what keep it boring.

Read-only by default

Validation, questions, and reports mutate nothing. The only write is the apply on merge - the deploy your GitOps flow was going to run anyway, gated by the PR review.

Model output is untrusted text

It goes into a PR comment or a Slack message and stops there. Never pipe it into a shell, an apply, or anything that executes: the diff it read came from a PR author.

Credentials are scoped and boring

A machine-user token with the minimum org role, and a Slack webhook that can post to exactly one channel. No kubeconfig and no cloud credential anywhere in the pipeline.

Always pass names in CI

Bare ankra cluster select opens an interactive picker and will hang a job until the timeout kills it. The same applies to every command with an interactive mode.

Before and after

In the pipeline	Typical setup	With Ankra
Credential in the runner	Cluster-admin kubeconfig	Scoped API token
Pipeline goes green when	The API accepted the change	The rollout verified healthy
A failed deploy tells you	Exit code 1	Root cause plus retry-or-broken verdict
Reviewing an infra PR	Read the YAML diff	Diff checked against live cluster state
Adding a second provider	Rebuild the pipeline	Same CLI, same stack, new cluster
Letting an agent fix things	Give it cluster write access	It files drafts a human approves

Copy the working versions

Full workflow files, prompts, and the failure modes we hit first.

Guide

Building Pipeline Agents with the Ankra CLI

Three working agents - PR review, deploy watcher, scheduled watcher - as copyable GitHub Actions and GitLab CI jobs, with the gotchas that break them.

Read it

Product