#Creating applications from Image

#Prerequisites

Obtain the image address. The source of the images can be from the image repository integrated by the platform administrator through the toolchain or from third-party platforms' image repositories.

• For the former, the Administrator typically assigns the image repository to your project, and you can use the images within it. If the required image repository is not found, please contact the Administrator for allocation.

• If it is a third-party platform's image repository, ensure that images can be pulled directly from it in the current cluster.

#Procedure 1 - Workloads

1. Container Platform, navigate to Applications > Applications in the left sidebar.

2. Click Create.

3. Choose Create from Image as the creation approach.

4. Select or Input an image, and click Confirm.

6. Refer to the following instructions to configure the related parameters.

#Workload 1 - Configure Basic Info

In the Workload > Basic Info section, configure declarative parameters for workloads

Parameters	Description
Model	Select a workload as needed: Deployment: For detailed parameter descriptions, please refer to Creating Deployment. DaemonSet: For detailed parameter descriptions, please refer to Creating DaemonSet. StatefulSet: For detailed parameter descriptions, please refer to Creating StatefulSet.
Replicas	Defines the desired number of Pod replicas in the Deployment (default: 1). Adjust based on workload requirements.
More > Update Strategy	Configures the rollingUpdate strategy for zero-downtime deployments: Max surge (maxSurge): Maximum number of Pods that can exceed the desired replica count during an update. Accepts absolute values (e.g., 2) or percentages (e.g., 20%). Percentage calculation: ceil(current_replicas × percentage). Example: 4.1 → 5 when calculated from 10 replicas. Max unavailable (maxUnavailable): Maximum number of Pods that can be temporarily unavailable during an update. Percentage values cannot exceed 100%. Percentage calculation: floor(current_replicas × percentage). Example: 4.9 → 4 when calculated from 10 replicas. Notes: 1. Default values: maxSurge=1, maxUnavailable=1 if not explicitly set. 2. Non-running Pods (e.g., in Pending/CrashLoopBackOff states) are considered unavailable. 3. Simultaneous constraints: maxSurge and maxUnavailable cannot both be 0 or 0%. If percentage values resolve to 0 for both parameters, Kubernetes forces maxUnavailable=1 to ensure update progress. Example: For a Deployment with 10 replicas: maxSurge=2 → Total Pods during update: 10 + 2 = 12. maxUnavailable=3 → Minimum available Pods: 10 - 3 = 7. This ensures availability while allowing controlled rollout.

#Workload 2 - Configure Pod

Note: In mixed-architecture clusters deploying single-architecture images, ensure proper Node Affinity Rules are configured for Pod scheduling.

1. Pod section, configure container runtime parameters and lifecycle management:

   Parameters	Description
   Volumes	Mount persistent volumes to containers. Supported volume types include PVC, ConfigMap, Secret,emptyDir, hostPath, and so on. For implementation details, see Storage Volume Mounting Instructions.
   Image Credential	Required only when pulling images from third-party registries (via manual image URL input). Note: Images from the platform's integrated registry automatically inherit associated secrets.
   More > Close Grace Period	Duration (default: 30s) allowed for a Pod to complete graceful shutdown after receiving termination signal. - During this period, the Pod completes inflight requests and releases resources. - Setting 0 forces immediate deletion (SIGKILL), which may cause request interruptions.

2. Node Affinity Rules

   Parameters	Description
   More > Node Selector	Constrain Pods to nodes with specific labels (e.g., kubernetes.io/os: linux).
   More > Affinity	Define fine-grained scheduling rules based on existing Pods: Pod Affinity Types: Inter-Pod Affinity: Schedule new Pods to nodes hosting specific Pods (same topology domain). Inter-Pod Anti-affinity: Prevent co-location of new Pods with specific Pods. Enforcement Modes: RequiredDuringSchedulingIgnoredDuringExecution: Pods are scheduled only if rules are satisfied. PreferredDuringSchedulingIgnoredDuringExecution: Prioritize nodes meeting rules, but allow exceptions. Configuration Fields: topologyKey: Node label defining topology domains (default: kubernetes.io/hostname). labelSelector: Filters target Pods using label queries.

