{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Use the app or service name that should appear in kubectl output.
Set a target namespace, or leave blank for a namespace-neutral manifest.
Prefer a digest or release tag instead of latest.
The generated Deployment uses this desired replica count.
pods
Expose the port your container listens on inside the pod.
{{ params.protocol }}
Choose whether the generator should include a Service manifest.
Use 80 for normal HTTP Services, or match the container port when you want one number everywhere.
{{ params.protocol }}
Pick the probe shape the generated container should expose.
Use a low-cost endpoint that does not mutate state.
Choose starter CPU and memory quantities, or switch to custom values.
Example: 250m.
Example: 256Mi.
Example: 1000m, or blank.
Example: 512Mi, or blank.
Choose how much securityContext hardening the manifest should include.
Overrides the generated container name only.
Use a short lowercase IANA-style name such as http or grpc.
Controls when kubelet should pull the image.
Sets container and Service protocol.
Optional explicit NodePort, usually 30000-32767.
node
Set only when the workload needs a named service account.
The default omits the field and keeps Kubernetes default behavior.
{{ params.automount_service_account_token ? 'Kubernetes default' : 'Disabled' }}
Optional metadata labels for ownership, team, or tier tracking.
Optional literal env values for starter manifests; keep secrets in Secret references instead.
Leave blank if the workload does not need a ConfigMap env source.
Reference an existing Secret without exposing its values.
Example: 25% or 1.
Example: 0, 1, or 25%.
Use 0 to omit a waiting window, or a small value for rollout stability.
s
600 seconds is a common ten-minute rollout deadline.
s
Keep enough time for request draining and shutdown hooks.
s
Use 0 to omit startupProbe, or set the expected startup grace window.
s
Leave off unless metrics-server and CPU requests are available in the cluster.
{{ params.include_hpa ? 'On' : 'Off' }}
Usually match the Deployment baseline for steady traffic.
pods
Set a cap that matches namespace quota and downstream capacity.
pods
Common starting values are 60-75 percent.
%
Use with more than one replica so node drains have room to proceed.
{{ params.include_pdb ? 'On' : 'Off' }}
Example: 1 or 50%.
{{ result.yaml }}
{{ header }} Copy
{{ cell }}
No table rows for the current manifest. 

        

      

    

  

                

                

                    

                        

                            Tags: Devops, Sysadmin
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    

    
A Kubernetes Deployment manifest describes the desired state for a replicated application: the pod template to run, the number of replicas to keep, and the rollout policy the controller should use when that template changes. A useful deployment draft also needs the surrounding choices that make the workload reachable, observable, and safer to operate, including Service routing, health probes, resource reservations, and security context settings.


    
Manifest generation is most helpful before a pull request, release handoff, namespace migration, or first cluster test. The draft should make the important Kubernetes choices visible early: which image will run, how many pods should exist, which labels bind the Deployment to a Service or disruption policy, and which checks still need evidence from the target cluster.


    

      
        Kubernetes manifest draft flow
        A deployment draft moves from workload inputs through pod template, service routing, health and resource policy, and review output.
        
        
          
          
          
          
          
          
            Inputs
            Deployment
            Service
            Policy
            Review
          
          
            image, port
            replicas
            pod template
            rollout rules
            selector
            targetPort
            probes, resources
            security, HPA, PDB
            YAML
            checks
          
          
            
            
            
            
            
            
            
            
          
          The generated draft is a starting manifest plus static review notes, not proof that the cluster will admit or run it.
        
      
    


    
A manifest draft can be syntactically clear and still be wrong for the destination cluster. Admission policies, image pull credentials, quota, node capacity, service annotations, ingress or gateway design, and actual application readiness all live outside the draft. Treat generated YAML as a structured starting point, then verify it with the cluster policy and workload behavior that will receive it.

  






  

    
Technical Details:


    
A Deployment controls a pod template through ReplicaSets. The selector must keep matching the labels on the pod template, because that relationship is how the controller knows which pods belong to the rollout. A Service uses a separate selector to route traffic to ready endpoints, so label consistency is part of both rollout safety and network reachability.


    
Readiness, liveness, and startup probes answer different questions. Readiness decides whether a pod should receive Service traffic. Liveness is a restart signal for a container that cannot recover. Startup probes give slow-starting applications time before normal probe behavior begins. A generated probe is therefore only useful when the endpoint or socket actually reflects the application state.


    
Resource requests, security context, HPA, and PDB settings are policy signals. CPU requests can use millicpu such as 250m, while memory quantities commonly use suffixes such as Mi or Gi. CPU-based autoscaling needs CPU requests to calculate utilization, and disruption budgets protect voluntary evictions rather than every possible outage.


    
Rule Core:

    
The generated manifest follows a direct mapping from workload settings to Kubernetes resources. Optional resources appear only when the selected options need them.


    

      

        
        
          

            Manifest part
            What is emitted
            Main review cue
          

        
        
          

            Deployment
            apps/v1 Deployment with replicas, selector labels, pod template, rolling update settings, revision history, and progress deadline.
            Selector labels and template labels must stay aligned; changing them after apply can orphan or replace pods.
          

          

            Container
            Image, pull policy, named port, protocol, literal environment variables, optional ConfigMap and Secret references, resources, probes, and security context.
            Use a digest or release tag, confirm the port is the real container listener, and keep secret values out of literal environment rows.
          

          

            Service
            Optional ClusterIP, LoadBalancer, or NodePort Service using the same selector labels and a named targetPort.
            LoadBalancer depends on provider behavior, and explicit NodePort values should fit the cluster range.
          

          

            Health probes
            HTTP readiness and liveness, HTTP readiness only, TCP readiness and liveness, optional startup probe, or no probe block.
            Readiness should reflect traffic safety; liveness should represent unrecoverable failure rather than a slow dependency.
          

          

            Resources
            Small, balanced API, worker-sized, requests-only, no-resource, or custom CPU and memory request and limit values.
            Scheduler and HPA behavior depend on requests; memory quantity case matters because Mi and m mean very different things.
          

          

            HPA and PDB
            Optional autoscaling/v2 HPA with CPU target and optional policy/v1 PDB with minAvailable.
            Confirm metrics availability, CPU requests, replica count, and voluntary disruption expectations before applying these objects.
          

        
      

    


    
Validation and Warning Boundaries:

    
Validation blocks YAML copy when required inputs are missing or malformed. Warnings keep the manifest visible but mark settings that need human review before use.


    

      

        
        
          

            Condition
            Output behavior
            Why it matters
          

        
        
          

            Missing workload name or image
            Shows a blocking input error and emits comment-only YAML until fixed.
            A Deployment without a stable object name or container image cannot be applied meaningfully.
          

          

            Name, namespace, service account, ConfigMap, Secret, or port name does not fit the expected Kubernetes label shape
            Normalizes where possible and reports errors for invalid generated names.
            DNS-safe names reduce apply failures and keep selectors readable in kubectl output.
          

          

            Image is unpinned or uses :latest
            Adds a readiness review row and warning.
            Mutable image references can produce different pods from the same manifest text.
          

          

            maxSurge and maxUnavailable are both zero
            Blocks output with a rolling update error.
            A rollout cannot progress when no extra pod and no unavailable pod are allowed.
          

          

            HPA max replicas is lower than min replicas
            Blocks output with an HPA range error.
            The autoscaler cannot honor an inverted replica range.
          

          

            Service traffic has no readiness probe
            Adds a warning when Service output is present and probes are disabled.
            Without readiness, endpoints can receive traffic before the application is ready to serve it.
          

          

            One replica plus PDB minAvailable of 1
            Adds a warning.
            That combination can block voluntary node drains for the selected workload.
          

        
      

    


    
Generation and review happen in the browser session. There is no tool-specific server backend for building the manifest, but copied YAML, downloaded outputs, screenshots, and shared URLs can still expose workload names, registry hosts, environment values, and internal service references.

  






  

    
Everyday Use & Decision Guide:


    
Start with a conservative web-service draft: a DNS-safe workload name, a pinned image, at least two replicas for normal HTTP traffic, ClusterIP Service, HTTP readiness and liveness probes, the balanced API resource preset, and the restricted-compatible security profile. That combination creates a readable first manifest without assuming public exposure, autoscaling, or disruption policy too early.


    
Use No Service for a worker that does not need a stable network endpoint. Use LoadBalancer Service only when the target cluster has a provider integration and the exposure decision is already approved. Use NodePort Service carefully; leaving the NodePort blank lets Kubernetes allocate one, while an explicit value should fit the cluster range and firewall plan.


    
    
      
  • Keep Container image on a digest or release tag before copying production YAML.
    • 
      
  • Set HTTP health path to a cheap endpoint such as /healthz that checks local readiness without changing application state.
    • 
      
  • Use Requests only when CPU limits are not part of local policy, but keep CPU and memory requests if HPA or scheduler review matters.
    • 
      
  • Choose Hardened plus read-only root filesystem only after confirming the image can run without writing to its root filesystem.
    • 
      
  • Reference a ConfigMap or Secret through envFrom when values already exist in the cluster; do not paste secret values into literal environment rows.
    • 
      
  • Add HPA only when metrics-server and CPU requests are available, and set the max replica cap against namespace quota and downstream capacity.
    • 
      
  • Add PDB only when replica count and drain behavior are known. A disruption budget can protect availability, but it can also slow maintenance if set too tightly.
    • 
    


    
The main stop-and-verify surface is Readiness Review. A Review row for the image, probes, resources, security context, autoscaling, or disruption budget means the YAML may still be valid, but the choice needs cluster or workload evidence before apply.


    
Finish by comparing Manifest Ledger with the YAML text. The ledger is easier to scan for resource count, API version, namespace, and purpose; the YAML is the artifact that kubectl apply will read.

  






  

    
Step-by-Step Guide:


    
Build the manifest from identity to traffic to policy, then use the review table before applying it to a cluster.


    
    
      
  1. Enter Workload name, Namespace, and Container image. Check the warning panel if names are normalized or the image is not pinned.
    2. 
      
  2. Set Replicas, Container port, Service exposure, and Service port. Confirm the summary names the intended resources and service type.
    3. 
      
  3. Choose Health probes. For HTTP probes, set a path that starts with /; for TCP probes, confirm a socket check is enough for the workload.
    4. 
      
  4. Pick a Resource preset or enter custom CPU and memory quantities. Fix any invalid quantity before trusting the YAML.
    5. 
      
  5. Choose a Pod security profile. If using the hardened profile, verify writable paths and application startup before release.
    6. 
      
  6. Open Advanced for container name, port name, pull policy, protocol, service account, service-token mounting, labels, environment rows, ConfigMap or Secret references, rollout timing, startup probe window, HPA, and PDB settings.
    7. 
      
  7. Read red validation errors first. Fix blocked fields such as missing image, invalid health path, duplicate labels, malformed environment variables, inverted HPA range, or impossible rolling update settings.
    8. 
      
  8. Open Manifest Ledger to confirm whether the generated set contains Deployment only, Deployment plus Service, or the optional HPA and PDB objects.
    9. 
      
  9. Open Readiness Review, resolve warnings, then copy or download Deployment YAML for cluster-side validation.
    10. 
    

  






  

    
Interpreting Results:


    
The summary headline gives the first gate. Check inputs means the YAML pane is not an apply-ready manifest. A manifest count means the input set passed validation, and the line below the count names the workload, namespace when present, and resource kinds emitted.


    

      

        
        
          

            Output cue
            What it means
            What to verify next
          

        
        
          

            Deployment YAML
            The generated Kubernetes manifests separated with YAML document dividers.
            Run a dry-run or review apply output against the target cluster before merging or release.
          

          

            Manifest Ledger
            A resource-by-resource summary of kind, name, API version, namespace, purpose, and apply note.
            Check that optional Service, HPA, and PDB resources appear only when intended.
          

          

            Readiness Review
            A static review of image pinning, rollout window, probes, resource policy, security context, service exposure, autoscaling, and disruption budget.
            Use Review rows as follow-up work, not as approval or failure by themselves.
          

          

            JSON
            A structured mirror of parameters, normalized values, warnings, errors, manifest list, and YAML.
            Use it for handoff notes or issue comments when reviewers need the choices behind the generated text.
          

        
      

    


    
Do not read apply-ready draft as a production guarantee. It means the static generator found no blocking errors and no built-in warnings. The cluster still decides admission, quota, defaults, image pull access, scheduling, network routing, and runtime behavior.

  






  

    
Worked Examples:


    
Internal API with readiness and resource requests

    
A workload named orders-api in production uses image ghcr.io/example/orders-api:2026.05, three replicas, container port 8080, ClusterIP Service on port 80, HTTP readiness and liveness at /healthz, balanced API resources, and the restricted-compatible security profile. The generated set contains a Deployment and Service. Readiness Review should mark probes, resources, service exposure, and security context as ready or configured, while still leaving cluster-side dry-run and application health testing to the operator.


    
Worker deployment with no Service

    
A queue worker keeps the workload name and image, sets Service exposure to No Service, and leaves probes on TCP only if the worker exposes a meaningful local socket. Manifest Ledger reports a single Deployment. That is not a missing Service error; it is the expected shape for a worker that does not need stable Service routing.


    
Autoscaling draft that needs CPU requests

    
If Include HPA is enabled while the resource preset omits CPU requests, the manifest can still include an HPA object, but the review warns that CPU-based scaling needs CPU requests. The safer correction is to select a preset with CPU and memory requests or add custom request values before relying on a CPU utilization target such as 70%.


    
Single replica with a strict disruption budget

    
A one-replica Deployment with Include PDB enabled and minAvailable set to 1 gets a warning because voluntary node drains may be blocked. For a highly available service, increase replicas and confirm the budget matches the maintenance policy. For a singleton, decide whether a PDB belongs in the first draft at all.

  






  

    
FAQ:


    

      Does the generator apply anything to a cluster?
      
No. It creates manifest text and review tables only. Use kubectl diff, server-side dry-run, admission review, or a controlled test environment before applying the YAML.

    


    

      Why did my workload name change?
      
Object names are normalized into lowercase DNS-style labels. Spaces, punctuation, uppercase letters, and repeated separators can change so the generated names fit common Kubernetes naming rules.

    


    

      Why does the image reference warning matter?
      
An image without a digest or stable release tag can point to different content later. Use a digest or explicit version tag when repeatable rollout behavior matters.

    


    

      Should every Deployment include liveness probes?
      
No. Liveness is a restart trigger. Use it only when the check represents an unrecoverable local failure, and prefer readiness for traffic routing decisions.

    


    

      Can the generated restricted profile satisfy every Pod Security policy?
      
No. It emits common hardening fields such as non-root pod context, runtime default seccomp, no privilege escalation, and dropped capabilities, but the target namespace may enforce additional rules.

    


    

      Where should secret values go?
      
Use existing Kubernetes Secrets and reference them when needed. Literal environment rows are useful for non-sensitive starter values, but copied manifests and review exports can expose anything placed there.

    

  






  

    
Glossary:

    

      
Deployment

      
A Kubernetes workload object that manages replicated pods through ReplicaSets and rollout policy.

      
Service

      
A stable network object that selects pods and routes traffic to their ready endpoints.

      
Readiness probe

      
A health check used to decide whether a pod should receive Service traffic.

      
Liveness probe

      
A health check used to restart a container when it appears unable to recover.

      
Resource request

      
The CPU or memory amount Kubernetes uses as a scheduling reservation signal.

      
HorizontalPodAutoscaler

      
A Kubernetes object that changes replica count based on metrics such as CPU utilization.

      
PodDisruptionBudget

      
A policy object that limits voluntary disruptions for selected pods.

    

  






  

    
References: