Kubernetes Manifest Generator

A Kubernetes manifest is a YAML (or JSON) file that declares the desired state of a Kubernetes resource — such as a Deployment, Service, or ConfigMap. You submit manifests to the cluster with kubectl apply, and Kubernetes continuously reconciles the actual cluster state to match what the manifest describes. Manifests are the standard way to manage Kubernetes workloads in a declarative, version-controllable way.

kubectl apply -f manifest.yaml sends the manifest to the Kubernetes API server, which creates or updates the resource to match the declared state. Unlike kubectl create (which fails if the resource already exists), apply is idempotent — running it multiple times on the same manifest produces the same result. It also records the configuration for future diffs. Use kubectl apply -f for all production workflows.

Both store key-value data that can be injected into Pods as environment variables or mounted as files. The key differences: ConfigMaps store plain text and are intended for non-sensitive configuration (feature flags, connection strings, etc.). Secrets store base64-encoded data and are designed for sensitive values (passwords, tokens, certificates). Kubernetes can encrypt Secrets at rest and restricts access via RBAC. Never put sensitive values in a ConfigMap.

ClusterIP (default) exposes the Service on an internal cluster IP — only reachable within the cluster. NodePort opens a port on every Node's IP (range 30000-32767) so the service is reachable from outside the cluster without a load balancer. LoadBalancer provisions an external cloud load balancer (AWS ELB, GCP LB, etc.) and assigns a public IP — the standard production method for exposing services externally. Use ClusterIP for internal microservices, LoadBalancer or Ingress for public traffic.

A LoadBalancer Service provisions one cloud load balancer per Service, which gets expensive with many services. An Ingress is a single entry point that routes HTTP/HTTPS traffic to multiple Services based on host name or URL path — using one load balancer for the whole cluster. Ingress also handles TLS termination centrally. Use Ingress when you have multiple HTTP services, need host/path-based routing, or want centralized TLS management. Ingress requires an Ingress Controller (nginx-ingress, Traefik, etc.) installed in the cluster.

Requests tell the Kubernetes scheduler how much CPU and memory a container needs — used to decide which Node to schedule the Pod on. Limits cap the maximum resources a container can consume; exceeding the CPU limit causes throttling, and exceeding the memory limit causes the container to be OOMKilled and restarted. Best practice: always set both requests and limits. CPU values use millicores (500m = 0.5 CPU cores). Memory uses binary suffixes: Mi (mebibytes), Gi (gibibytes).