Forem: Prashant Ghildiyal

7 Tools To Make Kubernetes Management Easy

Prashant Ghildiyal — Mon, 13 Jun 2022 13:29:47 +0000

In the emerging Cloud-Native environment, Kubernetes is everywhere without any question. It has become the standard for orchestrating containers. But managing multiple Kubernetes clusters presents a new set of challenges. Let’s explore some of the popular tools to manage Kubernetes efficiently.

1. Kube-Prometheus-Stack

Prometheus is an open source tool used for metrics-based tool used for monitoring and alerting. Kube-Prometheus-Stack is a collection of kubernetes manifests, Prometheus rules and Grafana dashboards combined with documentation and scripts to provide easy to operate end-to-end kubernetes cluster monitoring with Prometheus using the Prometheus operator. As it includes both Prometheus operator and Grafana dashboards, there is no need to set them up separately.

Installation

In order to install Prometheus Stack, you must follow these steps:

Create the namespace for Prometheus Stack:

 kubectl create namespace prometheus

Add the prometheus-community Helm repository:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

Update your local Helm chart repository cache:

helm repo update

To install the kube-prometheus-stack Helm chart in latest version:

helm install prometheus prometheus-community/kube-prometheus-stack --namespace=prometheus

To install the kube-prometheus-stack Helm chart in specific version :

helm install prometheus prometheus-community/kube-prometheus-stack --namespace=prometheus --version=<version>

2. Karpenter

Karpenter is an open-source, flexible, high-performance Kubernetes cluster autoscaler built with AWS that improves resource utilization and application availability. It observes the pod resource request of unscheduled pods and launches right-sized Amazon EC2 instances based on the needs of workloads of a cluster such as acceleration, compute, scheduling requirements, and storage.

Why Karpenter ?

Karpenter can provision new EC2 instances and schedule the Kubernetes pods within a minute.
With minimal infrastructural and configuration overhead, Karpenter dynamically selects the EC2 instance types that are best suited to what is needed by Kubernetes pods.
Karpenter can work with Kubernetes cluster based on any environment or cloud.

Installation

Install Karpenter in the Kubernetes cluster using Helm charts. But before doing this, you must ensure that there is enough compute capacity available. Karpenter requires permissions to provision compute resources that are based on the cloud provider you have chosen. Please follow this link for installation.

3. Devtron

Devtron is an open source software delivery workflow for Kubernetes written in go. It is designed as a self-serve platform for operationalizing and maintaining applications (AppOps) on Kubernetes in a developer friendly way.

Some of the amazing features that Devtron provides are:

Zero code software delivery workflow
Multi cloud deployment
Easy DevSecOps integration
Application debugging dashboard
Enterprise Grade security and compliances
GitOps aware

To know more about devtron, please visit here.

Installation (Using Helm3)

Follow the steps mentioned below :

helm repo add devtron https://helm.devtron.ai

helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd

kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}'

The command given above will show status of installation. It will print Downloaded If the installation is in progress and Applied if installation is completed.

kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'

kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}' | base64 -d

To check the devtron installation steps in detail, please visit here.

4. KEDA

KEDA is a Kubernetes-based Event Driven Autoscaler. With KEDA, we can scale any container in Kubernetes based on the events. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).

Installing KEDA (using helm)

Add helm repo:

helm repo add kedacore https://kedacore.github.io/charts

Update Helm repo:

helm repo update

Install keda helm chart

Helm 2

helm install kedacore/keda --namespace keda --version 1.4.2 --name keda

Helm 3

kubectl create namespace keda helm install keda kedacore/keda --version 1.4.2 --namespace keda

5. Silver Surfer

Currently there is no easy way to upgrade kubernetes objects in case of kubernetes upgrade. It's a tedious task to know whether the current ApiVersion of the Object is Removed, Deprecated or Unchanged. It provides details of issues with the kubernetes object in case they are migrated to cluster with newer kubernetes version.

Installation

Just with few commands, it's ready to serve your cluster.

git clone https://github.com/devtron-labs/silver-surfer.git
cd silver-surfer
go mod vendor
go mod download
make

It's done. A bin directory might have created with the binary ready to use ./kubedd command.

It categorises kubernetes objects based on change in ApiVersion. Categories are:

Removed ApiVersion
Deprecated ApiVersion
Newer ApiVersion
Unchanged ApiVersion

Within each category it identifies migration path to newer Api Version, possible paths are:

It cannot be migrated as there are no common ApiVersions between source and target kubernetes version
It can be migrated but has some issues which need to be resolved
It can be migrated with just ApiVersion change

This activity is performed for both current and new ApiVersion.

You can check the Repo here

6. Winter Soldier

Winter soldier can be used to scale down or delete unneeded workload after work hours based on conditions. Winter Soldier is an operator which expects conditions to be defined using hibernator CRD.

It’s very often that in a kubernetes cluster, workloads remains up which are not being utilized since long or having no need anymore and increase TCO of infrastructure. Over the weekend, it’s very rare that a kubernetes cluster or workloads are being used but still it remains up. In such user-cases, we can use winter soldier. To know more about winter-soldier, please follow this link.

Installation

Please visit this link to get installation steps for winter soldier.

7. Kyverno

In kubernetes, we need to set some rules or policies and we need to do that in a way that allows everybody else to use their cluster without a high risk or destroying everybody else’s work. So, here we are going to explore a kubernetes native solution for policies and that is Kyverno. Kyverno is an open-source policy management system for kubernetes. Kyverno allows cluster administrators to validate, mutate and generate resources.

Installation

In order to install Kyverno with Helm, first add the Kyverno Helm repository:

helm repo add kyverno https://kyverno.github.io/kyverno/

Scan the new repository for charts:

helm repo update

Use Helm 3.2+ to create a Namespace and install Kyverno.

helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace

Choose any one of the tools mentioned above and try it out on your Kubernetes cluster !

Follow Devtron for all things Kubernetes, DevOps and Opensource.

Devtron Follow

Devtron is redefining the paradigm of how DevOps should be done. An open-source software delivery workflow for Kubernetes automating Release Orchestration & Life Cycle Management of Applications.

Let's Learn Kubernetes - Basics - 4

Prashant Ghildiyal — Thu, 21 Oct 2021 15:41:06 +0000

Kubernetes is a container management tool that automates the deployment, scaling, and operations of an application.

In the previous blog of 'Let's learn Kubernetes' Series, we have learnt all about Storage. We learnt about concepts like Persistent Volume & Persistent Volume Claims, Storage Classes & Dynamic provisioning of Storage Classes.

