DEV Community

Cover image for Deploying a Standalone Application 1
Rahimah Sulayman
Rahimah Sulayman

Posted on

Deploying a Standalone Application 1

Introduction

Kubernetes has a reputation for being a wall of YAML, but it doesn't have to start that way. If you’re looking for a visual, hands-on way to understand how Pods, Deployments, and Services actually interact, you’re in the right place. Today, we’re firing up the Minikube Dashboard to deploy a standalone web server with just a few clicks. By the end of this post, you won't just have an Nginx server running, you'll understand the labels and selectors that hold the entire K8s ecosystem together.

Learning Objectives

By the end of this series, you should be able to:

  • Deploy an application from the dashboard.
  • Deploy an application from a YAML file using kubectl.
  • Expose a service using NodePort.
  • Access the application from outside the Minikube cluster.

Deploying an Application Using the Dashboard (1)

Let's learn how to deploy an nginx webserver using the nginx container image from Docker Hub.

Start Minikube and verify that it is running. Run this command first:

$ minikube start

ministart

Then verify Minikube status:

$ minikube status

ministatus

Start the Minikube Dashboard. To access the Kubernetes Web IU, we need to run the following command:

$ minikube dashboard

Running this command will open up a browser with the Kubernetes Web UI, which we can use to manage containerized applications. By default, the dashboard is connected to the default Namespace. Therefore, all the operations will be performed inside the default Namespace.

dashboard
Deploying an Application - Accessing the Dashboard

NOTE: In case the browser is not opening another tab and does not display the Dashboard as expected, verify the output in your terminal as it may display a link for the Dashboard (together with some Error messages). Copy and paste that link in a new tab of your browser. Depending on your terminal's features you may be able to just click or right-click the link to open directly in the browser.

The link may look similar to:

http://127.0.0.1:40235/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Chances are that the only difference is the PORT number, which above is 40235. Your port number may be different.
After a logout/login or a reboot of your workstation the expected behavior may be observed (where the minikube dashboard command directly opens a new tab in your browser displaying the Dashboard)
.

Deploying an Application Using the Dashboard (2)

Deploy a webserver using the nginx image. From the dashboard, click on the + symbol at the top right corner of the Dashboard. That will open the create interface as seen below:

plus
Create a New Application - Interface

From there, we can create an application using valid YAML/JSON configuration data, from a definition manifest file, or manually from the Create from form tab. Click on the Create from form tab and provide the following application details:

  • The application name is web-dash.
  • The container image to use is nginx.
  • The replica count, or the number of Pods, is 1.
  • Service is External, Port 8080, Target port 80, Protocol TCP. Namespace is default

deploying

deploying

deploying

deploy
Deploy a Containerized Application - Interface

If we click on Show Advanced Options, we can specify options such as Labels, Namespace, Resource Requests, etc. By default, the Label is set to the application name. In our example k8s-app: web-dash Label is set to all objects created by this Deployment: Pods and Services (when exposed).

By clicking on the Deploy button, we trigger the deployment. As expected, the Deployment web-dash will create a ReplicaSet (web-dash-74d8bd488f), which will eventually create 1 Pod replica (web-dash-74d8bd488f-dwbzz).

NOTE: Add the full URL in the Container Image field docker.io/library/nginx if any issues are encountered with the simple nginx image name (or use the k8s.gcr.io/nginx URL if it works instead).

NOTE: The resource names are unique and are provided for illustrative purposes only. The resources in your clusters and dashboards will display different names, but the naming structure follows the same convention.

Deploying an Application Using the Dashboard (3)

Once we create the web-dash Deployment, we can use the resource navigation panel from the left side of the Dashboard to display details of Deployments, ReplicaSets, and Pods in the default Namespace.

From the Dashboard we can display individual objects’ properties by simply clicking the object’s name. From the commands menu symbol (the vertical three-dots) at the far-right we can easily manage their state. Easily scale up the Deployment to a higher number of replicas, and observe the additional Pods spin up, or scale it down to fewer replicas. Attempt to delete one of the individual Pods of the Deployment. What do you notice after a few seconds? We can even delete the Deployment, an action that results in all its Pod replicas being terminated. But for now, let’s keep the Deployment so we can analyze it further.

depore
Dashboard displaying Deployments, Pods, and ReplicaSets

The resources displayed by the Dashboard match one-to-one resources displayed from the CLI via kubectl. List the Deployments. We can list all the Deployments in the default Namespace using the kubectl get deployments command:

$ kubectl get deployments

List the ReplicaSets. We can list all the ReplicaSets in the default Namespace using the kubectl get replicasets command:

$ kubectl get replicasets

List the Pods. We can list all the Pods in the default namespace using the kubectl get pods command:

$ kubectl get pods

List Deployment, ReplicaSet and Pod with a single command:

$ kubectl get deploy,rs,po

resources

Exploring Labels and Selectors (1)

Earlier, we have seen that labels and selectors play an important role in logically grouping a subset of objects to perform operations. Let's take a closer look at them.

Display the Pod's details. We can look at an object's details using the kubectl describe command. In the following example, you can see a Pod's description:

$ kubectl describe pod web-dash-6bf994f6

describe

describe

describe

Exploring Labels and Selectors (2)

List the Pods, along with their attached Labels. With the -L option to the kubectl get pods command, we add extra columns in the output to list Pods with their attached Label keys and their values. In the following example, we are listing Pods with the Label keys k8s-app and label2:

$ kubectl get pods -L k8s-app,label2

All of the Pods are listed, as each Pod has the Label key k8s-app with value set to web-dash. We can see that in the K8S-APP column. As none of the Pods have the label2 Label key, no values are listed under the LABEL2 column.

Select the Pods with a given Label. To use a selector with the kubectl get pods command, we can use the -l option. In the following example, we are selecting all the Pods that have the k8s-app Label key set to value web-dash:

$ kubectl get pods -l k8s-app=web-dash

pods

In the example above, we listed all the Pods we created, as all of them have the k8s-app Label key set to value web-dash.

Try using k8s-app=webserver as the Selector:

$ kubectl get pods -l k8s-app=webserver

no resources
No resources found.
As expected, no Pods are listed.

Deploying an Application Using the CLI (1)

To deploy an application using the CLI, let's first delete the Deployment we created earlier.

One method to delete the Deployment we created earlier is from the Dashboard, from the Deployment’s commands menu. Another method is using the kubectl delete command. Next, we are deleting the web-dash Deployment we created earlier:

$ kubectl delete deployments web-dash

Deleting a Deployment also deletes the ReplicaSet and the Pods it created:

$ kubectl get replicasets

$ kubectl get pods

delete

Summary

In this first installment, we were able to cover the Visual Orchestration & Lifecycle Basics. We established a rock-solid foundation for managing containerized applications. We moved beyond simple container execution and began exploring the automated world of Kubernetes orchestration.

Core Competencies Achieved
Cluster Lifecycle Management:
Initiated and verified the local Kubernetes environment using minikube start and status. This confirmed the control plane, Kubelet, and API server were operational.

GUI-Driven Deployment: Leveraged the Kubernetes Dashboard to deploy a standalone Nginx application. This demonstrated the "Create from Form" workflow, which simplifies resource definition for those new to the ecosystem.

Resource Hierarchy Identification: Observed the relationship between Deployments, ReplicaSets, and Pods. We verified how a single Deployment instruction automatically handles the creation of underlying ReplicaSets to ensure the desired state of our Pods.

See you in the next part!

Top comments (0)