Applications¶
The Applications service lets you deploy and manage application workloads on the Kubernetes clusters you have registered with the platform. You define a workload once as a reusable template, then instantiate it onto a single cluster or across a whole fleet of clusters. The platform rolls out the workload, tracks its status, and applies day-2 changes for you.
Key Features¶
- Two application types: Deploy a single Container image or a Helm chart.
- Templates and instances: Define a reusable application template, then deploy one or more instances from it.
- Single-cluster or fleet deployments: Target one cluster, or fan a deployment out across every cluster in a Cluster Fleet.
- Marketplace: Browse public applications and your organization's private templates from one catalog.
- Day-2 operations: Roll out new versions, override parameters, and disconnect or delete instances.
- Portable Helm charts: Use placeholders that are filled in with cluster-specific values at deployment time.
Core concepts¶
graph TD
A[Template<br/>reusable definition] -->|instantiate| B[Instance]
B --> C[Target: single Cluster]
B --> D[Target: Cluster Fleet]| Concept | What it is |
|---|---|
| Template | A reusable definition of an application — either a container image or a Helm chart — together with its configuration. Templates are versioned. |
| Instance | A running deployment created from a template, targeting a specific cluster or fleet. |
| Cluster | An application cluster — a Kubernetes cluster registered as a deployment target (see Application clusters). This is distinct from an MKS cluster. |
| Cluster Fleet | A group of application clusters that a single instance can deploy across at once. |
| Marketplace | A unified catalog combining public applications and your organization's private templates. |
Application types¶
When you create a template you choose one of two types. This is the complete set — there is no "raw Kubernetes manifest" or "arbitrary YAML" application type.
Deploy a single container image directly. You provide the image reference, optional environment variables, resource requests/limits, and how the container is exposed on the network.
Deploy a Helm chart from a chart repository. You provide the chart coordinates and override its values.
The YAML editor is for values, not manifests
The form's YAML editor edits a Helm chart's values.yaml overrides. It is not a place to paste arbitrary Kubernetes manifests, and it may be left empty.
Deploying a container¶
Image and registry¶
Provide the container image reference, for example docker.io/library/nginx:latest.
Choose whether the image comes from a Public or Private registry. For a private registry you must supply a Username and a Password / access token.
Environment variables¶
Container environment variables are simple name/value pairs. Names must be unique within the container.
No secret references
Environment variables are plain values only. There is no support for Kubernetes secret or config-map references in the container application type. Avoid placing sensitive values you would not want stored as plain configuration.
Resources¶
You can size the container with a simple slider, or switch on Advanced mode to set separate requests and limits.
| Resource | Range | Default limit | Default request |
|---|---|---|---|
| CPU | 1–16 cores | 1 |
500m |
| Memory | 512–16384 MiB | 1024Mi |
512Mi |
- Advanced CPU mode accepts cores or millicores; advanced memory uses MiB (minimum 128, in steps of 128).
- The request must be less than or equal to the limit — the form keeps this true automatically.
Conditional resources
Ephemeral storage (1–100 Gi) and GPU (1–4 devices) appear only when enabled for your environment. If you do not see these fields, they are not available to you.
Networking¶
A container can be exposed externally through one or more of three mechanisms:
| Mechanism | What it does |
|---|---|
| Load Balancer | Exposes ports through a load-balancer service with an external IP. |
| HTTP Ingress | Routes HTTP traffic by host/path. Path types: PathPrefix, Exact, RegularExpression. |
| Gateway API (HTTPRoute) | Routes traffic via the Gateway API. Deploys only on clusters that have gateway classes configured. |
Container ports default to 80/TCP. The protocol is TCP or UDP, and port numbers range 1–65535.
Public ports require the Load Balancer
Marking a port Public exposes it through a load-balancer service. You must enable the Load Balancer before you can mark any port public — otherwise the step is blocked.
Deploying a Helm chart¶
Provide the chart coordinates (all required):
- Chart Name (e.g.
wordpress) - Chart Repository URL — accepts
https://,http://,oci://,helm://, orfile://(e.g.https://charts.bitnami.com/bitnami) - Chart Version (e.g.
15.2.3)
Private chart repositories use the same Username / Password authentication as private container registries.
You can override chart values in two complementary ways:
- Editing the chart's
values.yamldirectly. - Adding
--setkey/value pairs.
Placeholders¶
Helm templates support placeholders — values that the platform fills in with cluster-specific values at deployment time, so one chart stays portable across clusters. Map a chart value key to one of:
| Placeholder | Filled in with |
|---|---|
INGRESS_HOST |
The cluster's ingress host |
INGRESS_CLASSNAME |
The cluster's ingress class name |
STORAGE_CLASS |
The cluster's storage class |
CLUSTER_CNI |
The cluster's CNI |
CLUSTER_NAME |
The target cluster's name |
APP_INSTANCE_ID |
The application instance's ID |
Note
Helm charts skip the container Resources and Networking steps — those come from the chart's own values.
Templates¶
A template is a reusable application definition. Creating one walks you through a wizard whose steps depend on the type (container vs Helm). Editing an existing template uses a tabbed view.
- A template's project cannot be changed after creation.
- Templates are versioned — you select a version when instantiating or updating an instance.
- Deleting a template is irreversible and requires typing the template name to confirm.
Publishing metadata¶
A template can carry marketplace metadata (set in the Basic Information step): icon URL, category/subcategory, tags, homepage and documentation URLs, and a changelog. New templates default to private and unlisted. URL fields must start with http:// or https://.
Marketplace¶
The Marketplace is a single catalog that combines public applications and your organization's private templates. Filter by:
- Visibility:
all,public, orprivate - Search (by name), Category / Subcategory, Package Type (Helm / Container), Tags, and Project (private only)
No ratings, install counts, sorting, or 'verified' badges
The catalog filters on the fields above only.
Public and private items behave differently when you instantiate them:
| Public application | Private template (yours) | |
|---|---|---|
| Target project | You choose the project | Locked to the template's own project |
| Edit / Delete | Read-only | Available (if you own it) |
An application's detail page shows a version selector with per-version changelog, homepage/docs links, technical details, and a status badge (active, deprecated, draft, beta).
Instances¶
An instance is a running deployment created from a template.
Choosing a target¶
When you instantiate, you pick the deployment target:
- Cluster — deploy to a single application cluster.
- Fleet — deploy across every cluster in a Cluster Fleet.
The instance name is optional; if left blank it is auto-generated. A fleet deployment supports global plus per-cluster overrides; a single-cluster deployment supports one flat set of overrides.
Day-2 operations¶
| Operation | What it does |
|---|---|
| Update version | Performs a rolling update to a newer template version. Only versions newer than the deployed one are offered; if you are already on the latest, none are shown. |
| Edit parameters | Applies overrides — environment-variable overrides for containers, or Helm --set / values.yaml overrides for Helm. |
| Sync | Re-runs the deployment to retry or reconcile it. |
Disconnect vs Delete¶
These are two different destructive actions. Read this before clicking either.
| Disconnect | Delete | |
|---|---|---|
| Effect on the platform | Removes the instance from platform management | Permanently deletes the instance |
| Effect on the workload | Workloads keep running in the cluster — nothing is removed | All resources are destroyed, running apps are stopped, data is lost |
| Cleanup | You may need to clean up cluster resources manually | Handled by the platform |
| Reversible | No | No |
Both require confirmation; error-state instances can only be deleted
Both actions require typing the instance ID to confirm. An instance in the error status cannot be disconnected — it can only be deleted. Disconnect is most useful when the cluster is no longer reachable and a normal deletion is not possible.
Lifecycle states¶
Instances report a status (pending, creating, active, error, deleting, detaching) and a separate readiness indicator. Actions are disabled while an instance is creating or deleting, and for users who are not its owner.
Finding your app's address
Connection details (external IP, ports, ingress hosts) are shown on an instance's detail page.
Application clusters¶
An application cluster is a Kubernetes cluster registered as a target for application deployments. It is not the same thing as an MKS cluster:
| Application cluster | MKS cluster | |
|---|---|---|
| What it is | A deploy target for applications | A Kubernetes cluster the platform provisions for you |
| How you add it | Register it with a kubeconfig | Provision it from your infrastructure |
| Where it lives | Applications | Managed Services → Kubernetes |
You deploy applications to application clusters, not directly to MKS clusters.
Importing an MKS cluster¶
You can register an existing MKS cluster as an application cluster. The Import MKS cluster action connects to the MKS cluster for you, so you do not have to supply a kubeconfig manually. During import you can optionally enable a Load Balancer, an Ingress class (class name, base host, annotations), and a map location.
Configurable resources¶
When registering an application cluster you can configure:
- Load Balancer
- Ingress classes — class name, base host, annotations (if ingress is enabled, a base host is required)
- Gateway classes — gateway name, namespace, base hostname, default flag (if a gateway is enabled, a gateway name and base hostname are required)
- Storage solutions — type, access modes, default flag
Cluster Fleets¶
A Cluster Fleet groups application clusters so that a single instance can be deployed across all of them at once. A fleet has a provider and an optional geographic location, shown on a world map.
- Creating a fleet requires only a name and a project; provider and location are optional.
- Clusters are added to or removed from a fleet individually, or replaced in bulk. A cluster must be in the same project as the fleet.
Fleet instances¶
A fleet instance is an application instance deployed across a fleet. It tracks, per cluster, a deployment plus an overall rollout summary (deploying / failed / pending / succeeded / total), and supports per-cluster configuration overrides.
Like single-cluster instances, deleting a fleet instance offers a detach (disconnect-only) mode that stops platform management without removing the deployed workloads, in addition to a full delete.
Getting Started¶
To deploy your first application, navigate to the Applications section in the platform dashboard:
- Make sure you have at least one application cluster registered as a target (you can import an existing MKS cluster).
- Create a template — choose Container or Helm and complete the wizard.
- Instantiate the template onto a cluster or fleet.
For the Kubernetes clusters that back your deployments, see the Managed Kubernetes Service guide.