Let's Learn Kubernetes - Basics - 3

Prashant Ghildiyal ・ Oct 19 '21

#beginners #kubernetes #devops #go

Continuing with the series, this blog consists about few additional configurations that are useful/necessary. In this blog we'll give a short explanation of each concept and then post a link that explains the same in-depth.

Before diving in, it would be great if you can check out, star ⭐ our Repo - Devtron, An End-to-End Kubernetes Software Delivery Workflow, which makes the DevOps workflow flawless for Developers, DevOps Engineers.

devtron-labs / devtron

Tool integration platform for Kubernetes

Configurations

In the final blog of the Let's learn Kubernetes series, here are some of the few additional configurations that are usually used by the folks working on Kubernetes in their day-to-day routine.
The blog covers following configurations:

ConfigMaps
Secrets
Resource management
KubeConfig Files
Best practices of using Kubernetes

ConfigMaps

ConfigMaps are more like an API object that is used to store some non-confidential data in the form of key-value pairs. They contain environment variables, command line arguments which are in turn used by pods for fetching data. They also allow you to keep your configurations separate from your pods and components which helps to keep your workloads portable. It keeps their configurations easy to change and manage.

To know more about ConfigMaps you can Check out the link below:

Creating & Using ConfigMaps in Kubernetes

Secrets

Secrets store confidential information for your pods or clusters. This information can be passwords, AuthTokens , SSH keys etc.

Keeping confidential data in secrets is way more secure than defining them in Configmaps in the form plain text or in the pods specifications. It reduces the risk of exposing data to unauthorized users. Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd).

Want to know more about Secrets? Check out this article:

Introduction to Kubernetes Secrets

Resource management

As Kubernetes helps in automating the major portion of your deployments making it simple to manage the applications. Yet, these containerized applications commonly share pooled resources so the resource allocation and management should be done properly.

Here are 5 ways in which this works:

Use namespace and resource quotas
Use limit ranges
Set network policies
Don’t forget about storage when applicable
Keep things tidy API objects and monitoring

This article goes in-depth regarding Resource Management:

Managing Kubernetes resources: 5 things to remember

Kubeconfig Files

A Kubeconfig file is a file used to configure access to Kubernetes when used in conjunction with the kubectl command-line tool (or other clients). The use of this file is to organize the information about clusters, users, and namespaces. This kubectl command-line program uses the Kubeconfig file to find the information within a particular cluster by communicating with the API server of that cluster.

By default, kubectl looks for a file named config in the $HOME/.kube directory. You can specify other Kubeconfig files by setting the KUBECONFIG environment variable or by setting the --kubeconfig flag.

The above image shows how the contexts define the information and configuration of the clusters listed in the Kubeconfig file.

To better understand the process, check out:

Article - Mastering the KUBECONFIG file
Video - 13 What are Kubeconfigs and Why Do We Need Them

Best practices of using Kubernetes

Till now, we came up with a series of blogs addressing all the basic concepts of Kubernetes. Starting from pods, controllers to networking and storage. Now at the end of this series, it is very important to understand how to use these configurations in the best possible way to keep on enhancing the cluster’s efficiency.

Following are the few best practices to realize a Kubernetes cluster model that is scalable, secured and highly optimized:

Download the latest version
Use namespaces
Maintain small container images
Set resources , requests and limits
Use readinessProbe and livenessProbe
Deploy RBAC for security
Auto scale and many more.

To get a better understanding regarding these practices check out:

Kubernetes Best Practices for Enhanced Cluster Efficiency

Finally, we come to an end of our series discussing various basic concepts that are essential to get a grip on Kubernetes. I am really glad to see a lot of positive response on the previous blogs in the series. It is always helpful, If you'd like to suggest what are the other topics you want me to write on.

Meanwhile, you can also check previous blogs in this series.

Let's Learn Kubernetes - Basics - 3

Prashant Ghildiyal — Tue, 19 Oct 2021 17:33:20 +0000

Kubernetes is a container management tool that automates the deployment, scaling, and operations of an application.
In the previous blog of 'Let's learn Kubernetes' Series, we have seen some fundamental topics such as Services, Load Balancers, ClusterIP, Nodeport, Ingress, DNS among others.

Let's Learn Kubernetes - Basics - 2

Prashant Ghildiyal ・ Oct 11 '21

#kubernetes #devops #beginners #go

Continuing with the series, this blog is all about storage in Kubernetes. In this blog we'll give a short explanation of each concept and then post a link that explains the same in-depth.

Before diving in, it would be great if you can check out, star our repo Devtron, An End-to-End Kubernetes Software Delivery Workflow, which makes the DevOps workflow flawless for Developers, DevOps Engineers.

devtron-labs / devtron

Tool integration platform for Kubernetes

Storage in Kubernetes

With the rise of Kubernetes as a method for hosting microservice-based processes, data storage is always a concern. When managing containerized environments, Kubernetes storage is useful for storage administrators, because it allows them to maintain multiple forms of persistent and non-persistent data in a Kubernetes cluster.

At a high level kubernetes uses the following types of storages described below:

Persistent Volume & Persistent Volume Claims

A PersistentVolume (PV) is a storage resource in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.

Persistent volumes are independent of the lifecycle of the pod that uses it, meaning that even if the pod shuts down, the data in the volume is not erased.In order for a Pod to start using these volumes, it must request a volume by issuing a persistent volume claim (PVC). PVCs describe the storage capacity and characteristics a pod requires, and the cluster attempts to match the request and provision the desired persistent volume.

On the other hand, A PersistentVolumeClaim (PVC) is a request sent by a Kubernetes node for storage.The claim can include specific storage parameters required by the application—for example an amount of storage, or a specific type of access (read/write, read-only, etc.).
Kubernetes looks for a PV that meets the criteria defined in the user’s PVC, and if there is one, it matches the claim to PV. This is called binding.

To know more about them checkout these listed links:

Storage Classes

Kubernetes Storage Class Objects are specified by name in Persistent Volume Claims to provision storage with a set of properties. The storage class itself identifies the provisioner that will be used and defines that set of properties in terms the provisioner understands.
Each Storage Class contains the fields provisioner, parameters, and reclaim policy, which is used when a Persistent Volume belonging to the class needs to be dynamically provisioned.

To get a detailed view regarding Storage Classes check out the listed links:

Dynamic provisioning of Storage Classes:

Kubernetes supports dynamic volume configuration, allowing you to create storage volumes on demand. Therefore, administrators do not have to manually create new storage volumes and then create a Persistent Volume object for use in the cluster.

