#Creating applications from YAML

If you are proficient in YAML syntax and prefer to define configurations outside of forms or pre-defined templates, you can create applications from YAML. This approach provides more flexible control over application configuration and referenced resources.

#Precautions

When both Linux and Windows nodes exist in the cluster, consider configuring node selection so that the workload is scheduled only onto compatible nodes. For example:

spec:
    spec:
      nodeSelector:
        kubernetes.io/os: linux

#Prerequisites

Ensure the images defined in the YAML can be pulled within the current cluster. You can verify this using the podman pull command.

#Procedure

1. Container Platform, and navigate to Application > Applications.

2. Click Create.

3. Select Create from YAML.

4. Complete the configuration and click Create.

5. View the corresponding Deployment on the details page.

#Creation entry differences between the Applications and Clusters views

The new web console can expose YAML-based creation from different views. Choose the entry based on whether you are working from project scope or from a concrete cluster.

• Applications view: Start from the current project. Open Applications > Applications, click Create from YAML, select the target Cluster first, review or confirm the target Namespace from the YAML content, and then submit the resources.
• Clusters view: Start from a concrete cluster. Open the target cluster first, enter the target namespace, and then navigate to Applications or the related resource list to open the YAML creation workflow in that fixed cluster context.

Before proceeding, confirm the following differences:

• In the Applications view, cluster selection is part of the project-scoped application workflow.
• In the Clusters view, the cluster is already fixed because you start inside a concrete cluster.
• In the Applications view, the main order is to select the cluster first and then confirm the namespace declared in the YAML.
• In the Clusters view, the main order is to enter the concrete cluster first and then work in the target namespace context.

#Additional guidance for the Applications view

If your environment exposes YAML creation in the Applications view, use the same YAML creation path and review the following Application-view-specific behavior.

1. Open the application page in the Applications view.
2. Click Create from YAML.
3. Select the target Cluster.
4. Review the namespace declared in the YAML metadata.
5. Paste or edit the YAML content.
6. Review the visible metadata and validation result.
7. Click Create.

#Understand YAML validation and consistency

When you create an application from YAML in the Applications view:

• The selected cluster determines the project context used by the workflow.
• The workflow does not forcibly overwrite the namespace declared in the YAML.
• Namespace validation follows the namespace declared in the YAML and standard Kubernetes rules for namespaced resources.
• YAML validation confirms that the content can be parsed and accepted by the workflow before submission.
• If the declared namespace does not exist or you do not have permission to use it, the submission returns an explicit error.
• Successful validation does not guarantee that runtime dependencies are already satisfied.

If your YAML contains multiple resources, make sure each resource declares the intended namespace explicitly when the resource is namespace-scoped.

#Review points before submission

Before clicking Create, confirm that:

• The namespace declared in the YAML is the namespace where you intend to create the resource.
• The declared namespace already exists, and your current identity has permission to create resources in that namespace.
• The image source is reachable from the selected cluster.
• Referenced ConfigMaps, Secrets, services, PVCs, and other dependencies either already exist or are included consistently in the submitted YAML.
• Labels, selectors, ports, and environment settings remain internally consistent across all submitted objects.
• The YAML does not unintentionally conflict with an existing object that has the same identity in the declared namespace.
• Any scheduling constraints still match the target cluster, especially in mixed-architecture environments.

When you submit multiple related resources together, review not only each object individually but also the relationships between workloads, Services, configuration objects, and storage references.

# webapp-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  labels:
    app: webapp
    env: prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
        tier: frontend
    spec:
      containers:
      - name: webapp
        image: nginx:1.25-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "250m"
            memory: "256Mi"
---
# webapp-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP