Kubernetes Deployment Generator

Workload name:

Use the app or service name that should appear in kubectl output.

Namespace:

Set a target namespace, or leave blank for a namespace-neutral manifest.

Container image:

Prefer a digest or release tag instead of latest.

Workload class:

Classify the workload before reviewing Service exposure, probes, rollout, and policy warnings.

Cluster policy profile:

Choose whether the generated artifact set should include namespace admission labels.

Kubernetes compatibility:

Target the API and policy-version shape expected by the cluster generation window.

Output package:

Choose the artifact shape before copying or downloading the generated output.

Replicas: {{ params.replicas }} pods

The generated Deployment uses this desired replica count.

pods

Rollout strategy profile:

Choose the rollout behavior before copying YAML; use Custom to expose exact timing fields in Advanced.

Container port:

Expose the port your container listens on inside the pod.

Service exposure:

Choose whether the generator should include a Service manifest.

Service port:

Use 80 for normal HTTP Services, or match the container port when you want one number everywhere.

Health probes:

Pick the probe shape the generated container should expose.

HTTP health path:

Use a low-cost endpoint that does not mutate state.

Resource preset:

Choose starter CPU and memory quantities, or switch to custom values.

CPU request:

Example: 250m.

Memory request:

Example: 256Mi.

CPU limit:

Example: 1000m, or blank.

Memory limit:

Example: 512Mi, or blank.

Security baseline:

Choose the securityContext baseline that should be emitted and checked against the cluster policy profile.

Fix manifest inputs

{{ error }}

Review generated manifest

{{ warning }}

Container name:

Overrides the generated container name only.

Port name:

Use a short lowercase IANA-style name such as http or grpc.

Image pull policy:

Controls when kubelet should pull the image.

Port protocol:

Sets container and Service protocol.

NodePort:

Optional explicit NodePort, usually 30000-32767.

node

Service account:

Set only when the workload needs a named service account.

Automount service token:

The default omits the field and keeps Kubernetes default behavior.

{{ params.automount_service_account_token ? 'Kubernetes default' : 'Disabled' }}

Extra labels:

Optional metadata labels for ownership, team, or tier tracking.

Environment variables:

Optional literal env values for starter manifests; keep secrets in Secret references instead.

ConfigMap envFrom:

Leave blank if the workload does not need a ConfigMap env source.

Secret envFrom:

Reference an existing Secret without exposing its values.

Rolling maxSurge:

Example: 25% or 1.

Rolling maxUnavailable:

Example: 0, 1, or 25%.

minReadySeconds: {{ params.min_ready_seconds }}s

Use 0 to omit a waiting window, or a small value for rollout stability.

progressDeadlineSeconds: {{ params.progress_deadline_seconds }}s

600 seconds is a common ten-minute rollout deadline.

terminationGracePeriodSeconds: {{ params.termination_grace_seconds }}s

Keep enough time for request draining and shutdown hooks.

Startup probe window: {{ params.startup_window_seconds }}s

Use 0 to omit startupProbe, or set the expected startup grace window.

Include HPA:

Leave off unless metrics-server and CPU requests are available in the cluster.

HPA min replicas: {{ params.hpa_min_replicas }} pods

Usually match the Deployment baseline for steady traffic.

pods

HPA max replicas: {{ params.hpa_max_replicas }} pods

Set a cap that matches namespace quota and downstream capacity.

pods

HPA CPU target: {{ params.hpa_cpu_target }}%

Common starting values are 60-75 percent.

Include PDB:

Use with more than one replica so node drains have room to proceed.

PDB minAvailable:

Example: 1 or 50%.

{{ result.yaml }}

{{ header }}	Copy
{{ cell }}
No table rows for the current manifest.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A Kubernetes Deployment turns a desired application state into controller work. It defines a pod template, a replica count, and a rollout strategy, then the Deployment controller creates or updates ReplicaSets until the cluster moves toward that state. The YAML matters because it is the contract the API server receives, but the running result also depends on admission policy, scheduler capacity, image pulls, health probes, and how the application behaves while pods are replaced.

Deployment manifests are easy to make syntactically valid and still unsafe to apply. A Service can select the wrong pods, a readiness probe can send traffic before dependencies are usable, a mutable image tag can point to a different build after review, and a namespace can reject pods that do not satisfy resource or security policy. Good release planning connects the object model to the operational evidence that says the workload can actually run in the target cluster.

Pod template: The container, ports, probes, resources, labels, and security settings that new pods inherit.
Selector: The label match that connects a Deployment to its pods and connects a Service to the endpoints it should route to.
Readiness: The signal that decides whether a pod should receive Service traffic, separate from whether the container process is still alive.
Policy: Cluster and namespace rules such as resource quota, Pod Security Admission, image policy, and required limits.

Workload type drives the manifest shape. A stateless API often needs a ClusterIP Service, more than one replica, readiness and liveness probes, resource requests, and a rolling update that keeps old pods serving while new pods become ready. A background worker may need no Service at all, but it still benefits from clear labels, graceful shutdown time, resource requests, and a security context that matches namespace policy.

Deployment, Service, policy, and review pieces in a Kubernetes manifest draft.