When the user requests a specific type of storage, the entire process runs automatically. The cluster administrator defines storage class objects as needed. Each Storage Class refers to a volume plugin, also called a provisioner.

To get a more detailed view about the topic refer to the following video:

Dynamic Volume Provisioning in Kubernetes

The next blog of Let's learn Kubernetes would be the last blog of the series' Basics. If you like to learn about other significant topics in Kubernetes, you can follow the previous blogs.

Let's Learn Kubernetes - Basics - 2

Prashant Ghildiyal — Mon, 11 Oct 2021 18:43:26 +0000

Kubernetes is a container management tool that automates the deployment, scaling, and operations of an application. It has become the de facto container orchestrator, with more than 80% of companies using it in some capacity.
In the previous blog of 'Let's learn Kubernetes' Series, we have seen the basic definition of Kubernetes, pods, Nodes, controllers among others.

Let's Learn Kubernetes - Basics - 1

Prashant Ghildiyal ・ Sep 29 '21

#kubernetes #devops #beginners #go

In this series we will go a little deeper to understand concepts like services, Load balancers and others. In this we'll give a short explanation of each concept and then post a link that explains the same in-depth.

Before diving in, it would be great if you can check out our repo Devtron, End-to-End Kubernetes Software Delivery Workflow, which makes the DevOps workflow flawless for Developers, DevOps Engineers.

devtron-labs / devtron

Tool integration platform for Kubernetes

Services

Kubernetes Services enables a group of pods that provide a specific function to have a unique IP Address and a name. A Kubernetes service can be used to easily expose an application deployed on a set of pods using a single endpoint. Service is both a REST object and an abstraction that defines:

A set of pods
A policy to access them

The article discusses what are Kubernetes services, Attributes of the K8s services, Defining them and creating new services.

Kubernetes Services

Load Balancer, ClusterIP, NodePort

Load Balancer

Load balancing is a technique for distributing network traffic or client requests among many servers. The load balancer, when utilized correctly, may assist to optimise scalability and availability. This is a crucial technique that should be correctly implemented in a solution; otherwise, clients will be unable to contact the servers.

ClusterIP

Within your cluster, a ClusterIP offers network communication. It is generally inaccessible from the outside. You can utilise these services to connect your workloads inside.

NodePort

Every node in your cluster has an open port called a NodePort. Even if your application is operating on a separate node, Kubernetes transparently redirects incoming traffic on the NodePort to your service.

A Comprehensive video by Nana explaining what is Loadbalancer, ClusterIP & Nodeport and the difference between them.

You can also read a detailed article on ClusterIP here:

Working With ClusterIP Service Type In Kubernetes

Ingress

Kubernetes Ingress is an API object that provides routing rules to manage external users' access to the services in a Kubernetes cluster, typically via HTTPS/HTTP.

Below write-up gives a comprehensive look of what is Ingress and what is its uses.

What is Kubernetes Ingress?

Ingress Controller

An Ingress controller is a specialized load balancer for Kubernetes (and other containerized) environments. An Ingress controller abstracts away the complexity of Kubernetes application traffic routing and provides a bridge between Kubernetes services and external ones.

Ingress controller

Below link defines Ingress controller and what it can do.

DNS for K8s

In the Article below, it is explained how DNS can help make it easier to access services.

Kubernetes DNS for Services and Pods

I will be continuing this series to include more fundamental topics of Kubernetes under 'Let's learn Kubernetes' series title.

Let's Learn Kubernetes - Basics - 1

Prashant Ghildiyal — Wed, 29 Sep 2021 15:40:54 +0000

Building an application is one set of challenges that needs to be tackled, and once that is done, you have a series of new challenges. An Application needs to be Deployed, Scaled, and maintained across based on the demand. In recent times, the containerization of Apps has become an excellent means to help solve most of the mentioned challenges. Many solutions containerize and help manage and operationalize the application, but the most used of all the available solutions is Kubernetes.

Kubernetes is a container management tool that automates the deployment, scaling, and operations of an application. It has become the de facto container orchestrator, with more than 80% of companies using it in some capacity. Hence, it becomes essential for Novice & Expert DevOps Engineers, Developers, and Programmers to learn Kubernetes. Devtron brings you a collection of concepts and their most popular links/explanations to make a comprehensive guide understanding the basics of Kubernetes.

You can also check out Devtron, End-to-End Kubernetes Software Delivery Workflow here:

devtron-labs / devtron

Tool integration platform for Kubernetes

An Overview

Kubernetes is a portable, extensible, open-source platform for managing containerized applications and services that facilitate declarative configuration and automation. Kubernetes provides a platform to configure, automate, and manage:

Intelligent and balanced scheduling of containers
Creation, deletion, and movement of containers
Easy scaling of containers
Monitoring and self-healing abilities

In this write-up, the author discusses challenges faced using previous server-side application management tools and how Kubernetes helps tackle these challenges.

Here's why you should use Kubernetes!

Prashant Ghildiyal ・ Jun 16 '21

#kubernetes #beginners #devops #opensource

Architecture

In this article, we get to see a brief overview of the Architecture of Kubernetes and the components of the Architecture such as Master, API Scheduler, Nodes, Pods, Scheduler, among others.

A Developers Guide to Kubernetes

Pods

The Smallest Execution Unit of Kubernetes can be considered a Pod. A pod is temporary in nature, and new ones form when one dies. Pods consist of a unique IP address, Persistent storage Volumes, Configuration Information.

The below link explains all things Pods.

What are Kubernetes Pods?

Nodes & Clusters

Node is the smallest unit of Computing Hardware in a cluster. Each Node can be considered a set of CPU and RAM resources available for Kubernetes to work.
Although working with individual nodes is useful, Kubernetes combines these resources of nodes to become a cluster. Kubernetes intelligently manage the distribution of work among the worker nodes among the Cluster.
A more detailed explanation is available in the following link about Pods, Nodes, and Clusters.

Kubernetes 101: Pods, Nodes, Containers, and Clusters

Controllers

A controller is a system pod that helps in controlling the behavior of other pods. The above video gives a detailed explanation of how controllers work.

Replicasets

With Replicasets, it is possible to run a specified number of pod replicas running at all times. The link below gives a comprehensive view of Replicasets.

Kubernetes ReplicaSets: A Brief Introduction

Jobs

Kubernetes Jobs are used to creating transient pods that perform specific tasks they are assigned to.

A beginner's guide to Kubernetes Jobs and CronJobs

