GlossaryManifest

Manifest

A Kubernetes manifest is a YAML or JSON configuration file that declares the desired state of one or more resources, such as Deployments, Services, or Jobs.

Table of Contents

Table of Contents

How a manifest works

Engineers write manifests declaratively. Kubernetes then works to make the cluster match what the file describes.

Manifests are a cornerstone of Infrastructure-as-Code and GitOps. They keep infrastructure consistent, reproducible, and easy to review.

  1. Write a manifest that declares the kind, metadata, and spec of a resource.
  2. Store the file in Git and review changes through pull requests.
  3. Apply it with kubectl apply or a GitOps tool such as Argo CD.
  4. Kubernetes compares desired state with actual state and reconciles.
  5. Later edits to the manifest roll out as updates.

Key parts of a manifest

  • apiVersion: the API group and version of the resource
  • kind: the resource type, such as Deployment or Job
  • metadata: name, namespace, labels, and annotations
  • spec: the desired state, such as replicas or container images

Manifests vs. Helm charts

Both describe Kubernetes resources. Helm adds templating and packaging on top of plain manifests.

Plain manifest Helm chart
Format Static YAML or JSON Templated YAML with values
Reuse across environments Copy and edit Override values per environment
Packaging Individual files Versioned chart package
Best for Simple or one-off resources Apps deployed many times

Why manifests matter in Kubernetes

Manifests are the foundation for managing clusters at scale. Without them, changes are hard to reproduce, audit, or automate.

  • Declarative configuration: define what should exist, not how to create it
  • Version control: history, rollback, and collaboration through Git
  • Reproducibility: identical environments deploy anywhere
  • Automation: fits naturally into CI/CD and GitOps workflows
  • Fewer manual errors: reviewable files replace one-off commands

Consider a SaaS team that rebuilds a staging cluster after an outage. With manifests in Git, one sync restores every service. Without them, engineers piece together commands from memory.

Common challenges with manifests

  • Configuration drift: manual changes make clusters differ from declared files
  • Duplication: near-identical manifests for each environment
  • Complexity: large or nested configurations are hard to maintain
  • Validation errors: small YAML mistakes block deployments
  • Version mismatches: resource definitions change between Kubernetes versions

Templating tools like Helm or Kustomize reduce duplication and keep manifests manageable.

How manifests relate to Testkube

Testkube relies on Kubernetes manifests for installation, configuration, and test execution. This keeps Testkube aligned with Kubernetes-native practices.

  • Installation: deploy Testkube with prebuilt YAML files or Helm charts
  • Declarative tests: test workflows and settings are Kubernetes custom resources
  • GitOps: test definitions, triggers, and configuration live in Git
  • CI/CD: pipelines apply manifests automatically during builds or deploys
  • Repeatability: identical Testkube setups across clusters

Real-world examples

  • Git-reviewed changes: a DevOps engineer applies all cluster changes through pull requests
  • Consistent tests: a QA team defines Testkube test workflows as YAML manifests
  • Automated sync: a platform team uses Argo CD to sync Testkube manifests from Git
  • Quick setup: a developer runs kubectl apply on a manifest to deploy Testkube in a new cluster

Frequently Asked Questions (FAQs)

What is the difference between a manifest and a Helm chart?

A manifest is a static resource definition. A Helm chart templates and packages manifests so one chart serves many environments.

Can manifests include multiple resources?

Yes. One YAML file can hold several resources separated by three dashes.

What format should manifests use?

YAML is the most common because it is easy to read. Kubernetes also accepts JSON.

How does Testkube use manifests?

Testkube installs from manifests or Helm charts, and its test workflows are defined as Kubernetes custom resources.

How do I apply a manifest in Kubernetes?

Run kubectl apply -f with the file name, or let a GitOps tool apply it from Git.

What happens if I modify a manifest after deployment?

Reapplying it updates the resource. Kubernetes reconciles the cluster to match the new desired state.

Related Terms and Concepts

No items found.