Deploying your first application

What this is

How to get an application running on your cluster. There are three routes and they all end at the same place, so pick the one that matches how your team already works.

Before you start

You need a provisioned cluster. See Creating your first cluster.

You also need a container image. Today images are pulled from Docker Hub, so your image needs to be available there. ByteDC has built a Harbor registry which is intended to become the internal registry later, but it is not the path to use right now.

If you have never containerised your application, that work comes first: build the application into a container image and push it to Docker Hub, then come back here. Kubernetes runs images, so there is no route that skips this step.

Helm charts are not connected yet, so a Helm based install is not available today.

Route 1: the portal deployment form

The simplest path, and the right one for your first deployment.

Step 1. Open your cluster in the portal.

Step 2. Choose the deployment option.

Step 3. Give the deployment a name. A short service name such as web001 works well.

Step 4. Provide your application. You can paste your own application code, or start from a basic default image if you just want to prove the cluster works before involving your real application.

Step 5. Deploy, and wait for the pod to start.

Screenshot needed: portal deployment form completed.

Route 2: Headlamp

Headlamp is the Kubernetes user interface available on the platform. Use it when you want to see and manipulate Kubernetes objects directly rather than through the portal's simplified form.

Open Headlamp from the portal and deploy from there. Your view is scoped to your namespace, so you see your own resources and not other tenants'.

Screenshot needed: Headlamp interface showing a deployment.

Route 3: your own kubeconfig

Use this when you already have Kubernetes tooling, a CI pipeline, or scripts you want to keep using.

Step 1. Download the kubeconfig from the portal.

Step 2. Point your local Kubernetes client at that kubeconfig.

Step 3. Deploy using your normal process.

Screenshot needed: kubeconfig download in the portal.

Treat the kubeconfig as a credential. It grants access to your namespace, so store it the way you would store a password and do not commit it to a repository.

What you should see when it works

Whichever route you took, the result is the same:

• Your pod is listed and running

• You can see scale up and scale down controls for it

• The cluster now reports consumption where it previously showed zero

• If your application exposes a port, it has a public endpoint you can open

Screenshot needed: running pod with a public endpoint and scale controls.

A small application such as Nginx is a good first test, because it starts quickly and confirms the whole path works end to end before you introduce your own code.

Common problems

The pod will not start and keeps restarting. This is nearly always the image or the application rather than the cluster. Read the container logs, because a container that is stopping repeatedly reports why. See Reading logs and events to debug your app.

The image cannot be pulled. Confirm the image exists on Docker Hub and that the name and tag are exactly right. Private images need credentials, so start with a public image to prove the path.

I want to use a Helm chart. Not available yet. Helm charts are not connected on the platform today, so deploy the image directly.

I want to run commands inside the cluster from a terminal. There is no terminal access. The intended model is to build and deploy your application as an image, then let Kubernetes run that image. See Proof of concept limits and what changes in production.

My deployment worked but the application is not reachable. Confirm your application listens on the port you exposed. If you are trying to reach one of your own services from another, see Connecting two applications inside your cluster.