Kubernetes Manifests

Kubernetes manifests are the foundational, declarative files that define the desired state of Kubernetes objects such as Deployments, Services, ClusterRoles, ReplicaSets, and CustomResourceDefinitions. While manifests themselves are not package managers, they are central to how you describe and manage native Kubernetes resources.

The image illustrates components of a Kubernetes cluster such as Pod, Service, and Deployment, represented as a structured diagram with a YAML file input.

Manifests are typically authored in YAML (or JSON) — the formats accepted by the Kubernetes API — and applied to a cluster to create or update resources. They are declarative: you describe what you want, and the Kubernetes control plane reconciles the cluster to match that state. Below is a simple example that defines a Deployment and a Service in a single manifest file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
  labels:
    app: my-web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
        - name: my-web-app
          image: nginx:latest
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-web-app-service
  labels:
    app: my-web-app
spec:
  type: ClusterIP
  selector:
    app: my-web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Apply this manifest to your cluster using kubectl:

kubectl apply -f my-manifests.yaml

Keep YAML indentation consistent and ensure the Deployment’s pod template (spec.template under spec) is present — otherwise the API will reject the object.

Advantages and trade-offs of using raw Kubernetes manifests:

Benefit	Details
Full control	Manifests expose all fields of the Kubernetes API so you can tune behavior precisely.
Declarative & native	The YAML maps directly to Kubernetes objects and describes the desired cluster state.
No abstraction overhead	No hidden behavior — what you declare is what Kubernetes understands.

Trade-off	Details
Repetition	No built-in templating or parameterization leads to duplicated manifests across environments.
Dependency management	You must handle ordering and inter-resource relationships outside the manifest files.
Reuse and versioning	Manifests lack native packaging/versioning; teams rely on external tools or workflows.
Human error	Large sets of hand-edited YAML can be error-prone and harder to maintain.

The image shows a comparison of pros and cons, with "Pros" in green including aspects like fine-grained control and customization, and "Cons" in red highlighting issues like manual overhead and lack of templating.

Because of these limitations, teams commonly adopt packaging or templating tools to reduce duplication, manage dependencies, and improve reuse. Helm is the most popular package manager for Kubernetes and is often chosen to add templating, versioning, and dependency features on top of raw manifests. Links and references

Watch Video

Section Introduction

Helm