Schedulers

The Kubernetes Scheduler, monitoring the Object Store for unassigned Pods, will assign the Pod to a Node. Then, the Kubelet, monitoring the Object Store for assigned Pods, will execute the Pod.

The Kubernetes Scheduler

Kubernetes Deployment Made Easy

Prashant Ghildiyal — Tue, 03 Aug 2021 15:40:49 +0000

You can check out our dashboard and Opensource repo here:

devtron-labs / devtron

Software Delivery Workflow For Kubernetes

The world is changing, and the pandemic accelerated organisational transformation. The challenge is no longer capturing the largest share of voice, but disruptive sustainable growth - delicately balanced on the three fundamental principles of cost, security, and stability! Devtron Labs not only balances the three principles effectively but provide the solution in an OpenSource environment

On July 24th, One of our contributors, Prakarsh from Devtron Labs curated a session at the AWS UG OSTech Conference 2021 organized by AWS User Group, Jaipur. With over ten years of professional experience, Prakarsh now holds the position of a kubernetes solution architect at Devtron. He discussed how Devtron makes kubernetes deployment extremely smooth.

Devtron: The Inception

While there were many solutions in the Kubernetes vertical, none of them provided end-to-end software delivery. To address this challenge, Devtron was born. Devtron seamlessly integrates with the majority of the solutions in the marketplace. Being highly flexible, it also provides multiple abstractions so that users don’t need to go in-depth into Kubernetes. Using Devtron’s complete automated workflow (which operates numerous verticalized tools such as Helm Charts, Clair, etc.), users can quickly deploy various applications. In addition, Devtron also offers next-level user management giving complete control to the users.

Solutions Provided:

Devtron is a complete consumer-focused tool built to take care of divergent needs such as monitoring, deployment, GitOps, observability, among many others, to make it a convenient experience for all users. It integrates multiple services within the Kubernetes and Cloud Native Computing Foundation(CNCF) universe to provide various microservices.

Some of the microservices like argocd, argo-rollout, clair, lens etc are readily available for deployment. In addition to that, all the original microservices created by Devtron are also available for the community to use and contribute.

Feature Exhibition:

One of the vital features includes exceptionally integrated Helm Charts within Devtron. With one click, users can add any helm chart they need and deploy it on their cluster. In addition, Devtron also supports multiple deployment strategies such as Blue-Green/Canary Deployment, which is uncommon. Users can also use Multiple Clusters and access Devtron’s Multi-Cloud support enabling multiple clusters available from numerous cloud providers, all managed from a single Devtron setup.

Integrated Observability and Uniform Access Management enables users to create groups for their environment and control access. Some other features include Centralized Caching, Hibernation, and Hierarchical Security Policies.

Devtron: Hands-On

Deployment: Devtron can be used to deploy any containerised application on a Kubernetes cluster without writing any kubernetes manifest at all. The users can simply connect various Kubernetes clusters on the Devtron UI (User Interface). This will allow the users to create multiple environments within the Kubernetes cluster. Each of these environments is mapped to a namespace within the cluster. Any Kubernetes cluster, be it on-premise or through cloud providers, can be connected. Devtron supports it all!

User Access Management:Users can define a group and add/remove users to manage permissions efficiently.

Chart Store:Using the Helm Chart section, it is easy to import any helm chart available in the market. It is simply a matter of selecting a helm chart and hitting the deployment key besides being highly customizable, allowing users to edit and deploy using integrated GitOps, so no hassle to manage and store helm values.

To access information on helm charts, users can find the ReadMe file to dig further. Helm charts can also be grouped for frequent use removing all the hassle of deploying them individually.

Security:Security is integrated within the Devtron UI, allowing users to scan all images they build through Clair integrated within devtron. The users can also control security policy at the organization, cluster, environment and application level. Hence, it is easy to enforce a policy that prohibits any user deploying a critically vulnerable application.

Deploying microservice using Devtron: To deploy microservices through Devtron, one simply has to create an application by selecting the Name and the Project. Then, the user can either create an application from scratch or clone configs from any of the existing applications that he has access to Devtron also supports building images from multiple git repositories. For a detailed tutorial, watch here:

Next Steps: Encouraging the Community

The Devtron project is an entirely open-source project that anyone can contribute to. Devtron is due to release a feature called “Bring your own charts” and will be including a lot of community contributed charts with due credits. All the DevOps and open source enthusiasts can contribute their charts. If contributors have a chart in mind and want to contribute, they can check the chart contribution guideline here. Furthermore, you can check the open issues in the Devtron Github Issues and ask the moderators if you would like to pick an issue and contribute.

You can Join our Discord here to connect with us.

A Journey of making our Dashboard Close to Perfect.

Prashant Ghildiyal — Tue, 13 Jul 2021 14:59:20 +0000

You can check out our dashboard and Opensource repo here:

devtron-labs / devtron

Tool integration platform for Kubernetes

Cloud Native tool integration platform for Kubernetes

Explore documentation »
Try Devtron Demo »
Website · Blogs · Join Discord channel · Twitter YouTube

🔥 Want to accelerate K8s adoption? Introducing DevOps in a Box; Leave DevOps on Devtron 🔥

Devtron deeply integrates with products across the lifecycle of microservices,i.e., CI, CD, security, cost, debugging, and observability via an intuitive web interface.

Devtron helps you deploy, observe, manage & debug existing Helm apps in all your clusters.

Devtron Demo Environment

Please log in the Demo environment using github credentials. Please note the user is granted view access.

Devtron Features

Application-level Resource grouping for easier Debugging

Devtron groups your Kubernetes objects deployed via Helm charts and display them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Devtron UI and even edit them!

Centralized Access Management

Control and give customizable view-only…

View on GitHub

This post was originally published on the Devtron website by our design lead, Utkarsh.

I was part of the leadership team of a fast-growing company and it was in May 2017 when we decided that we needed to become a better agile team. We realised that we wanted to become better at estimations and at reacting/taking action on feedback as we were growing at a very fast pace.

As a team, we spent considerable time reading practices adopted by other companies and then sitting in the room with a whiteboard and having passionate discussions on what would work best for us.

We knew that there was no ‘best method’ or right way to go about everything, therefore, we experimented with different approaches, but always found it difficult to quantify the effectiveness of those changes. It was always about the gut feel, and what the majority of the team felt.

I was particularly happy when we decided to explore the science around the impact of agile practices at Devtron. Now, people fortify their gut feeling with data. But that was only half the battle, we were yet to figure out how to present it in a way that meaningful insights could be derived out of it.