3. Network Configuration

   • Kube-OVN

     Parameters	Description
     Bandwidth Limits	Enforce QoS for Pod network traffic: Egress rate limit: Maximum outbound traffic rate (e.g., 10Mbps). Ingress rate limit: Maximum inbound traffic rate.
     Subnet	Assign IPs from a predefined subnet pool. If unspecified, uses the namespace's default subnet.
     Static IP Address	Bind persistent IP addresses to Pods: Multiple Pods across Deployments can claim the same IP, but only one Pod can use it concurrently. Critical: Number of static IPs must ≥ Pod replica count.

   • Calico

     Parameters	Description
     Static IP Address	Assign fixed IPs with strict uniqueness: Each IP can be bound to only one Pod in the cluster. Critical: Static IP count must ≥ Pod replica count.

#Workload 3 - Configure Containers

1. Container section, refer to the following instructions to configure the relevant information.

   Parameters	Description
   Resource Requests & Limits	Requests: Minimum CPU/memory required for container operation. Limits: Maximum CPU/memory allowed during container execution. For unit definitions, see Resource Units. Namespace overcommit ratio: Without overcommit ratio: If namespace resource quotas exist: Container requests/limits inherit namespace defaults (modifiable). No namespace quotas: No defaults; custom Request. With overcommit ratio: Requests auto-calculated as Limits / Overcommit ratio (immutable). Constraints: Request ≤ Limit ≤ Namespace quota maximum. Overcommit ratio changes require pod recreation to take effect. Overcommit ratio disables manual request configuration. No namespace quotas → no container resource constraints.
   Extended Resources	Configure cluster-available extended resources (e.g., vGPU, pGPU).
   Volume Mount	Persistent storage configuration. See Storage Volume Mounting Instructions. Operations: Existing pod volumes: Click Add No pod volumes: Click Add & Mount Parameters: mountPath: Container filesystem path (e.g., /data) subPath: Relative file/directory path within volume. For ConfigMap/Secret: Select specific key readOnly: Mount as read-only (default: read-write) See Kubernetes Volumes.
   Port	Expose container ports. Example: Expose TCP port 6379 with name redis. Fields: protocol: TCP/UDP Port: Exposed port (e.g., 6379) name: DNS-compliant identifier (e.g., redis)
   Startup Commands & Arguments	Override default ENTRYPOINT/CMD: Example 1: Execute top -b - Command: ["top", "-b"] - OR Command: ["top"], Args: ["-b"] Example 2: Output $MESSAGE: /bin/sh -c "while true; do echo $(MESSAGE); sleep 10; done" See Defining Commands.
   More > Environment Variables	Static values: Direct key-value pairs Dynamic values: Reference ConfigMap/Secret keys, pod fields (fieldRef), resource metrics (resourceFieldRef) Note: Env variables override image/configuration file settings.
   More > Referenced ConfigMap	Inject entire ConfigMap/Secret as env variables. Supported Secret types: Opaque, kubernetes.io/basic-auth.
   More > Health Checks	Liveness Probe: Detect container health (restart if failing) Readiness Probe: Detect service availability (remove from endpoints if failing) See Health Check Parameters.
   More > Log File	Configure log paths: - Default: Collect stdout - File patterns: e.g., /var/log/*.log Requirements: Storage driver overlay2: Supported by default devicemapper: Manually mount EmptyDir to log directory Windows nodes: Ensure parent directory is mounted (e.g., c:/a for c:/a/b/c/*.log)
   More > Exclude Log File	Exclude specific logs from collection (e.g., /var/log/aaa.log).
   More > Execute before Stopping	Execute commands before container termination. Example: echo "stop" Note: Command execution time must be shorter than pod's terminationGracePeriodSeconds.

2. Click Add Container (upper right) OR Add Init Container.

   See Init Containers. Init Container:

   1. Start before app containers (sequential execution).
   2. Release resources after completion.
   3. Deletion allowed when:
      • Pod has >1 app container AND ≥1 init container.
      • Not allowed for single-app-container pods.

3. Click Create.

#Procedure 2 - Services

Parameters

Description

Service

Kubernetes Service, expose an application running in your cluster behind a single outward-facing endpoint, even when the workload is split across multiple backends.. For specific parameter explanations, please refer to Creating Services. Note The default name prefix for the internal routing created under the application is the name of the compute component. If the compute component type (deployment mode) is StatefulSet, it is advisable not to change the default name of the internal routing (the name of the workload); otherwise, it may lead to accessibility issues for the workload.

#Procedure 3 - Ingress

Parameters

Description

Ingress

Kubernetes Ingress, make your HTTP (or HTTPS) network service available using a protocol-aware configuration mechanism, that understands web concepts like URIs, hostnames, paths, and more. The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API. For detailed parameter descriptions, please refer to Creating Ingresses. Note: The Service used when creating Ingress under the application must be resources created under the current application. However, ensure that the Service is associated with the workload under the application; otherwise, service discovery and access for workload will fail.

7. Click Create.

#Application Management Operations

To modify application configurations, use one of the following methods:

1. Click the vertical ellipsis (⋮) on the right side of the application list.
2. Select Actions from the upper-right corner of the application details page.

Operation	Description
Update	Update: Modifies only the target workload using its defined update strategy (Deployment strategy shown as example). Preserves existing replica count and rollout configuration. Force Update: Triggers full application rollout using each component's update strategy. 1. Use cases: Batch configuration changes requiring immediate cluster-wide propagation (e.g., ConfigMap/Secret updates referenced as environment variables). Coordinated component restarts for critical security. 2. Warning Caution: May cause temporary service degradation during mass restarts. Not recommended for production environments without business continuity validation. Network Implications: Ingress Rule Deletion: External access remains available via LB_IP:NodePort if: 1) LoadBalancer Service uses default ports. 2) Surviving routing rules reference application components. Full external access termination requires Service deletion. Service Deletion: Irreversible loss of network connectivity to application components. Associated Ingress rules become non-functional despite API object persistence.
Delete	Cascading Deletion: 1. Removes all child resources including Deployments, Services, and Ingress rules. 2. Persistent Volume Claims (PVCs) follow retention policy defined in StorageClass Pre-deletion Checklist: 1. Verify no active traffic through associated Services. 2. Confirm data backup completion for stateful components. 3. Check dependent resource relationships using kubectl describe ownerReferences.

#Reference Information​

#Storage Volume Mounting Instructions

Type	Purpose
Persistent Volume Claim	Binds an existing PVC to request persistent storage. Note: Only bound PVCs (with associated PV) are selectable. Unbound PVCs will cause pod creation failures.
ConfigMap	Mounts full/partial ConfigMap data as files: Full ConfigMap: Creates files named after keys under mount path Subpath selection: Mount specific key (e.g., my.cnf)
Secret	Mounts full/partial Secret data as files: Full Secret: Creates files named after keys under mount path Subpath selection: Mount specific key (e.g., tls.crt)
Ephemeral Volumes	Cluster-provisioned temporary volume with features: Dynamic provisioning Lifecycle tied to pod Supports declarative configuration Use Case: Temporary data storage. See PVC
Empty Directory	phemeral storage sharing between containers in same pod: - Created on node when pod starts - Deleted with pod removal Use Case: Inter-container file sharing, temporary data storage.
Host Path	Mounts host machine directory (must start with /, e.g., /volumepath).

#Health Check Parameters

#Common Parameters

Parameters	Description
Initial Delay	Grace period (seconds) before starting probes. Default: 300.
Period	Probe interval (1-120s). Default: 60.
Timeout	Probe timeout duration (1-300s). Default: 30.
Success Threshold	Minimum consecutive successes to mark healthy. Default: 0.
Failure Threshold	Maximum consecutive failures to trigger action: - 0: Disables failure-based actions - Default: 5 failures → container restart.

#Protocol-Specific Parameters

Parameter	Applicable Protocols	Description
Protocol	HTTP/HTTPS	Health check protocol
Port	HTTP/HTTPS/TCP	Target container port for probing.
Path	HTTP/HTTPS	Endpoint path (e.g., /healthz).
HTTP Headers	HTTP/HTTPS	Custom headers (Add key-value pairs).
Command	EXEC	Container-executable check command (e.g., sh -c "curl -I localhost:8080 | grep OK"). Note: Escape special characters and test command viability.