{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Workload: {{ resultsReady ? workloadClassLabel : '—' }} Package: {{ resultsReady ? packageLabel : '—' }} Review: {{ resultsReady ? `${computation.values.warning_count} flag${computation.values.warning_count === 1 ? '' : 's'}` : '—' }}

Topology visual unavailable.

Use the application name that should appear in kubectl output.
A blank value uses the namespace selected when the manifest is applied.
Example: ghcr.io/example/orders-api:2026.05.
Choose the closest runtime shape; it does not add provider-specific resources.
Prefer current stable APIs unless the target cluster is intentionally older.
The selected wrapper changes the generated artifact, download name, and ledger.
Use at least two for a normal traffic-serving rolling workload.
pods
Recreate stops old pods before new pods start and can interrupt traffic.
Provider-specific LoadBalancer annotations and ingress resources are outside this generator.
Use the port the application listens on inside the pod.
port
Port 80 is a common HTTP Service entry point.
port
Choose no probes only when the application has no reliable local health signal yet.
The path must start with /.
Treat presets as reviewable starting values, not measured capacity recommendations.
Hardened output needs an application that can run without writing to its root filesystem.

Optional overrides refine packaging, identity, rollout, resources, autoscaling, and disruption policy. Leave defaults unchanged for the baseline manifest.

Opening Advanced without changing this control does not change the output.
Controls when kubelet pulls the container image.
Sets both container and Service port protocol.
Blank lets Kubernetes allocate the NodePort.
Optional override for the generated container name.
Example: http or grpc.
Set only when the workload needs a named account.
Turn this option on when automount service token is required.
{{ automount_service_account_token ? 'Kubernetes default' : 'Disabled' }}
Optional ownership or tier labels, one per line.
Literal starter values only; do not paste real secrets.
s
s
The neutral 0-second default omits startupProbe.
s
Turn this option on when horizontalpodautoscaler is required.
{{ include_hpa ? 'Included' : 'Not included' }}
%
Turn this option on when poddisruptionbudget is required.
{{ include_pdb ? 'Included' : 'Not included' }}
{{ computation.values.manifest_yaml }}

The chart renderer is unavailable. The same relationships remain listed in the readiness ledger and manifest.

CheckpointCurrent valueStatusRecommended actionCopy
{{ row[0] }}{{ row[1] }}{{ row[2] }}{{ row[3] }}
Kubernetes Pod Security Context Checker Check Kubernetes workload YAML for inherited security contexts, Pod Security gaps, weighted findings, and a reviewable hardening patch.
Kubernetes Resource Requests Checker Check Kubernetes manifests for missing resource requests and invalid limits, with QoS clues and scheduler-footprint evidence before rollout.
Kubernetes NetworkPolicy Generator Build Kubernetes NetworkPolicy YAML from pod labels and allow rules with selector checks, rollout guidance, and security review warnings.
Kubernetes Cluster Capacity Calculator Estimate a rollout-safe Kubernetes replica ceiling from allocatable resources and pod requests, then test node loss and disruption limits.

A Kubernetes release begins with desired state, not a sequence of server commands. A Deployment declares a pod template and replica count, then the Deployment controller creates ReplicaSets and replaces pods at the selected rate. That makes the manifest repeatable, but it does not guarantee that the application will start, become ready, or satisfy cluster policy.

Deployment
Maintains the requested pod replicas and controls replacement during updates.
Service
Provides a stable network endpoint for pods whose labels match its selector.
Readiness probe
Determines when a pod may receive Service traffic.
Resource request
Tells the scheduler how much CPU or memory the container needs.

Several settings must agree. The Service selector must match the pod labels, its target port must reach the application listener, and a readiness probe must test a path or socket that reflects whether the workload can serve traffic. A syntactically valid manifest can still route nowhere or restart a healthy application when those assumptions are wrong.

Rollout policy controls the availability tradeoff. RollingUpdate can create extra pods with maxSurge and limit unavailable pods with maxUnavailable. Recreate stops the old pods before starting the new revision, which may be appropriate for some workloads but can interrupt service.

Security and capacity are cluster-specific. Pod Security Admission, quota, registry credentials, node architecture, storage, networking, metrics collection, and organization policy can all change whether the same YAML is accepted. Optional autoscaling and disruption resources also need operational support; more objects do not automatically make a workload safer.

Treat generated YAML as a reviewed draft. A server-side dry run, rollout check, EndpointSlice check, and application-specific smoke test provide evidence that the target cluster and the manifest agree.

How to Use This Tool:

Define the workload and its traffic path first, then add only the policies the target cluster can support.

  1. Enter the Workload name, optional Namespace, and a release-specific Container image.
  2. Choose the workload class, Kubernetes compatibility target, output package, replica count, and rollout strategy.
  3. Set Service exposure, container port, service port, protocol, and health probes. Background workers may legitimately use No Service.
  4. Select resource and security presets. Use the advanced fields when custom quantities, a service account, environment references, startup time, HPA, PDB, or namespace policy labels are required.
  5. Resolve input errors such as invalid names, ports, resource quantities, an inverted HPA range, or rolling values with both surge and unavailable set to zero.
  6. Read the Readiness ledger and warnings before copying the manifest. Follow with a server-side dry run against the intended cluster.

Interpreting Results:

The output is locally consistent when its inputs pass validation. The warning count identifies choices that deserve review, such as one replica with Recreate, missing probes, no resources, an unpinned image, or a security baseline that leaves policy work to the cluster.

A clean local review is not an admission result. Verify the resource kinds and traffic route, then ask the target API server to validate the manifest. After applying it, confirm that desired and available replicas match and that a Service has ready endpoints.

Technical Details:

A Deployment is always emitted with apps/v1. Its selector labels are reused by the pod template and any generated Service, autoscaler, or disruption budget so that all companion resources target the same workload.

Rule Core:

Choice Generated effect Review boundary
Service exposure Adds a ClusterIP, LoadBalancer, or NodePort Service; No Service omits it. NodePort accepts only 30000 to 32767.
Namespace policy Adds a Namespace with Pod Security Admission labels unless the portable choice is used. A restricted policy requires the restricted-compatible or hardened security baseline.
Health probes Adds HTTP or TCP readiness and liveness probes; an optional startup window adds a startup probe. The startup failure threshold is the window divided by 10 seconds, rounded up.
Horizontal autoscaling Adds a CPU-utilization HPA with the chosen minimum, maximum, and target. The maximum must be at least the minimum, and useful CPU requests plus metrics are still required.
Disruption budget Adds a policy/v1 PodDisruptionBudget with integer or percentage minAvailable. An aggressive minimum can block voluntary maintenance.
Compatibility Uses autoscaling/v2 for current targets and autoscaling/v2beta2 for the legacy 1.21 to 1.24 target. Use the API set accepted by the real cluster version.

Rolling profiles resolve to explicit values before YAML is written. The zero-downtime profile uses 25% surge, 0 unavailable, 5 seconds of minimum readiness, and a 600-second progress deadline. Balanced rolling uses 25% for both surge and unavailable. Conservative rolling uses a surge of 1, 0 unavailable, 15 seconds of minimum readiness, and a 900-second deadline.

HTTP and TCP probes run every 10 seconds with a 2-second timeout. Readiness starts after 5 seconds and liveness after 20 seconds. These are generated defaults, not measurements of the application, so slow startup and dependency behavior still need testing.

Replica input is limited to 1 through 100, and container and service ports to 1 through 65535. HPA limits extend to 500 replicas. Custom rollout values accept integers or percentages, while CPU and memory fields must use supported Kubernetes quantity syntax.

The output may be a multi-document YAML stream, a Kubernetes List, or a Kustomize-style set of file sections. Packaging changes the handoff shape, not the resource policies inside it.

Limitations:

The generator does not inspect the target cluster or application image.

  • Provider annotations, Ingress or Gateway resources, storage, image pull secrets, and network policy remain outside the generated package.
  • Probe paths, resource sizes, security settings, and rollout timing are configuration choices rather than observed runtime values.
  • Admission, quota, API availability, and registry access can only be confirmed against the intended cluster.

Worked Examples:

Internal HTTP service

A two-replica web frontend with a ClusterIP Service produces a Deployment and Service. If probes, resources, and security are all disabled, the manifest still generates, but the readiness review warns that traffic has no readiness gate, scheduling has no requests, and the pod has no selected security baseline. Fix those decisions before treating the YAML as a release candidate.

References: