Skip to main content

Kubernetes YAML Generator

Generate Kubernetes resource manifests for Deployments, Services, Ingress, HPA, and ConfigMaps with proper structure and best practices.

Configuration

Generated YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: nginx:1.25
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /health
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

What is Kubernetes YAML?

Kubernetes uses YAML manifests to declaratively define the desired state of your applications and infrastructure. These manifests describe resources like Deployments (how many replicas of your app to run), Services (how to expose them), Ingress (external access routing), HorizontalPodAutoscalers (auto-scaling rules), and ConfigMaps (configuration data). Writing correct YAML is essential for reliable Kubernetes operations.

This generator creates production-ready manifests following Kubernetes best practices: resource limits to prevent noisy neighbors, readiness probes for safe rollouts, proper labels for service discovery, and autoscaling configurations for handling variable load.

Frequently Asked Questions

What are resource limits in Kubernetes?

Resource limits define the maximum CPU and memory a container can use. Requests define the minimum guaranteed resources. The scheduler uses requests to place pods on nodes, while limits prevent a single pod from consuming all node resources. Setting appropriate limits prevents cascading failures and ensures fair resource sharing across workloads.

What is a readiness probe?

A readiness probe tells Kubernetes when a container is ready to accept traffic. Until the probe succeeds, the pod is removed from service endpoints. This prevents routing traffic to containers that are still starting up, loading caches, or establishing database connections. Common probe types include HTTP GET checks, TCP socket checks, and exec commands.

ClusterIP vs NodePort vs LoadBalancer?

ClusterIP (default) exposes the service only within the cluster—used for internal communication between microservices. NodePort exposes the service on each node's IP at a static port (30000-32767)—useful for development. LoadBalancer provisions an external load balancer (cloud provider specific)—used for production external traffic. Most production setups use ClusterIP services behind an Ingress controller.