> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Kubernetes Manifests
> Explains Kubernetes manifests, declarative YAML resource definitions, usage with kubectl, benefits and trade offs, and why teams use tools like Helm for templating and packaging.
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.
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:
```yaml theme={null}
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:
```bash theme={null}
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. |
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
* [Kubernetes Concepts — What is Kubernetes?](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
* [kubectl apply — Kubernetes CLI documentation](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply)
* [Helm — The Kubernetes Package Manager](https://helm.sh/)