Autoscaling and disruption budgets help only when their prerequisites are present. A CPU-based HorizontalPodAutoscaler needs useful CPU requests and working metrics collection. A PodDisruptionBudget protects availability during voluntary maintenance, but one replica with a strict minimum can also block node drains. These companion resources should reflect how the workload scales and recovers, not a desire for more YAML.

A manifest draft remains a starting point until the target cluster accepts it. Before release, compare it with namespace quota, Pod Security Admission settings, registry access, image pull secrets, node capacity, ingress or gateway design, service annotations, metrics availability, and the real health behavior of the application.

How to Use This Tool:

Start with identity, traffic shape, and target-cluster assumptions, then review the generated resources before copying the YAML.

Enter Workload name, Namespace, and Container image. Use a digest or release-specific tag for reviewable output, and leave Namespace blank only when the manifest should apply to the current kubectl namespace.
Choose Workload class, Cluster policy profile, Kubernetes compatibility, and Output package. These choices control workload intent, optional Namespace policy labels, the HPA API version, and whether the output is multi-document YAML, a List object, or Kustomize-style file sections.
Set Replicas, Rollout strategy profile, Container port, and Service exposure. APIs and frontends usually need a Service and more than one replica; worker workloads often use No Service.
Pick Health probes, Resource preset, and Security baseline. HTTP probe paths must start with /, custom resource quantities must use Kubernetes CPU and memory syntax, and a restricted namespace policy requires a restricted-ready security baseline.
Open Advanced when the manifest needs a container name, port name, image pull policy, protocol, service account, token-mount choice, literal environment values, ConfigMap or Secret references, custom rollout timing, startup probe window, HPA, or PDB.
Fix red input errors before using the output. Common blockers include an empty image, invalid DNS label, invalid port name, invalid resource quantity, maxSurge and maxUnavailable both set to zero, HPA max replicas below HPA min replicas, or an invalid PDB value.
Review Output Package, Manifest Ledger, Readiness Review, Resource/Security Ledger, and Manifest Topology. Copy the YAML only after the warning list matches decisions you are ready to check with a cluster dry run.

Interpreting Results:

The summary badges show whether the current inputs are blocked, need review, or have produced an apply-ready draft. Treat apply-ready draft as a local consistency result, not proof that the target cluster will admit the objects or run the workload successfully.

Output Package is the YAML or file-section text you can copy. Manifest Ledger lists each emitted resource, its API version, namespace scope, and purpose. Readiness Review catches release assumptions such as an unpinned image, no readiness probe behind a Service, one replica for a service workload, or a missing CPU request for HPA. Resource/Security Ledger explains resource requests and limits, service-account token behavior, security baseline, and optional policy choices. Manifest Topology shows how the Deployment, pods, Service, HPA, PDB, and Namespace policy relate when they are included.

Run kubectl apply --dry-run=server or an equivalent admission-policy check before applying the YAML.
Test the actual readiness and liveness endpoints; a syntactically valid probe can still be the wrong health signal.
Confirm that warnings about image pinning, replica count, HPA metrics, PDB drains, or security baseline are intentional rather than ignored defaults.
Keep secret values out of literal environment variables; reference existing Secret objects through Secret envFrom instead.

Technical Details:

A Deployment is a controller-driven workload. The selector identifies the pods it owns, and changes to the pod template create new ReplicaSets for rollout. Because selectors define ownership, changing selector labels after adoption is risky and normally avoided. Service routing uses its own selector, so the Service and Deployment labels must describe the same pod set when traffic should reach those pods.

Health probes, rollout settings, resources, and policy fields affect different parts of the release. Readiness controls Service endpoints, liveness restarts a container that appears unable to recover, and startup probes delay normal liveness checks for slow initialization. Resource requests influence scheduler placement and provide the denominator for CPU-based autoscaling, while limits and security context fields are often governed by namespace policy.

Rule Core:

Generated Kubernetes resource rules
Resource	When it appears	Generated effect	Review boundary
Deployment	Always, when inputs pass validation.	`apps/v1` Deployment with replicas, selector labels, pod template, container image, port, probes, resources, security context, and rollout strategy.	Verify image immutability, label consistency, probe truth, resource requests, and shutdown timing.
Service	When Service exposure is not No Service.	`v1` Service with selected type, port, protocol, selector labels, and named `targetPort`.	Use no Service for workers unless they need a stable endpoint; test readiness before routing traffic.
Namespace policy	When a PSA profile is selected and Namespace is present.	`v1` Namespace labels for enforce, warn, and audit Pod Security Admission modes.	Restricted policy needs a restricted-ready pod security baseline and cluster support for PSA labels.
HorizontalPodAutoscaler	When Include HPA is on.	CPU utilization target with min and max replicas; API version follows the compatibility choice.	CPU-based HPA needs metrics collection and CPU requests on the target container.
PodDisruptionBudget	When Include PDB is on.	`policy/v1` PDB with `minAvailable` and the Deployment selector labels.	One replica with `minAvailable: 1` can block voluntary node drains.
Output wrapper	Selected with Output package.	Multi-document YAML, one `v1/List`, or Kustomize base file sections.	Choose the shape that matches the review or apply workflow you will actually use.

