Alauda Container Platform

Creating applications from Image

TOC

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.

INFO

Note: When using images from the image repository integrated into web console, you can filter images by Already Integrated. The Integration Project Name, for example, images (registry-projectname), which includes the project name projectname in this web console and the project name containers in the image repository.

When using images from a private registry, you need to configure the corresponding image pull secret. For more information, see Add ImagePullSecrets to ServiceAccount.

  1. 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

ParametersDescription
ModelSelect a workload as needed:
ReplicasDefines the desired number of Pod replicas in the Deployment (default: 1). Adjust based on workload requirements.
More > Update StrategyConfigures 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:

    ParametersDescription
    VolumesMount 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 CredentialRequired 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 PeriodDuration (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.
  1. Node Affinity Rules
ParametersDescription
More > Node SelectorConstrain Pods to nodes with specific labels (e.g., kubernetes.io/os: linux).
Node OS Selector
More > AffinityDefine 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.
  1. Network Configuration
    • Kube-OVN
      ParametersDescription
      Bandwidth LimitsEnforce QoS for Pod network traffic:
      • Egress rate limit: Maximum outbound traffic rate (e.g., 10Mbps).
      • Ingress rate limit: Maximum inbound traffic rate.
      SubnetAssign IPs from a predefined subnet pool. If unspecified, uses the namespace's default subnet.
      Static IP AddressBind 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
      ParametersDescription
      Static IP AddressAssign 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.

    ParametersDescription
    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 ResourcesConfigure cluster-available extended resources (e.g., vGPU, pGPU).
    Volume MountPersistent 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.
    PortExpose 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 & ArgumentsOverride 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 ConfigMapInject 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 FileConfigure 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 FileExclude specific logs from collection (e.g., /var/log/aaa.log).
    More > Execute before StoppingExecute 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

ParametersDescription
ServiceKubernetes 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

ParametersDescription
IngressKubernetes 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.
  1. 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.
OperationDescription
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

TypePurpose
Persistent Volume ClaimBinds an existing PVC to request persistent storage.

Note: Only bound PVCs (with associated PV) are selectable. Unbound PVCs will cause pod creation failures.
ConfigMapMounts 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)
SecretMounts 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 VolumesCluster-provisioned temporary volume with features:
  • Dynamic provisioning
  • Lifecycle tied to pod
  • Supports declarative configuration

Use Case: Temporary data storage. See Ephemeral Volumes
Empty DirectoryEphemeral 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. See EmptyDir
Host PathMounts host machine directory (must start with /, e.g., /volumepath).

Health Check Parameters

Common Parameters

ParametersDescription
Initial DelayGrace period (seconds) before starting probes. Default: 300.
PeriodProbe interval (1-120s). Default: 60.
TimeoutProbe timeout duration (1-300s). Default: 30.
Success ThresholdMinimum consecutive successes to mark healthy. Default: 0.
Failure ThresholdMaximum consecutive failures to trigger action:
- 0: Disables failure-based actions
- Default: 5 failures → container restart.

Protocol-Specific Parameters

ParameterApplicable ProtocolsDescription
ProtocolHTTP/HTTPSHealth check protocol
PortHTTP/HTTPS/TCPTarget container port for probing.
PathHTTP/HTTPSEndpoint path (e.g., /healthz).
HTTP HeadersHTTP/HTTPSCustom headers (Add key-value pairs).
CommandEXECContainer-executable check command (e.g., sh -c "curl -I localhost:8080 | grep OK").
Note: Escape special characters and test command viability.