In the present marketing trend, Kubernetes has been adopted by various business organizations as their initial step in building scalable modern applications. To get better benefits from Kubernetes, enterprises will search for solutions that can monitor and secure Kubernetes applications. By offering continuous intelligence solutions for Kubernetes, it assists the enterprises to control and manage their Kubernetes deployments.
The dashboard is a very popular web-based user interface of Kubernetes. The Kubernetes dashboard is aided in deploying containerized applications to a Kubernetes cluster, containerized application troubleshoot, and cluster resources management. This system provides a broad view of those applications which run on the Kubernetes cluster and also assists in creating or altering the Kubernetes resources like jobs, Daemon Sets, deployment, and a lot more. For instance, a deploy wizard of Kubernetes can be utilized to scale a Deployment, initiate a rolling update, restart a pod, or deploy new applications. The cluster contains several Kubernetes resources and a dashboard assists in providing facts concerning the state of these resources and on any errors that may have occurred. The important thing to keep in mind is that by default, the Dashboard UI can’t be deployed.
Become a Kubernetes Certified professional by learning this HKR Kubernetes Training !
There are several ways of accessing the dashboard UI. You can either implement the kubectl command-line interface or access the master apiserver of Kubernetes by using a web browser.
The welcome page can be viewed by accessing the Dashboard on an empty cluster. This page contains a link to this document as well as a button to deploy your first application. Moreover, by default, you can also view the system applications which are running in the kube-system namespace of your cluster, Considering dashboard is the best example to understand.
By using a simple wizard, the dashboard assists in creating and deploying a containerized application in the form of deployment and optional service. It provides you with two options to choose from where you can manually specify application details or upload a YAML or JSON file that contains the application configuration. The right button on the welcome page is utilized for accessing the deploy wizard. To access the wizard at a later point, you can always click the create button that is present at the upper right side of the page.
Information concerning the deploy wizards are:
App name: App name is obligatory and the application must be specified with a name. The name along with a label will be added to the deployment and service and it will also be deployed. The application name has to be unique within the chosen Kubernetes namespace. It should begin with a lowercase character and end with a lowercase character or number and it must also contain only lowercase letters, dashes, and numbers limited by 24 characters. The trailing and leading spaces are ignored.
Container Image: The container image is also obligatory. The URL is part of a public Docker container image on any private image or any registry. The container image specification requires a colon at its end.
Number of pods: This is also obligatory and the number of pods that need to be focussed depends on the number of applications to be deployed. A positive value is given for the number of pods. The deployment has to be made to maintain the expected quantity of a number of pods throughout the cluster.
Service: A service is optional. A service can be exposed onto an external cluster for a few parts of an application. The external part can be a public IP address that is outside of the cluster. This is known as an external service that requires to open one or more than a single port. The services visible from the inside part of the cluster is known as internal services. While creating a service, two ports should be specified and the container listens on a port that is considered as the incoming port.
Description: The description is the text entered which is added as notations to the deployment and can also be displayed over the application.
Labels: The application name and its version are the default labels that are used for the application. You also have the great freedom to specify other labels that are to be applied to the service, deployment, and pods which will include release, environment, partition, and tier, and also release track.
Namespace: Kubernetes supports multiple virtual clusters that are also backed by the same physical cluster. The namespace is a term that is denoted for these virtual clusters which assist in partitioning the resources into logical groups. All types of namespace options are available in a drop form list of the dashboard. A namespace allows a maximum of 63 alphanumeric characters and dashes but doesn’t allow capital letters or will allow only numbers. This is because if the namespace only consists of a number, the pod will be directed into a default namespace.
Image pull secret: If the specified Docker container image is private, then it may require pull secret credentials. All available secrets are offered by the dashboard in a dropdown list and permit you to create a new secret. The secret name follows a DNS domain name syntax, for example, new.image-pull.secret. The content of a secret must be base64-encoded and specified in a .dockercfg file. The secret name may consist of a maximum of 253 characters. If the image pull secret is successfully created then it is selected by default else no secret is applied.
CPU requirement and memory requirement: You will be allowed to specify a minimum resource limit of the container provided with an option. By default, the pods will run with an unbounded memory limit and CPU.
Run as privileged: Through this option, you can find out if a privileged process is equal to the running host processes. The privileged containers possess the capabilities which can access the devices and manipulate the network stack.
Environmental variables: The Kubernetes exposes services via environment variables. You can create environment variables or can pass arguments to your command by utilizing the values of environmental variables.
Kubernetes supports the declarative configurations. All types of configurations are stored in JSON or YAML files. The file configuration is done by using API resource schemas. The application details can also be specified with another alternative method. In the scenario of deploying wizard, users are allowed to define their application in the form of a YAML or JSON file and then upload the files with the help of a dashboard.
The following sections describe views of the Kubernetes Dashboard UI; what they provide and how they can be used.
When there are Kubernetes objects defined in the cluster, the Dashboard displays them in the initial view. By default, only the default namespace objects are displayed and the namespace selector can be used to change this which is located in the navigation menu. The dashboard displays mostly the different kinds of Kubernetes objects and groups them into a few menu categories.
Overview of Admin
For cluster and namespace administrators, Dashboard lists Nodes, Namespaces, and Persistent Volumes and contains detailed views for them. Node list view contains CPU and memory usage metrics consolidated across all Nodes. The details view displays the metrics for a Node, its specification, status, allocated resources, events, and pods running on the node.
The workloads display all the applications running in the selected namespace. The view lists applications by kinds of workloads such as Deployments, Replica Sets, Stateful Sets, etc. and each workload kind can be viewed separately. The lists give you an overview of actionable information concerning the workloads, such as the number of ready pods for a Replica Set or usage of current memory for a Pod.
Detail views for workloads display the status and specification information and surface relationships between the objects. For instance, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
The services display the resources of Kubernetes which allows them to unveil the services to the external world and find them within a cluster. For that cause, Service and Ingress views display Pods focussed by them, internal endpoints for cluster connections, and external endpoints for external users.
Config Maps and Secrets
The config maps and secrets display all Kubernetes resources that are used for the live configuration of applications running in clusters. The view allows for editing and managing config objects and displays hidden secrets by default.
Pod lists and detail pages link to a logs viewer that is built into Dashboard. The viewer permits for drilling down logs from containers belonging to a single Pod.
In this section, we are going to discuss the Kubernetes Cluster UI Dashboard and the various components that are pre-deployed in your sandbox environment.
Kubernetes Dashboard UI is a web-based interface that lets you visualize the various components of the Kubernetes cluster, as well as deploy and manage Applications through containers running on Pods. It also provides the ability to view the summary about the health of various components and troubleshoot the specifications of those components.
The Kubernetes Dashboard UI comes with a vertical menu. Let us discuss the main sections in this menu.
Top 30 frequently asked Kubernetes Interview Questions !
The Cluster Overview is the landing page. It provides you the general information and the health status of the various workloads installed. Let’s discuss them.
Let us now go back to the Overview page, it will display all the Deployments, which are fundamentally the actual applications (microservices) that are deployed.
On the left side of the vertical menu, if you click on Cluster, you will discover information about the various components associated with the cluster which include namespaces, nodes, persistent volumes, roles, and storage classes. In the sections, we will discuss each of these cluster components.
CPU and memory usage
Likewise to the Overview page, you can gather the overall cluster CPU and Memory utilization:
The Namespaces offer a virtual subdomain to related resources within the cluster. For instance, namespaces can be applied to resources that are part of the same Application or to divide cluster resources among multiple users. When not defined, resources are defined as part of a default namespace. As part of this HOL, we have namespaces for the following options.
The nodes are the worker machines in Kubernetes which hold the Pods that run the Containers with the actual Applications. It is recommended to run at least two nodes across various servers, sites, or Availability Domains for High Availability. To make it clear, this HOL environment was equipped with only one worker node. However multiple worker nodes can be easily turned up and joined to the cluster.
By clicking on the Node link, you can explore more details which include:
Containers are not persistent storages, when a Pod terminates, then the state of its associated container(s) also terminates. Hence, persistent volumes are utilized to persist in the state. Persistent Volumes (PV) have an independent lifecycle to pods and can record implementation details of various types of storage, being that NFS, iSCSI, cloud-provider specific storage systems, etc. We are not using Persistent volumes in this HOL.
Kubernetes has introduced role-based access control (RBAC) in version 1.6. Kubernetes defines two resources for roles known as Role and ClusterRole. The Roles enforces policy-based Authentication, Authorization, and Accounting by isolating resources based on namespaces. For instance, we can enforce that an account for a monitoring system has only read-only access to pods in a specific namespace or across all namespaces.
Multiple roles are defined in HOL with a wide “Cluster Role” scope, this covers resources across all namespaces. Likewise, we also have defined roles with a more constraint “Role” type to resources under a specific namespace like kube-system.
A Storage Class provides the direction for administrators to describe the “classes'' of storage they offer. Various classes might map to quality-of-service levels, backup policies, or arbitrary policies determined by the cluster administrators. We are not using Storage classes in this HOL.
This section allows you to filter by specific namespaces. By default, it is set to “All namespaces”, but specific namespaces can be chosen. By doing so, all the rest of the sections will only show resources belonging to the filtered namespace.
For instance, filtering by default will let you view CPU, Memory, Pods, Deployments, etc. associated under the default namespace. This tool is used to filter by related resources, hence, it is a best practice to always associate your resources with specific namespaces.
Want to know more about Kubernetes,visit here Kubernetes Tutorial !
Various workloads have already been introduced as part of the Overview page, these include:
Daemon Sets: These are the mini processes that are chosen to run on all/some Pod(s), to handle specific actions. For instance, there are DaemonSet which ensures that:
Deployments: (View the cluster Overview as discussed earlier)
Jobs: The jobs are often used to ensure that a certain set of tasks are reliably taken up. For instance, a job can create one or more pods and ensures that a specified number of them successfully terminate. As pods successfully get completed, the job tracks the successful completions. A job is said complete when a specified number of successful completions is reached. A Job can also run multiple pods in parallel.
Pods: (View the cluster Overview as discussed earlier)
Replica Sets: (View the cluster Overview as discussed earlier)
Replication Controllers: (View the cluster Overview as discussed earlier)
Stateful Sets: These are intended to be utilized with stateful applications and distributed systems. It helps manage the deployment and scaling of a set of Pods associated with a stateful application and provides assurance concerning the order and uniqueness of these Pods. A StatefulSet maintains a sticky identity for each of their Pods as compared to Deployment. These pods are created from the same spec but are not interchangeable. Each has a persistent identifier which is maintained across any rescheduling.
The dashboard is utilized to give information concerning the state of the Kubernetes resources which is present in the cluster. They are also present on any types of error which might have occurred. The user interface of the web-based Kubernetes dashboard has many usages.
Batch starts on 1st Apr 2023, Weekend batch
Batch starts on 5th Apr 2023, Weekday batch
Batch starts on 9th Apr 2023, Weekend batch