Skip to main content

Basic Deployment

This series is using mendhak/http-https-echo as the containerized application to demo PlatformApplication functionality. Check out mendhak's GitHub repository for more options if you are curious.

What You'll Learn​

In this lesson, you'll learn:

  • Required fields for a Platform Application
  • How to deploy a container
  • How to verify the deployment
  • Platform's production-ready defaults
  • Understanding autoscaling, security, and resilience features

Manifest​

This example demonstrates the absolute minimum configuration required to deploy a container using a PlatformApplication.

application.yaml
apiVersion: meta.p6m.dev/v1alpha1
kind: PlatformApplication
metadata:
  name: demo-http-echo
  namespace: demo-http-echo
  labels:
    p6m.dev/app: demo-http-echo
spec:
  deployment:
    image: mendhak/http-https-echo:31
    ports:
      - port: 8080
        protocol: http
    readinessProbe:
      port: 8080
      path: /

Important Fields​

The minimal PlatformApplication for a web service requires three fields:

  • spec.deployment.image: The container image to deploy
    • If you do not define 'image', the PlatformApplication fails validation and does not get applied to the Kubernetes cluster.
  • spec.deployment.ports: Ports the container listens on
    • If you do not define 'ports', the Pod is deployed with no exposed ports — but the operator's Service objects then fail validation (spec.ports: Required value) and the PlatformApplication never reports Ready.
    • So declare a port even for an application that takes input from a Queue (or similar) rather than network requests. See Non-Web Workloads.
  • spec.deployment.readinessProbe: Health check configuration
    • If you do not define 'readinessProbe', the Platform Application Operator injects no probe at all, and the Pod is marked Ready as soon as it starts.
    • That is the right behavior for a background process that serves no traffic (see Non-Web Workloads), but for a web service it means traffic can arrive before the application is listening. Set the probe.
    • A readinessProbe is required when you enable ingress — it doubles as the load balancer health check.
    • For more information on Probes check out the official documentation.
  • spec.deployment.livenessProbe (optional): Restarts a container that's stuck or deadlocked
    • Independent of readinessProbe — it restarts the pod instead of just pulling it out of traffic. Not required for a basic deployment.
    • Unlike readinessProbe, initialDelaySeconds, periodSeconds, and timeoutSeconds must all be set explicitly; there's no default timing.
    • See the Platform Application Reference for the full field list.

What Gets Created​

By applying this PlatformApplication, the Platform Application Operator automatically creates:

• Deployment (2 replicas)
• Service (main, stable, canary)
• HorizontalPodAutoscaler (2-10 replicas, 80% CPU target)
• VerticalPodAutoscaler
• PodDisruptionBudget
• Cloud IAM (ex: Workload Identity)
• Gateway (for future ingress)
• NetworkPolicy
• PeerAuthentication (mTLS)
• AuthorizationPolicy

For a detailed breakdown of all resources, see the Basic Deployment - Details page.

Deploy Steps​

ArgoCD automatically updates to your PlatformApplication after the Platform Dispatch Action to update your .platform repository is run.

For more information on setting up ArgoCD for Platform Applications, see the ArgoCD Deployment Tutorial.

ArgoCD view of initial Platform Application deploymentArgoCD view of initial Platform Application deployment

The easiest way to find resources in the ArgoCD, once your application is synced, is to use the various filters on the left side of the ArgoCD UI. Let's use the Kinds filter to locate our Pods and Deployments.

ArgoCD view of initial Platform Application deploymentArgoCD view of initial Platform Application deployment

Check out our ArgoCD Cheat Sheet for how to view application logs and other tips on interacting with ArgoCD.

Common Observations​

Why are there 2 pods when I didn't specify replicas?

The platform's default HPA configuration requires minimum 2 replicas for high availability. You can customize this in the autoscaling section of your manifest.

It is also important in Kubernetes to run at least 2 pods, so that your application stays available even if the underlying compute Node hosting one Pod needs to be replaced.

What's the Gateway resource for?

Even without ingress enabled, the platform pre-creates a Gateway resource to prepare for easy ingress enablement later. This doesn't expose your application externally until you explicitly enable ingress.

Why so many resources for a "basic" deployment?

The platform prioritizes production readiness over simplicity. These defaults prevent common production issues like single points of failure, resource exhaustion, and security vulnerabilities.

tip

Want to dive deeper? See Basic Deployment - Details for comprehensive resource information, verification procedures, and spec documentation.

Next Steps​

Troubleshooting​

For common issues and solutions, see the Troubleshooting Guide.

Specific sections that may be helpful:

Cleanup​

Update your Git repository to remove the PlatformApplication manifest and sync, with prune enabled, the changes in ArgoCD to delete the application.

Prune is not enabled by default, so you will need to execute a manual sync with prune to delete the resources.

ArgoCD view of prune sync for Platform Application cleanupArgoCD view of prune sync for Platform Application cleanup

To fully clean up the namespace, you will need to delete the related folder in the .platform repository and manually delete the namespace:

kubectl delete namespace demo-http-echo

Kubernetes Core Concepts​

Tools & CLI​