In this blog, we are going to share the journey of evolution of this product, the initial failure and the way forward, , how we evolved our product to what it is today. The journey is still ongoing, and would love to have your feedback and thoughts on how we can make it better.

The science behind the metrics

As the whole reason to adopt agile is to do more frequent and stable deployments, it was a no brainer to have the following metrics:

Deployment Frequency: How frequently are you deploying code.
Change Failure Rate: How often deployments fail.
Mean Time to Recovery(MTTR): How fast can you recover from failures.

Apart from the above metrics which measure the current performance of the team, we also decided to introduce two other metrics which aid in improving the above metrics.

In order to have higher deployment frequency and less failure rate the surface area of the release should be as small as possible and therefore we introduced:

Lead Time: Time gap between the oldest non-deployed commit in the release and the release date. This should be small because older commits may result in merge issues and incomplete testing.
Deployment Size: It is the number of lines changed between the release in question and the previous release. This number should again be as small as possible as smaller change means better testing and fewer bugs. It is based on the principle – less code, less bugs, no code, no bugs.

The First Cut

We launched a version of the Deployment Metrics a few months back. This is how it looked in the first version. Let’s see what we did and what went wrong.

We had put cards on the top which mentioned cycle time and deployment size for the latest deployment, time since the failure and time it took to recover from failure.

Graph below shows different data points related to each release. X – axis denoted time, Y – axis could be switched between cycle time and lead time. Ridges denoted number of deployments, circle size denoted size of deployment and green colour denoted successful deployment while red denoted failure.

Hover state showed this information in a tooltip. Users could view these metrics for a set of relative time ranges, i.e; last 15 days, 30 days upto 6 months.

We thought that we had done a good job of putting all data contextually so as to help developers make informed decisions, and that it would see good uptake from developers who want to adopt better DevOps practices.

Outcome (v1)

Over a period of a few months, we waited for users’ feedback on this page. What happened next was any product designer’s worst nightmare. It appeared that almost none of our users were engaging with this page. Moreover, we didn’t find much adoption internally as well. This meant that the developers at Devtron themselves were not able to leverage it to improve their metrics.

In fact, I clearly remember in one of the meetings around May 2020 when one of the developers threw up his hand and said he was exasperated trying to find whether our process change has been able to mitigate the impact of remote working. That is when we decided to step back and take a closer look at the reasons why this might be happening and how we can make these metrics more usable.

Learnings

We did an intensive half-day session with a focus of tearing down the existing feature and design. Every developer in the company communicated why they were not using it. We realised our biggest mistake was to design this page without looking at the sample data.

The biggest problem was posed by the huge variation in data points.

Cycle time may vary from a few days for regular releases to a few hours in case of critical bug fixes, the same is true for lead time.
Deployment size could vary from 2-3 lines to fix a bug to hundreds and thousands of lines for big feature releases. This led to huge variations in the ridge lines with many deployments clustered together which were not differentiable visually.

All in all, it made these charts totally unusable. Then we faced other minor problems: :

Although these metrics were important in the software delivery world, most developers barely knew what these metrics meant
Data points were juxtaposed in the graph for better correlation but had very high cognitive difficulty
Hover state gave all details of deployment, but it was difficult to compare metrics across deployments
Calendar supported relative time only i.e; last 15 days, 30 days…

Second Cut

Armed with the knowledge of challenges in the usability of metrics and data visualisation we decided to rethink it to solve this problem.