Validation Core:

Kubernetes manifest validation checks
Check	Accepted shape	Why it matters
Generated names	Lowercase DNS labels up to 63 characters.	Kubernetes object names and selector-bearing references need predictable DNS-safe values.
Port name	Lowercase IANA-style name up to 15 characters.	Named ports let probes and Services continue pointing at the same logical port.
HTTP probe path	Must begin with `/`.	The generated HTTP readiness, liveness, and startup probes call that path on the named port.
Rolling update values	Numbers or percentages; `maxSurge` and `maxUnavailable` cannot both be zero.	A rolling update needs permission to create a new pod or make an old pod unavailable.
NodePort	Blank, or an explicit value from `30000` to `32767`.	Blank lets the cluster allocate a port; explicit values must fit the normal NodePort range.
HPA bounds	Max replicas must be greater than or equal to min replicas.	The autoscaler cannot scale inside an inverted replica range.
PDB value	Integer or percentage.	Voluntary disruption rules need an unambiguous availability target.

Formula Core:

When a startup probe window is set, the startup probe uses a fixed 10-second period and rounds the requested window up to a whole number of probe failures.

failureThreshold = ⌈ \frac{startupWindowSeconds}{10} ⌉

A 60-second startup window emits failureThreshold: 6. A 65-second window emits failureThreshold: 7, because rounding up prevents the generated startup probe from being shorter than the requested grace window.

Limitations:

The generated result is a static manifest draft. It does not contact the Kubernetes API server, inspect cluster admission policy, check image registry access, prove pull credentials, measure node capacity, or confirm that an application endpoint is a meaningful health check.

Run a server-side dry run, policy check, or CI review before applying the YAML.
Check namespace quota, LimitRanges, Pod Security Admission, image pull secrets, service annotations, and ingress or gateway requirements separately.
Use literal environment values only for non-secret starter values; keep passwords, tokens, and keys in Kubernetes Secrets.

Worked Examples:

A stateless API named orders-api in namespace production, using image ghcr.io/example/orders-api:2026.05, three replicas, HTTP probes on /healthz, ClusterIP Service, standard resources, and a restricted security baseline should produce Deployment and Service rows in Manifest Ledger. Readiness Review should show configured rollout, probes, resources, and Service exposure, while any image-pinning warning depends on whether that tag is specific enough for the release process.

A background worker using No Service, no probes, worker-sized resources, and a restricted security baseline can correctly produce only a Deployment row in Manifest Ledger. Readiness Review may still ask for release evidence around resources and security, but no Service is expected for a queue consumer that has no stable network endpoint.

A slow-starting API with Startup probe window set to 65 seconds emits failureThreshold: 7 in Output Package. The rounded threshold gives the app at least the requested startup window before normal liveness behavior can restart it.

A custom rolling update with maxSurge set to 0 and maxUnavailable set to 0 blocks output generation. Raise one of those values before using Output Package, because the Deployment controller would otherwise have no allowed path to replace pods.

FAQ:

Can I apply the generated YAML directly?

Use it as a draft first. Review warnings, then run a server-side dry run or admission-policy check in the target cluster before applying it to a namespace.

Why does the result warn about latest image tags?

Mutable tags make rollouts harder to reproduce. A digest or release-specific tag gives the manifest a clearer link to the image that was tested.

When should Service exposure be set to No Service?

Choose No Service for worker-style workloads that do not need a stable network endpoint. APIs, web frontends, and internal tools usually need Service routing unless another object handles traffic.

Why does HPA need CPU requests?

CPU utilization is calculated against requested CPU. Without a CPU request, a CPU-based HorizontalPodAutoscaler does not have the expected denominator for that container.

Why is my HTTP health path rejected?

HTTP probe paths must start with /. Change values such as healthz to /healthz, then review Output Package again.

Glossary:

Deployment: A workload object that manages ReplicaSets and pod-template rollouts.
ReplicaSet: The controller-owned object that keeps a matching set of pods at the desired replica count.
Selector: A label match used to associate a Deployment, Service, HPA, or PDB with the pods it should manage or target.
Service: A Kubernetes object that provides a stable network endpoint for selected pods.
Readiness probe: A probe that decides whether a pod should receive Service traffic.
HorizontalPodAutoscaler: An object that adjusts replica count from a scaling signal such as CPU utilization.
PodDisruptionBudget: A policy object that protects availability during voluntary disruptions such as node drains.
Pod Security Admission: Namespace-level admission controls that enforce, warn, or audit Pod Security Standards.

References:

Deployments, Kubernetes.
Service, Kubernetes.
Configure Liveness, Readiness and Startup Probes, Kubernetes.
Resource Management for Pods and Containers, Kubernetes.
Horizontal Pod Autoscaling, Kubernetes.
Specifying a Disruption Budget for your Application, Kubernetes.
Pod Security Admission, Kubernetes.

Kubernetes Deployment Generator

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Rule Core:

Validation Core:

Formula Core:

Limitations:

Worked Examples:

FAQ:

Glossary:

References: