Kubernetes Dashboard

The Dashboard can be defined as a web-based user interface of Kubernetes. We can use the dashboard for deploying containerized applications to any Kubernetes cluster, manage the resources of the cluster, and troubleshoot our containerized applications.

We can use the dashboard for getting the application's overview running on our cluster. We can also create or modify individual resources of Kubernetes (including DaemonSets, Jobs, Deployments, etc.). For example, we can initiate the rolling update, scale the deployments, restart any pod, or expand a newer application with the help of the deploy wizard.

The dashboard also facilitates information about the Kubernetes resource state in our cluster and on the error that might have appeared.

Dashboard UI Deployment

By default, the Dashboard UI isn't deployed. Run the below command for deploying it:
kubectl apply https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

Accessing the Dashboard UI

By default, the dashboard expands with fewer RBAC configuration for protecting our data. The Dashboard currently only supports logging in along with the Bearer token.

Command-line proxy

We can access the Kubernetes Dashboard with the help of a tool known as kubectl command-line by executing a command mentioned below:

The UI can be accessed through a machine only in which the command is run.

Note: Kubeconfig Authentication technique doesn't support x509 certificate-based authentication or outer identity providers.

Welcome View

If we access Dashboard over any empty cluster, a welcome page may appear. It has the link to the document and also the button for deploying our first application. We can consider by default that the applications of the system are executing within the kube-system namespace of our cluster such as Dashboard itself.

Expanding Containerized Applications

The Dashboard enables us to create and expand the containerized applications as the Deployment and alternative Service with a general wizard. We can either upload a JSON or YAML file including application configuration or specify details of an application manually.
Press the button, i.e., CREATE in the right upper corner of a page to start.

Specifying Application Information

The deploy wizard supposes that we facilitate the below details:

• App name (essential): Name for our application. A label along with a name will be included in the Service and Deployment will be deployed.
  An application name should be specific in the chosen Kubernetes namespace. It should begin with the lowercase character, and it will be ended with the lowercase number or a character. It also includes lowercase letters, dashes, and numbers only. It is restricted to up to 24 characters. Trailing and leading spaces are avoided.
• Container image (essential): Any URL of the public Docker container image over a private image or registry (hosted commonly on a Docker Hub or Google Container Registry). The specification of a container image must be ended with the colon.
• Pods number (essential): The pod's target number we wish our application to be expanded in. The value should be any positive digit.
  A Deployment will be made for maintaining the pod desired number around our cluster.
• Service (optional): We may wish to expose any Service to a public or maybe external IP address outer to our cluster (outside Service) for a few parts of our application (such as for frontends).
  Other services that are visible only in the cluster are known as internal Services.
  If we choose to make any Service and our container listens over an incoming port then we need to describe two ports irrespective of various Service types. The Service will be made for mapping the incoming port to a target port noticed by a container. The Service will be routed to our deployed Pods. Some of the supported protocols include UDP and TCP. The internal name of DNS for the Service will be that value we specified as an application name above.

Note: We may require to open-up multiple ports for doing so for some of the external Services.

If required, we can deploy the Advance options section in which we can describe several settings:

• Description: Here, the text we enter will be specified as the annotation to Deployment and appears in the details of the application.
• Labels: Various default labels to be applied for our application are the version and name of the application. We can specify several other additional labels to be used for the Services (if any), Deployment, and Pods like release track, partition, tier, environment, and release.
  For example,
  release=1.0
  tier=frontend
  environment=pod
  track=stable
• Image Pull Secret: In the specified condition, the defined Docker container is secret. It may require pulling secret recommendations.
  The dashboard provides all possible secrets within the drop-down list. It allows us to make new secrets. A secret name should follow the syntax of the DNS domain name, for example, new.image-pull.secret. The secret content should be specified inside the .dockercfg file and base64-based. This secret name might contain a maximum of 253 characters.
  When the image pull secret creation is successful, then it is by default selected. When the failure of creation occurs, no secrets will be applied.
• Namespace: Kubernetes provides its support for more than one virtual cluster approved by a similar physical cluster. These types of virtual clusters are known as namespaces. They enable us to partition resources into named groups logically.
  The dashboard provides all possible namespaces within the drop-down list. It allows us to make new namespaces. A namespace name may include a maximum of 63 alphanumerical numbers and dashes but can't include capital letters.
  The namespace names must not combine numbers only. If a name is fixed as any number, like 10, then the pod will be set in a default namespace.
  When the namespace creation is successful, it is selected by default. When the failure of creation occurs, the initial namespace will be selected.
• Memory requirement (MiB) and CPU requirement (cores): We can define the resource limits for a container. Pods execute with unbounded memory and CPU limits by default.
• Run command arguments and Run command: Our containers execute the default entry point command of the Docker image by default. We can apply the command arguments and options for overriding the default.
• Environment variables: Kubernetes discloses Services by environment variables. We can pass arguments and construct environment variables to our commands with the help of the environment variable values. They could be used inside the applications for finding the Service. Using a syntax, i.e., $(VAR_NAME) values could reference many other variables.
• Run as privileged: It regulates whether processes in the privileged containers are equal to those processes executing as root over the host. The privileged containers could make use of abilities like accessing devices and managing the network stack.

Uploading a JSON or YAML file

Kubernetes provides support for declarative configuration. All configurations are stored in JSON or YAML configuration files with the help of the resource schemes of Kubernetes API in this style.
We can define our application in JSON or YAML files and upload these files with the help of the dashboard as a substitute for specifying the details of an application in a deploy wizard.

Using Dashboard

The following key points specify the Kubernetes Dashboard UI view; how could they be applied and what they offer:

Navigation

The dashboard illustrates it in the starting view if there are any Kubernetes objects specified in the cluster. Only objects through the default namespace can be displayed and it could be modified using a namespace selector positioned in the navigation menu.
The dashboard illustrates most kinds of Kubernetes objects and collects them in some menu categories.

Overview of Admin

The detail view displays the metrics for any Node, its status, specification, pods, events, and allocated resources executing on the node.

Workloads

It displays all applications executing in a selected namespace. The applications that are listed using view via workload kind (such as Stateful Sets, Replica Sets, Deployments, etc.) and all workload kinds could be separately viewed.

Services

Services illustrate Kubernetes resources that permit to expose the services to the outer world and hiding them in the cluster.

Storage

The view of the storage illustrates Persistent Volume Claim capabilities which are applied by the applications to store information.

Congif Secrets and Maps

These are used to illustrate every Kubernetes resource that is applied for the application's live configuration running inside the cluster. The view permits for managing and editing config objects and shows secrets by default undisclosed.

Logs viewer

Detail pages and pod lists link to the logs viewer. It is created into the dashboard. This viewer permits to drill down the logs through the containers residing to an individual Pod.