Though we use the Jobs to be done framework to identify the desired outcome, this time we added another step which we have found particularly helpful in data intensive applications – Questions to be answered. (We didn't know if such frameworks already existed but we have been using this homegrown framework internally for sometime now).

Hence, we decided to look at the metrics from a user’s lens, the goal this time was to identify key questions the user wants to be answered through this data so that he/she can make an informed decision.

Questions to be Answered (QTBA)

We framed user goals in the form of questions and statements so that we could think in terms of answering these questions while redesigning.

How has the performance changed over time?
How has the performance changed after the process was modified?
How do I quickly figure out areas for improvement?
How to correlate team behaviour changes with process modification for better Root Cause Analysis (RCA).

The Redesign

We redesigned the page from scratch in the pursuit of answering the above questions and some more. Take a look at it yourself.

In this design as you would see, we made fundamental changes to the previous design.

Use easy to consume metrics

Cycle time and deployments per day are related metrics, they are inversely related to be precise. Multiple deployments can happen in a day and each one of them will have a different cycle time. With dates as x-axis cycle times of different releases on the same date overlap with each other making them indiscernible.

Therefore, instead of cycle time, we are now charting the number of deployments per day as it is easier to understand trends over time.

Chart is to see trends not for RCA

In the previous approach, all data points were juxtaposed in one chart so that users could find the root cause of the behaviour. But we realised that it was creating cognitive overload.

Therefore in the newer version we decided to use charts only for anomaly detection and delegated RCA responsibilities to tabular data format. Instead of all data points juxtaposed in one chart, we placed all three metrics next to each other to highlight any anomalies.

Eg. In case of higher deployment frequency, you can find out if it is because of bug fixes or old pending features were deployed (higher deployment with increasing lead time).

What’s obvious to you may not be obvious to the user

Each metric is now supported by additional information to make the metric easily understandable and usable.

Example, for Deployment Frequency we have:

Meaning: A tooltip explaining what the metric means aimed to familiarise users with various metrics.
Visualisation: depicting trends of the metric over a given period.
Benchmarking: This was an important addition aimed to give a quick understanding of where the metric performance stands in comparison to the standard industry benchmark. Each benchmark was divided into four categories Elite, High, Medium, Low.

On clicking the benchmark, it opens a modal which further explains the metrics and the various benchmark categories for the metric.

We also realised that, though the number of deployments is the right metrics, deployment frequency is difficult to understand and hence we added cycle time information along with it for better understanding and correlation.

Hovering over the graph further shows details for each bar.

For example, hovering over the above bar shows 13 deployments (11 successful, 2 Failed) in the week of July 17 – Jul 24.

Clicking on each bar further opens a modal (to drill down) showing the deployments related to this particular bar. The modal additionally shows other data points (Cycle time, Lead time, Deployment size, and Recovery time if the deployment had failed) for easier correlation between various data points.

Tabular data better for RCA

Below the graphs, we added a deployments table showing all deployments of the application for the selected environment in the specified time period. The deployments lists can be filtered by successful and failed deployments based on the focus area of the user.

This solves the problem we had with hover, wherein you had to remember previous data points to compare. Now data is visible in tabular format and therefore it’s easier to compare changes across multiple releases.

Also, we went back to to using cycle time instead of number of deployments per day as this is a non aggregated view of data.

Sorting is provided on every column so that it becomes easier for you to find anomalies for e.g. largest deployments, highest recovery time, highest lead time or cycle time, etc.

You can also see the details of a deployment by clicking on the deployment date.

We believe that through this initial step that we have taken, teams who want to keep challenging themselves will be able to take data backed decisions and will be able to iterate quickly and confidently.

Let us know what you think about the design and our redesign process in the comments below. Also, if you have suggestions related to this feature do reach out to us and you can contribute as well.

Conclusion

Do not design data visualisations just for the sake of it, make sure they answer the users’ questions
Charts are best suited for trend analysis and anomaly detections
Identifying a relevant graphical representation(bar graph, line/area chart among others) is a key starting point while working with data visualisation

If you would like to know more about UX design and Devtron, I made a walkthrough with Saiyam Pathak, Director at Civo. He is a well reputed YouTube influencer and has a great following in the commnity. You can check it out here:

learn about The OpenSource End-to-End DevOps tool - Devtron, Heroku for Kubernetes. Livestream on 8th July 3:00 PM UTC

Prashant Ghildiyal — Wed, 07 Jul 2021 16:36:40 +0000

I am Excited to share with everyone that I will be joining Saiyam Pathak, Director of Civocloud and a YouTuber, on a Livestream on 8th july to talk about our OpenSource End-to-End Devops tool, Devtron.
There are cool giveaways as well for those who attend the event 😄

Devtron is an application-first way of looking at Kubernetes, meaning deep integrations with existing open-source, commercial software and add capabilities on top of them to enable a clean self serve UI for developers and DevOps.
We support various OpenSource systems like argocd, Argo workflow, Clair, hibernator, grafana, Prometheus, envoy, and many others. In short, it automates and helps in maintaining a balance between Security, Cost and stability of your app.

If any of this interests you, you will definitely have a great time. Come hang out with us on the stream to have a chat with me.

This is our OpenSource DevOps tool link, if you'd like to explore more

devtron-labs / devtron

Tool integration platform for Kubernetes

Cloud Native tool integration platform for Kubernetes

Explore documentation »
Try Devtron Demo »
Website · Blogs · Join Discord channel · Twitter YouTube

🔥 Want to accelerate K8s adoption? Introducing DevOps in a Box; Leave DevOps on Devtron 🔥

Devtron deeply integrates with products across the lifecycle of microservices,i.e., CI, CD, security, cost, debugging, and observability via an intuitive web interface.

Devtron helps you deploy, observe, manage & debug existing Helm apps in all your clusters.

Devtron Demo Environment

Please log in the Demo environment using github credentials. Please note the user is granted view access.

Devtron Features

Application-level Resource grouping for easier Debugging

Devtron groups your Kubernetes objects deployed via Helm charts and display them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Devtron UI and even edit them!

Centralized Access Management

Control and give customizable view-only…

View on GitHub

Devtron: A business opportunity in developers’ needs

Prashant Ghildiyal — Tue, 22 Jun 2021 11:53:26 +0000

Devtron is one of the few Indian Companies that is providing advanced Open Source tools using Kubernetes.

One of our co-founder, Rajesh, talks about all things Kubernetes, DevOps, and Devtron in a chat with Srinath Srinivasan. Featured in Financial Express!

Read the full article here: Devtron: A business opportunity in developers’

Checkout Devtron's OSS here:

devtron-labs / devtron

Tool integration platform for Kubernetes

Explore documentation »
Website · Blogs · Join Discord channel · Twitter YouTube

🔥 Want to accelerate K8s adoption? Our team would love to help 100 companies do it the Devtron way! 🔥

Apply Now 👋

Devtron deeply integrates with products across the lifecycle of microservices,i.e., CI, CD, security, cost, debugging, and observability via an intuitive web interface.

Devtron helps you deploy, observe, manage & debug existing Helm apps in all your clusters.

Devtron features

Application-level Resource grouping for easier Debugging

Devtron groups your Kubernetes objects deployed via Helm charts and display them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Devtron UI and even edit them!

Centralized Access Management
- Control and give customizable view-only, edit access to users on Project, Environment and Application levels Deploy, Manage and Observe on multiple clusters
-…

View on GitHub

Demystifying AppOps - DevOps done right!

Prashant Ghildiyal — Mon, 21 Jun 2021 10:21:15 +0000

AppOps? What’s that? How does it work? And why do I need yet another paradigm?

These are all valid questions, and to address them, we’ll have to make a quick trip back in time to set the context.

The Beginning

It all started with applications. In the beginning, computers were massive machines housed in labs, worked on by elite scientists and engineers, and the early applications were highly specialized software for space missions, defense, etc. As computers became smaller and more accessible, business-related applications drove the software industry. Then personal computing began to take off, further fueling the development of applications, and it careened along at breakneck speeds — particularly in the last couple of decades.

The breathtaking speed of software evolution meant that developers were scrambling to stay one step ahead. Initially, there was very little time in the development cycle to focus on anything other than functional features. Over time, and often led by the efforts of the open-source community, software tools and frameworks to support developers and ease the pain points of the development cycles became more common and a thriving industry in itself. Development cycles became more efficient, allowing developers more time to focus on the user experience. Customers were becoming better about advocating for their needs, and they also had the luxury of choice as more players entered the arena. Companies had to devote resources to make their product development process as customer-centric as possible to stay competitive.

Pre DevOps Hassle

The tools to support developers through the software development lifecycle allowed for hygiene protocols to be instituted to ensure that the application that worked flawlessly in the developers’ environment worked just as smoothly in the production environment. To support a more disciplined and structured development and deployment process, the IT infrastructure and the teams that maintained it had to expand significantly. Larger teams, more software tools, and supporting hardware resulted in an exponential growth in complexity and steep learning curves for everyone involved. Application developers, in particular, not only had to master the technology they worked on directly, but they also had to learn to handle the tools and protocols of the deployment management process.

Adding to the mix came cloud technology which meant organizations had to get comfortable with hybrid and distributed systems, all of which had to work together seamlessly. The tech world, especially the open-source community, always finds a solution for every pain point. Tools to manage the complexity sprung up, which led to the need for more teams to manage the tools! And so came about DevOps - to foster collaboration between the application (aka development) teams and the IT (aka operations) teams so that releases/services could be developed, tested, packaged, and deployed quickly and with high quality.

DevOps - An Improvement but not quite

Around this time, application containerization began gaining widespread adoption. Containers, which offer portability and extensibility, have become the standard packaging mechanism to deploy application-related libraries, dependencies, and configurations. As container use increased, the need for container management and orchestration became the need of the hour. Thus came about Kubernetes, an open-source platform initially designed by Google, to automate the management of containerized apps and services in a cloud environment.

So. Now we have DevOps to connect siloed teams plus a flexible platform like Kubernetes for container orchestration that gives developers more independence and control. So all should be well in the application development ecosystem, right? Not entirely. It’s a good start, but there remain gaps and no tangible way to accommodate different teams and organizations’ nuanced and specific needs. Developers have had to relinquish a lot of their ownership in the application management process to DevOps for the greater good. But having to depend on the DevOps team for even relatively minor changes has become restrictive and inefficient. Also, it results in distracting the DevOps team from crucial operations-related responsibilities. It has led to inefficient use of resources, both human and system.

Lack of Proper Integration

Despite the greater control that Kubernetes allows developers, there are still crucial missing bits of automation in the workflow (usually related to dependencies or changes that are outside the Kubernetes purview) requiring DevOps to step in regularly with what essentially amounts to manual intervention. An otherwise great platform still requires “glue” or custom code to get to the different moving parts working together. The process isn’t fool-proof - often, changes made by developers don’t fully carry through into the build process because of that small but crucial need for human intervention, which introduces errors, tripping up DevOps teams who are either not fully informed or are not as familiar with the configuration. This leads to an unnecessary and inefficient back-and-forth on problems to identify the root cause. Furthermore, though Kubernetes is a flexible platform, it isn’t necessarily easy to master; many companies admit that their application teams do not have the depth of expertise to handle the complexities, especially in a multi-clustered environment. Therefore an unfair share of the burden weighs down the DevOps teams, who are then mischaracterized as the bottlenecks in high-velocity release cycles.

So though the combination of DevOps and Kubernetes has gone a long way in breaking down the development/operations silos, there are still “last mile” pitfalls that can’t be automated away.

AppOps - The True Coordination

This was the genesis for Devtron proposing the AppOps model. We set out to democratize DevOps because we believe that empowering application developers is an integral part of the solution. Companies should adopt the best DevOps practices across the spectrum - irrespective of the size, revenue, or industry type. AppOps offers a framework and tools that cater specifically to developers, so they don’t struggle with the typical DevOps-oriented tools. It allows for greater efficiency as developers have more latitude in solving their problems. This self-service model also has checks to prevent compromising the inherent integrity of the process.

Using AppOps, the DevOps team can erect guardrails within which developers can build, deploy, and test their applications independently with minimal oversight. If the application fails in this sandbox, it can be debugged, changed, and redeployed, all with nary a call to DevOps. In short, developers can operationalize and manage applications without worrying about the complexity of the infrastructure or the domain knowledge that goes with it. The DevOps resources can spend less time putting out smaller fires and focusing on the more significant and more intensive responsibility of cloud infrastructure management and Kubernetes cluster deployments. A win-win all around.

The AppOps platform allows DevOps teams to abstract the complexities of the Kubernetes configuration for developers while providing a consolidated view of all relevant/critical data across the enterprise. They can also add in guardrails — constraints and restrictions limiting what application developers can and cannot do. A well-designed AppOps portal also provides DevOps with complete visibility on all deployed apps and their current state for crucial real-time monitoring.

Devtron has leveraged the power of Kubernetes to make AppOps a reality, bringing together DevOps and developers while also giving both their independence and the space to work separately - always a recipe for a happy marriage - as they work towards the common goal of agile, efficient and high-quality releases that can be deployed smoothly and with minimum churn.

About Me:

Hi Everyone, I am Prashant, and I have been a DevOps Engineer for more than 15 years now. I've been working on Exciting technologies like Kubernetes, Orchestration, Containerization, among others. With Experience, I understood that there is a lack of consolidated delivery workflow for Kubernetes. So, With some of my friends, I have Co-founded Devtron, an Open Source solution, to solve this issue. It would mean a lot if you can check out our Repo:

devtron-labs / devtron

Tool integration platform for Kubernetes

Cloud Native tool integration platform for Kubernetes

Explore documentation »
Try Devtron Demo »
Website · Blogs · Join Discord channel · Twitter YouTube

🔥 Want to accelerate K8s adoption? Introducing DevOps in a Box; Leave DevOps on Devtron 🔥

Devtron deeply integrates with products across the lifecycle of microservices,i.e., CI, CD, security, cost, debugging, and observability via an intuitive web interface.

Devtron helps you deploy, observe, manage & debug existing Helm apps in all your clusters.

Devtron Demo Environment

Please log in the Demo environment using github credentials. Please note the user is granted view access.

Devtron Features

Application-level Resource grouping for easier Debugging

Devtron groups your Kubernetes objects deployed via Helm charts and display them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Devtron UI and even edit them!

Centralized Access Management

Control and give customizable view-only…

View on GitHub

Here's why you should use Kubernetes!

Prashant Ghildiyal — Wed, 16 Jun 2021 15:10:58 +0000

Kubernetes is a portable, extensible, open-source platform for managing containerized applications and services that facilitates both declarative configuration and automation. Kubernetes provides a platform to configure, automate, and manage:

Intelligent and balanced scheduling of containers
Creation, deletion, and movement of containers
Easy scaling of containers
Monitoring and self-healing abilities

Challenges with Previous Technologies

Before Kubernetes there were containers, which became popular because they simplified going from application development to deployment without having to worry about portability or reproducibility. Developers can package an application and all its dependencies, libraries, and configuration files needed to execute the application into a container image. A container is a runnable instance of an image. Container images can be pulled from a registry and deployed anywhere the container runtime is installed: on your laptop, servers on-premises, or in the cloud.

Compared to virtual machines, containers have similar resources and isolation benefits, but are lighter in weight because they virtualize the operating system instead of the hardware. Containers are more portable and efficient, take up less space, use far fewer system resources, and can be spun up in seconds.

Managing containers for production is challenging. As the container market continued to grow and many workloads transitioned to fully production-grade containers, it was clear cluster admins needed something beyond a container engine. Key capabilities were missing, such as:

Using multiple containers with shared resources
Monitoring running containers
Handling dead containers
Moving containers so utilization improves
Autoscaling container instances to handle load
Making the container services easily accessible
Connecting containers to a variety of external data sources

Advantages of Kubernetes

Containers paved the way to build cloud native systems, in which services are implemented using small clouds of containers. This created an enormous opportunity to add and adopt new services to make the use of containers easier, faster, and far more productive. Since it was open-sourced by Google in 2014, Kubernetes has become the de-facto standard for container orchestration. Kubernetes leverages the power of containers while simplifying the management of services and machines in a cluster.

A Pod is a logical grouping of one or more containers, which are scheduled together and share resources. Pods enable multiple containers to run on a host machine and share resources such as storage, networking, and container runtime information.

Kubernetes Clusters abstract their underlying computing resources, allowing users to deploy workloads to the entire cluster as opposed to a particular server. A Kubernetes cluster consists of at least one master node that manages the cluster and multiple worker nodes, where containerized applications run using Pods.

Kubernetes architecture enables:

A single administrator to manage thousands of containers running simultaneously
Workload portability and orchestration of containers across on-site deployments to public or private clouds and to hybrid deployments in between

About Me:

devtron-labs / devtron

Tool integration platform for Kubernetes

Cloud Native tool integration platform for Kubernetes

Explore documentation »
Try Devtron Demo »
Website · Blogs · Join Discord channel · Twitter YouTube

🔥 Want to accelerate K8s adoption? Introducing DevOps in a Box; Leave DevOps on Devtron 🔥

Devtron deeply integrates with products across the lifecycle of microservices,i.e., CI, CD, security, cost, debugging, and observability via an intuitive web interface.

Devtron helps you deploy, observe, manage & debug existing Helm apps in all your clusters.

Devtron Demo Environment

Please log in the Demo environment using github credentials. Please note the user is granted view access.

Devtron Features

Application-level Resource grouping for easier Debugging

Devtron groups your Kubernetes objects deployed via Helm charts and display them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Devtron UI and even edit them!

Centralized Access Management

Control and give customizable view-only…

View on GitHub

This post is originally published on the Devtron website by one of our beloved devs, Prakarsh.

Understanding Kubernetes Architecture

Prashant Ghildiyal — Wed, 09 Jun 2021 04:59:07 +0000

Kubernetes is becoming the new standard for deploying and managing the software in Cloud because of the wide number of features that Kubernetes provide such as automated rolling and rollback of deployments, storage orchestration, automating bin packing, self-healing, management of secrets and configuration files and many more. This blog post will give you a high-level view of the Kubernetes Architecture and in-depth explanation about Kubernetes Node Architecture and its components.

Overview of Kubernetes Architecture

A Kubernetes cluster consists of a set of worker machines known as nodes that run containerized applications. Every cluster has at least one worker node. The worker node(s) host the pods that are the components of the application workload.

Kubernetes cluster consists of at least one master and multiple nodes.

Master:

It is responsible for exposing the application program interface (API), scheduling the deployments and managing the overall Kubernetes cluster, the master server runs the following components:

Kubernetes Master and Node Components

API Server: It performs all the administrative tasks through the API server within the master node.

scheduler: It schedules the tasks to worker nodes. It stores the resource usage information for each slave node.

controller-manager: The controller watches the desired state of the objects it manages and ensures that their current state through the API server. If the current state of the objects it manages does not meet the desired state, then the control loop takes corrective steps to make sure that the current state is the same as the desired state.

etcd: etcd is a distributed key-value store that stores the cluster state and can also be used to store configuration details such as subnets, ConfigMaps, Secrets, etc. It can be part of the Kubernetes Master, or it can be configured externally.

Node:

It is a physical server that has pods inside them that are responsible for running applications inside them and managed by the Master. The necessary components of Node are:

Kubelet: It is an agent that communicates with the Master node and executes on the worker nodes. It gets the Pod specifications through the API server and executes the containers associated with the Pod and ensures that the containers running within the pods are running and in a healthy state.

Kubelet also periodically monitors the state of the pods and in case of any problem, launches the new instance instead. Kubelet also has an internal HTTP server exposing a read-only view at port 10255. For Example: /healthz is a health check endpoint, /pods get a list of running pods, /spec to get specifications of the machine on which kubelet is running on.

Kube-Proxy: Kube-proxy runs on each node to deal with individual host sub-netting and ensures that the services are available to external parties. For each Service endpoint, Kube-proxy sets up the routes so that it can reach to it.

It serves as a network proxy and a load balancer for the pods running on that particular node. It is an important networking part of Kubernetes and ensures that there is an efficient communication across all elements of the cluster.

cAdvisor: It was originally created by Google is now integrated with Kubelet. It collects metrics such as CPU, memory, file, and network usage for all running containers and makes sure that they are running properly. All the data is sent to the scheduler to ensure the performance of the node which is further used for tasks like scheduling, horizontal pod scaling and managing container resource limits.

Container Runtime: Container Runtime is the software that is responsible for pulling images from public or private registries running containers based on these images. Kubelet directly interacts with Container Runtime to start, stop or delete containers. Kubernetes supports several runtimes such as Docker, container, CRI-O and any other implementation of Kubernetes CRI(Container Runtime Interface).

About Me:

I am Prashant and I've been thoroughly enjoying working in the DevOps space for years. My main areas of work used to be around DevOps, Kubernetes Orchestration and CI/CD. With Experience I understood that there is a lack of consolidated delivery workflow for Kubernetes. Sure, there are tools that will help us achieve a specific task but no tool that encompasses the whole workflow efficiently. So, with some of my passionate friends in tech, I have Cofounded Devtron Labs intended to solve this problem. It is a completely community led Open Source, Software Delivery workflow for Kubernetes that efficiently manages security, cost and Stability.

devtron-labs / devtron

Tool integration platform for Kubernetes

Cloud Native tool integration platform for Kubernetes

Explore documentation »
Try Devtron Demo »
Website · Blogs · Join Discord channel · Twitter YouTube

🔥 Want to accelerate K8s adoption? Introducing DevOps in a Box; Leave DevOps on Devtron 🔥

Devtron deeply integrates with products across the lifecycle of microservices,i.e., CI, CD, security, cost, debugging, and observability via an intuitive web interface.

Devtron helps you deploy, observe, manage & debug existing Helm apps in all your clusters.

Devtron Demo Environment

Please log in the Demo environment using github credentials. Please note the user is granted view access.

Devtron Features

Application-level Resource grouping for easier Debugging

Devtron groups your Kubernetes objects deployed via Helm charts and display them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Devtron UI and even edit them!

Centralized Access Management

Control and give customizable view-only…

View on GitHub