kubernetes

Kubernetes Deployment YAML Generator

Generate a Kubernetes Deployment and ClusterIP Service YAML with resource requests/limits, liveness/readiness probes, and configurable replicas, image, and environment variables.

Generator

Inputs

App Name

Used as the Deployment name, Service name, and selector label.

Namespace

Container Image

Replicas

Container Port

CPU Request

Guaranteed CPU. 100m = 0.1 vCPU. Start low and tune up.

Memory Request

CPU Limit

CPU limits cause throttling. Set 4–8× the request.

Memory Limit

Exceeding the memory limit kills the pod (OOMKilled).

Environment Variables

Comma-separated KEY=value pairs.

Image Pull Policy

Include ClusterIP Service

Output — deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-app:latest
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 3000
              protocol: TCP
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 10
            periodSeconds: 15
          readinessProbe:
            httpGet:
              path: /ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
  namespace: default
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 3000
      protocol: TCP
  type: ClusterIP

Kubernetes Deployment Patterns

A Deployment manages a ReplicaSet which manages Pods. This three-level hierarchy provides rolling updates, rollback, and self-healing.

Resource Sizing

request = what you need on average
limit   = what you allow at peak (CPU: 4–8× request, memory: 1.5–2× request)

Probe Configuration

yaml

livenessProbe:
  httpGet:
    path: /healthz
    port: 3000
  initialDelaySeconds: 10   # wait for app to start
  periodSeconds: 15         # check every 15s
  failureThreshold: 3       # kill after 3 failures

readinessProbe: httpGet: path: /ready port: 3000 initialDelaySeconds: 5 periodSeconds: 10 ```

Rolling Update Strategy

yaml

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1        # create 1 extra pod during update
    maxUnavailable: 0  # never remove a pod before new one is ready

Pod Disruption Budget

yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: my-app

Key Terms

Full glossary →

kubeadm

A tool for bootstrapping Kubernetes clusters. It automates the setup of control plane components and joining worker nodes, following Kubernetes best practices.

etcd

A distributed key-value store used by Kubernetes to store all cluster state and configuration. etcd is the single source of truth for the entire cluster.

cert-manager

A Kubernetes controller for automating TLS certificate management. cert-manager can issue certificates from Let's Encrypt, Vault, or internal CAs, and automatically renews them.

Helm

A package manager for Kubernetes. Helm charts bundle Kubernetes manifests into reusable packages with configurable values, versioned and published to chart repositories.

Frequently Asked Questions

What's the difference between resource requests and limits?

Requests are what Kubernetes uses to schedule the pod — it guarantees that much CPU/memory is available. Limits are the maximum — exceeding CPU limits causes throttling, exceeding memory limits kills the pod (OOMKilled). Always set requests; set limits with care. Never set CPU limits to 0 or omit them on shared clusters.

What should my liveness vs readiness probe check?

Readiness: is the app ready to serve traffic? Check if DB connections are established, caches are warmed. If readiness fails, traffic is removed but the pod keeps running. Liveness: is the app stuck or deadlocked? If liveness fails, the pod is killed and restarted. Use different endpoints: /ready and /healthz.

Why use 2 replicas minimum?

A single replica means zero availability during node maintenance (kubectl drain) or pod eviction. With 2 replicas and a PodDisruptionBudget of minAvailable: 1, Kubernetes ensures at least one pod is always running during disruptions.

What is IfNotPresent vs Always for image pull policy?

IfNotPresent pulls the image only if not already cached on the node — faster for stable tags like v1.2.3. Always pulls on every pod start — required if you use mutable tags like latest. For production, use immutable image tags (SHA or version) with IfNotPresent.

Related Calculators

K8s Cluster Cost K8s Node Sizing

Related Generators

K8s Ingress ArgoCD App K8s RBAC

Related Comparisons

k3s vs kubeadm Kubernetes kubeadm vs RKE2

Related Guides

kubernetes

Kubernetes Deployment YAML Generator

Generator

Inputs

Output — deployment.yaml

Kubernetes Deployment Patterns

Resource Sizing

Probe Configuration

Rolling Update Strategy

Pod Disruption Budget

Key Terms

Frequently Asked Questions

What's the difference between resource requests and limits?

What should my liveness vs readiness probe check?

Why use 2 replicas minimum?

What is IfNotPresent vs Always for image pull policy?

Related Calculators

Related Generators

Related Comparisons

Related Guides

CI/CD for Kubernetes with GitHub Actions: A Complete Guide (2026)

ArgoCD vs Flux: Choosing a GitOps Tool for Kubernetes in 2026

Hetzner vs DigitalOcean for Kubernetes in 2026: An Honest Comparison

Generator

Inputs

Output — deployment.yaml