Forem: Abhinav Dubey

From Cluster UI to Operational Plane: Lessons from the Kubernetes Dashboard Deprecation

Abhinav Dubey — Sat, 24 Jan 2026 23:00:33 +0000

The official Kubernetes Dashboard has been deprecated.

With the Kubernetes Dashboard officially deprecated, many teams are reassessing how they manage visibility and operations in Kubernetes environments and for many teams, this didn’t change much day-to-day. The dashboard had already faded into the background of real production workflows. But the decision itself is still worth paying attention to; not because a UI is going away, but because of what that decision reflects about how Kubernetes is operated today.

The original Kubernetes Dashboard was built at a time when clusters were smaller, teams were centralized, and direct interaction with cluster resources was common. A simple web interface for inspecting and modifying resources made sense.

That context no longer exists.

Kubernetes today is multi-cluster by default, driven by GitOps, guarded by strict access controls, and operated by platform teams serving dozens or hundreds of developers. In that world, a generic, cluster-scoped UI isn’t just limited, it’s misaligned.

The deprecation of the Kubernetes Dashboard is less a removal of functionality and more an acknowledgment: Kubernetes operations have moved up the abstraction stack.

And that shift from cluster UI to operational plane is the real lesson here.

For more details about the Kubernetes Dashboard, please check out this article.

The Deprecation Is a Symptom, Not the Story

If you’ve been running Kubernetes in production for a while, this move probably felt inevitable.

Many teams stopped relying on the official dashboard years ago. Not because it was “bad,” but because it was built for a very different phase of Kubernetes adoption.

The dashboard wasn’t deprecated because it failed. It was deprecated because the operating model outgrew it.

That distinction matters.

What the Kubernetes Dashboard Was Originally Built For

The original Kubernetes Dashboard made perfect sense at the time.

It was designed for:

A single cluster
A small group of operators
Direct, imperative actions (similar to kubectl)
Basic visibility into pods, services, and deployments
Minimal assumptions around RBAC and organizational boundaries

In early Kubernetes adoption, this was enough. Clusters were smaller in size, teams were centralized, production workflows were simpler (although the dashboard was just an UI), it was easier to set it up and have a graphical visibility into workloads.

The dashboard answered one basic question well:
“What’s running in my cluster right now?”

How Kubernetes Is Actually Operated Today

Fast forward to today, and that question is no longer sufficient.

Modern Kubernetes environments look very different:

Multiple clusters across regions and environments
GitOps-first workflows, where Git is the source of truth
Helm everywhere, managing application lifecycles
Strict RBAC, often tied to SSO and org structure
Platform teams enabling developers, not operating clusters manually
Deployment state and observability matter more than raw resources

In most real-world setups:

You don’t “edit” live resources inside the cluster
You don’t want everyone to see everything
You care more about applications than individual pods
You need context across clusters, not inside just one

A generic, cluster-scoped UI starts to feel out of place.

Why a Generic Cluster UI No Longer Works

This is where the original dashboard begins to break down, not functionally, but conceptually.

A few realities many teams ran into:

Resource-centric views don’t match how teams think
Developers reason in terms of applications and releases, not ReplicaSets and Services.
Single-cluster visibility doesn’t scale
Troubleshooting modern systems requires aggregation and comparison across environments.
RBAC becomes painful fast
“Just give dashboard access” stops working once security and compliance are involved.
Drift between Git and cluster is invisible
The dashboard shows what is, not what should be.

At that point, the dashboard becomes either read-only and underused or powerful but risky. Neither is a sustainable operational model.

What a Kubernetes Dashboard Needs to Be Today

This naturally leads to a better question:

What should a Kubernetes dashboard actually do in 2026?

Based on how Kubernetes is used in practice, a modern dashboard should:

Be application-aware, not just resource-aware
Work across clusters, not inside one
Be RBAC-first, not RBAC-as-an-afterthought
Understand deployments, rollbacks, and failures
Complement GitOps and automation, not bypass them

At this level, the dashboard stops being a UI for cluster inspection and becomes a thin operational layer providing context, guardrails, and visibility without encouraging ad-hoc changes.

This is less about UI design and more about operational philosophy.

From Dashboards to Operational Planes

This shift explains why many teams moved away from the official dashboard long before it was deprecated.

They weren’t necessarily looking for “a better dashboard.” They were looking for a way to operate Kubernetes that aligned with their scale, security posture, and delivery workflows.

This is where Kubernetes management platforms like Devtron come into the picture; not as replacements for kubectl, and not as generic UIs, but as operational planes that sit above the cluster and becomes the orchestration layer for managing applications on Kubernetes.

These platforms focus on:

Application-centric visibility
Deployment and Helm awareness
Multi-cluster context
Guardrails instead of unrestricted access
K8s-native CI/CD
Integration with GitOps (ArgoCD, FluxCD)
Security and policies preventing unintentional production downtime
Enables automation instead of writing custom scripting

It represent a different generation of tooling, built for how Kubernetes is actually run today.

Devtron is a Kubernetes Management Platform, born in Kubernetes and provides the best conventional way of operating your workloads on K8s

Conclusion

The deprecation of the Kubernetes Dashboard isn’t a gap that needs to be “filled” by another UI.

It’s a reminder that Kubernetes is no longer operated at the level of individual resources and ad-hoc actions. As clusters, teams, and delivery pipelines scale, the center of gravity shifts from cluster inspection to application lifecycle management, from visibility to security & governance, and from manual operations to guardrailed automation.

This is where Kubernetes management platforms like Devtron naturally fits in; not as dashboards in the traditional sense, but as operational planes that reflect the reality of modern Kubernetes operations.

The dashboard didn’t disappear.
It evolved; just not in the place many originally expected.

Getting Started with External Secrets Operator

Abhinav Dubey — Sat, 18 Feb 2023 20:24:45 +0000

Kubernetes has one of the most simple and flexible methods for storing and retrieving sensitive data in form of secrets. Kubernetes allows creating and storing of secrets such as database passwords, tokens, etc within Kubernetes namespaces. These secrets can be retrieved in form of environment variables or from the files mounted at a certain location within the pod and then can be used in the applications. Even though the native process is seamless and easy, it has certain disadvantages.

Base64 Encodings: The default secrets encodings are base64 encoding which doesn't ensure the security of secrets stored within Kubernetes.

Missing Single Source of Truth: There is no single source of truth for managing all your Kubernetes secrets in one place. It is not recommended to store secrets in static YAML files in a git repository.

Lack of Vault Integrations: Kubernetes secrets don't come with any mechanisms to integrate with cloud vaults such as AWS secret manager, Azure Key Vault, etc to offer enterprise-grade protection.

Thus, KES was Born!

To address the above challenges, Kubernetes External Secret (KES) was born. It was created by Godaddy for their internal usages and later on open-sourced for the community. It comes with the default integration of multiple cloud-based secret stores and solves the all issues discussed above.

However, the GoDaddy team have stopped maintaining the project and is publicly archived on July 26, 2022.

Introducing External Secrets Operator

External Secrets Operator (ESO) is a Kubernetes operator that helps you integrate with third-party external secrets like Hashicorp Vault, AWS Secrets Manager, Azure Key Vault, IBM Cloud Secrets Manager and many more within your Kubernetes secrets. The main objective of ESO is to synchronize secrets from external APIs into Kubernetes. It is a collection of custom API resources - SecretStore, ExternalSecrets, and ClusterSecretStore that helps you maintain the lifecycle of secrets from third-party vaults.

Architecture

ESO controller is installed in a Kubernetes cluster and is a cluster-specific object. To communicate with other secret managers, the API resource - SecretStore / ClusterSecretStore is deployed within the namespace/ cluster and is responsible for the authentication with external APIs. There are different ways you can authenticate using such as generic secret (using access key & secret key), IAM roles, ServiceAccount, etc that can be seen here in the documentation.

Once authentication is done, it will create an API resource called ExternalSecret that is responsible for interacting with your secrets stored in vaults and then creating a secret out of the box in respective namespaces.

This is a high-level architecture on how ESO works. Now, let's try some hands-on.

Getting Started with ESO

ESO installation is pretty straightforward. We need to install the ESO controller and then we are ready to get our external secrets into Kubernetes. For controller installation, we will use the helm. It is the Kubernetes package manager. For more information about helm, feel free to read the below blog.

All About Helm, The K8s Package Manager

Abhinav Dubey ・ Feb 8 '22

#kubernetes #beginners #opensource #devops

Execute the following commands to install ESO Controller

helm repo add external-secrets https://charts.external-secrets.io

helm install external-secrets \
   external-secrets/external-secrets \
   -n external-secrets \
   --create-namespace

Once the controller is deployed, you can see all three pods up and running in external-secrets namespace as shown in the below image.

Yayy!! The controller is up and running. It is all you need to get started with External Secrets. Now let's take the example of AWS Secrets Manager and fetch secrets from AWS and create Kubernetes secrets.

AWS Secret Manager with ESO

Execute the following steps to create a secret in AWS Secret Manager and get it into Kubernetes using ESO.

Step-1: Create a secret using GUI named user-creds with two key-value pairs, username & password. Once created, you can see the dashboard something like this -

Step-2: Let's now create a generic secret with an access key and secret access key that would be used by SecretStore for authentication. Execute the below command to create a secret.

[Note: Make sure KeyId & SecretKey generated should have access to the secrets manager]

echo -n 'KEYID' > ./access-key
echo -n 'SECRETKEY' > ./secret-access-key
kubectl create secret generic awssm-secret --from-file=./access-key --from-file=./secret-access-key -n external-secrets

Step-3: Create SecretStore uses the generic secret for authentication. Execute the following manifest to create SecretStore named cncf-thane-demo

cat <<EOF | kubectl apply -f - 
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: cncf-thane-demo
  namespace: external-secrets
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        secretRef:
          accessKeyIDSecretRef:
            name: awssm-secret
            key: access-key
          secretAccessKeySecretRef:
            name: awssm-secret
            key: secret-access-key
EOF

Step-4: Now create a ExternalSecret would fetch the secrets from the AWS secrets manager and bring them to Kubernetes. Execute the following manifest to create ExternalSecret named cncf-thane-demo and provide the necessary details to fetch secrets.

cat <<EOF | kubectl apply -f - 
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: cncf-thane-demo
  namespace: external-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: cncf-thane-demo
    kind: SecretStore
  target:
    name: eso-secret
    creationPolicy: Owner
  data:
  - secretKey: credentials
    remoteRef:
      key: user-creds
      property: username
EOF

After ExternalSecrets being deployed, you can check the secret it created. In our case, it has created a secret named eso-secret that we have specified in ExternalSecret manifest. Let's now check if we get the value of the username key that we have added in the secrets manager.

kubectl get secrets eso-secret -nexternal-secrets -o jsonpath='{.data.credentials}' | base64 -d

Hurray!! We have successfully fetched the value from AWS Secret Manager and imported it into Kubernetes secrets using ESO. We can also use ESO to get multiple secrets or even the plan text secrets into Kubernetes in a similar fashion.

Conclusion

In this blog post, we have seen the need for an External Secrets Operator, KES and how to get started with ESO to fetch secrets from AWS Secrets Manager. Feel free to connect with me on Twitter and LinkedIn and ask your questions if you have any.

OpenLens Deprecated Logs & Shell

Abhinav Dubey — Thu, 29 Dec 2022 04:12:37 +0000

OpenLens is the open-source project behind one of the most adopted Kubernetes IDE, Lens. In simple terms, it is nothing less than Lens without its proprietary components. OpenLens falls under the MIT license and has been actively maintained by the community and the Lens team. The installation of OpenLens is a bit complex as you have to build it from the source, but many open-source contributors maintain builds depending upon the operating system. OpenLens also releases the same release that Lens IDE does and is a mirror image in terms of appearance. With the latest release, i.e. v6.3.0, the OpenLens governance team has deprecated some of its best features, causing chaos in the open-source community. In this blog, we will talk about the deprecated feature and an alternative solution.

What is missing on the OpenLens v6.3.0?

With the latest release of OpenLens v6.3.0, you won’t be able to access logs and the terminal of your Kubernetes workloads/nodes attached to the cluster from the IDE by default. These extensions are permanently removed from the OpenLens and moved to Lens Desktop. Here are some references for the same -

Now, let’s dive a bit into the history. Lens 6 is by far the most important release from the Lens team that comes with many new additional features but only with the paid subscriptions. With the Lens6 release, they talked about their vision and introduced new subscription models primarily in two tiers: Lens Personal (with limited support) and Lens Pro. They have also updated their terms and conditions, which can be read from their official blog. Lens Personal is free to use but comes with limited features and is limited for educational purposes or for startups with less than $10 million in annual revenue or funding.

The recent OpenLens v0.6.3 release doesn't provide the capability to access logs and shell extensions. This has impacted the community, and the heavy users who relied on these extensions are looking for ways to resolve this redacted feature. They are limited to two options. The first is either to use a personal license or to move to the pro version by paying a subscription fee if their organization exceeds the $10mn revenue or funding criteria. The second option is to look for alternatives.

Users looking for an alternative open-source project that can provide them the capability to access real-time logs and a shell extension should consider Devtron.

Introducing Devtron, An Open source alternative to OpenLens

Devtron is an open-source alternative to OpenLens with all your standard features and a lot more. The Devtron project is completely open-source and offers a much wider range of capabilities over and beyond shell and log extensions. It helps you to deploy and manage all your Kubernetes workloads. It is built in a modular fashion that comprises of two primary components -

Kubernetes Dashboard by Devtron
Devtron Dashboard with CI/CD

Kubernetes dashboard by Devtron helps you manage the lifecycle of Helm applications and Kubernetes objects associated with the chart, circumventing all the complexities and challenges of dealing with Kubernetes directly. Read about the challenges that Devtron’s Dashboard solves to explore ways you can simplify operations at your organization.

Why Kubernetes Dashboard by Devtron over other alternatives

Adopting Devtron only for bash and log extensions will be throttling the power that Devtron can unleash for your application teams. Let's understand how Devtron can become your go-to tool for managing your clusters and workloads in Kubernetes.

Cluster Management
- use your custom images of your favorite tools like - k9s/ netshoot/ busybox/ helm/ kubectl from the cluster terminal in the browser,
- Multi-cluster enabled,
- Preconfigured RBAC, so you don't have to use kubeconfig,
- Dedicated panel to view resource usage details
Workload Management
- grep logs across multiple pods with ease,
- exec into the pods,
- deploy any helm chart or K8s application,
- easy rollback with configurations,
- compare configurations diff,
- manage helm app across multiple clusters,
- easily upgrade helm charts,
- faster debugging of helm charts with resource grouping, events, manifests, logs, and a lot more.

While you are evaluating your options, Devtron may be able to tick all of your requirements at one go.

devtron-labs / devtron

The only Kubernetes dashboard you need

The Kubernetes Dashboard for Helm

Abhinav Dubey — Thu, 10 Nov 2022 07:15:56 +0000

Configuring and managing Kubernetes requires a lot of effort and domain expertise. From writing Kubernetes manifests to deploying and upgrading them manually every time a new change comes in, it makes your workflow more and more complex. Sooner or later, most teams end up with tools to simplify their application deployment. Helm happens to be the most adopted package manager for deploying applications on Kubernetes. Though widely adopted because it reduces the complexities of deploying applications on Kubernetes, Helm CLI has posed few challenges that we will talk about in this blog.

If you are new to helm and probably wondering about what exactly it is, have a look at the detailed breakdown on what is helm and how to build your own helm chart.

All About Helm, The K8s Package Manager

Abhinav Dubey ・ Feb 8 ・ 8 min read

#kubernetes #beginners #opensource #devops

Challenges with Helm

While Helm is great at packaging Kubernetes applications, it still needs to catch up when it comes to debugging and troubleshooting applications using Helm CLI. The community currently faces some burning challenges:

No active/real-time monitoring of Kubernetes resources with time series data - using Helm CLI just presents the current state of applications which is rarely enough for troubleshooting
Improper grouping of resources
Accessing the chart’s readme documentation is not seamless
Missing unified interface for managing Helm Apps across multi-clusters
No easy way to compare deployment values across deployments

Peripheral Challenges

Apart from the native helm challenges, there are some other issues as well which can be solved using Helm Dashboard and can help you to manage the entire team and optimize the infra costs. The other challenges are:

No out-of-the-box support for hibernation of workloads
Complex access management for team members

Devtron is aware of the community's difficulty with existing Helm CLI features. Considering these common problems that the community faces today with Helm CLI, we built an intuitive Helm dashboard for managing the lifecycle of Helm apps, abstracting out all the complexities and challenges. Let's take a look into the challenges and how the Devtron dashboard helps to solve those challenges.

Helm Dashboard in Devtron

Before we look out for the solution, let me grab a minute of yours. Devtron is an open-source cloud-native tool integration platform for Kubernetes. It provides an intuitive dashboard for all your Kubernetes and Helm-related challenges and enables teams to easily collaborate and work on faster delivery of applications on the top of Kubernetes.

How Devtron helps to solve all your challenges

Active Monitoring

If you are using helm CLI, there’s no real-time monitoring of your workloads. Once you deploy/install a chart using helm install repo/chart, helm status will always show you as deployed even if some of the k8s resources are missing or not deployed successfully. With Devtron’s Helm Dashboard, it becomes effortless to actively monitor all the Kubernetes Resources deployed using the Helm charts. It shows the real-time status of applications deployed through the dashboard or a terminal.

Let’s assume, you deployed a helm chart and there is some configs error in it. Unlike helm CLI, Devtron will show the status as Degraded since the chart configs were not correct. If everything was good and deployed successfully, the status will be shown as Healthy. Again if the chart is deployed, and someone deletes any k8s workload associated with it, Devtron will immediately change the status to missing.

Resource Grouping

In the official kube-prometheus-stack chart, about 174 Kubernetes resources get deployed when you install the chart. Imagine if there’s an error in any of the config files of the multiple Kubernetes resources. How difficult would it be to debug using helm CLI or just kubectl?

You would have to fire a lot of kubectl/helm commands to figure out which workload is not working. Then check out the logs, describe the pods, etc just to figure out what went wrong and all that from the terminal. But Devtron greatly simplifies that.

Devtron does the grouping of resources of all your applications and categorizes them into different buckets, which makes it easy to find the right resources while debugging. As you can see in the above screenshot, all the networking-related components are categorized under Networking (like Ingress, Service, and Endpoints), ConfigMap, secrets under Config & Storage, etc. Also, if you hover over any workload, you will get an option to check out the k8s manifest and events, check logs in real-time, and even exec into a pod for debugging directly in the Devtron UI.

Here is an additional read on a detailed understanding of debugging and logging capabilities of Devtron for Helm apps.

Referring to Chart’s Documentation In Your Workflow

If you want to try out a new Helm chart, you will use its README to check out the different parameters exposed, the values to be passed, and so forth. If using Helm CLI, it becomes a hassle to refer to README, again and again, navigate to different tabs in the browser, making typo errors or mismatched parameters and values in the process, all leading to spending more time to get the job done. With Devtron’s Helm Dashboard, you can see the chart’s README beside the values and check out the parameters, their descriptions, and values to be passed all at the same place.

Managing Helm Apps Across Multi-Clusters

One of the big pain points of using helm CLI or kubectl is that there isn’t any unified platform/dashboard to manage deployments across multi-cluster in a hybrid cloud. As seen in the above image, Devtron does it very smoothly. With Devtron’s application tab, you can easily observe and manage your deployments across multiple environments and clusters, irrespective of the cloud providers.

Deployment Values Comparison

One of the primary questions that SREs and developers ask while troubleshooting is “what changed” since the last time the application was stable? In the context of Helm, comparing value.yaml files are one of the most common workflows for all teams. Devtron’s Helm Dashboard provides a handy way to compare Helm configurations when you are dealing with an incident or troubleshooting

Hibernation of Workloads

There’s no Out-of-the-Box support for the Hibernation of workloads in Helm or raw Kubernetes. When it comes down to cost optimization, it becomes essential to consume the resources as per requirements, and especially talking about small-scale industries or startups, features like hibernation of workloads can help them save dollars just with a few clicks.

It becomes very effective for environments like non-prod or staging. With a few clicks, as shown in the image above, you can quickly scale down your workloads, not in use, and save the infra costs.

Access Management

When you use raw Kubernetes or Helm CLI, collaborating with other team members becomes a bit complex. For adding any user or upgrading any user's access, you will need to write RBAC rules every time. But Devtron significantly simplifies that. Internally it also uses RBAC, inheriting all its advantages and abstracting out the complexities by providing this intuitive user interface, as seen in the above image. You can add users just in seconds.
Devtron also has its flavor for access management and enables teams to provide access at different levels - for entire projects, environments, and even for a single application. It also comes with Group permissions wherein users can create a group of accesses, for e.g - View only access to maybe staging environment for all new joiners and add the group permissions while adding new users. Please refer to the documentation for more detailed information about fine-grained access management for helm apps.

Conclusion

The adoption of Kubernetes is increasing, and so is the usage of Helm. To ensure business agility with minimal errors in deploying Kubernetes with better management and debugging capabilities, community users can adopt the Helm Dashboard in Devtron.

As part of our commitment to open source, we will strive to improve this dashboard further. We are always looking to learn about what problems we can solve for our community. If you have suggestions or feature requests, submit them on Github.

Deploying a custom Mongodb operator using Helm Charts

Abhinav Dubey — Tue, 28 Jun 2022 11:00:31 +0000

Building a Helm chart and managing it, are two different aspects of packaging an application for Kubernetes. Helm is efficient enough to package a complex K8s application and deploy it. When it comes down to app management, there are certain challenges with Helm. In this short blog, we will see how easy it is to deploy and manage a custom mongodb chart using Devtron.

So, let’s get started

If you are not aware of Helm, please have a read of my previous blog for detailed understanding of Helm charts.

All About Helm, The K8s Package Manager

Abhinav Dubey ・ Feb 8 '22

#kubernetes #beginners #opensource #devops

[Note: The only prerequisite of getting started with Devtron is to have a Kubernetes cluster]

Adding Helm repository

Devtron comes with a number of pre-added, commonly used Helm charts that can be seen in the Charts section. But if you want to install your custom chart, let's say MongoDB, it can be easily achieved using Devtron.

To add any custom chart, go to Global Configurations → Chart Repository → Click on Add Repository → Click Save → Click on Refresh Charts

[Note: If you do not see any charts in Charts section, click on Refresh Charts to sync all the charts from added repositories]

Deploying Helm charts

Now that we have added our custom chart repository i.e, percona, let’s deploy it.

To deploy any chart through Devtron, goto Charts → Click on Chart to Deploy → Click Deploy → Change Values as per required → Click Deploy Chart

For instance, I want to deploy Percona's MongoDB operator. Let’s see how we can deploy it with just a few clicks.

Step-1: Select the chart to deploy i.e, percona/psmdb-operator

Step-2: Click on Deploy to edit default values as per your requirements.

Step-3: Edit the default configuration and click on Deploy Chart. You can also see the description for all the parameters, from the sidebar - README of the particular chart.

Step-4: Congratulations, you have successfully deployed! You can see all the details of your deployed chart such as current status, different workloads, manifests, events, logs, deployment history, etc within Devtron dashboard itself.

Reach out to us through the Discord channel and refer to Devtron documentation, to find all the features of Devtron.

Unleash the blogger in you!

Abhinav Dubey — Mon, 30 May 2022 10:32:42 +0000

Are you a technical blogger passionate about writing interesting & exciting content to create a meaningful impact in people’s lives using technology? Using your writing skills, do you love to break down complex IT scenarios and explain them in simple terms?

If yes, Devtron brings an exciting opportunity to all the tech writers across the globe. Participate now and stand a chance to win exciting prizes and goodies. The published blogs between 5th May - 30th June, can be submitted to https://contest.konfhub.com/

Prizes

Roll-up your selves, become a blogging sifu 🥋 and get a chance to win exciting prizes along with Devtron branded swags.

Top 3 winners

Amazon Gift vouchers + Devtron Swag Kit

Winner: $350
Runner up: $200
2nd Runner up: $100

4th position to 10th position

$25 Amazon Gift voucher + Devtron Swag Kit

All valid submitters

Devtron Swag Kit

Blogathon Themes

Participants can write about any topics on the given themes, covering relevant scenarios and use cases.

Kubernetes
AppOps
DevOps/DevSecOps

How to Participate?

Write technical blogs on one or multiple themes mentioned above.
Your blog must cover examples, scenarios, or relevant use-cases of the technology themes on which you are writing.
You are allowed to publish any number of blogs. There are no restrictions.
Publish your blogs on any platform like Dev.to, Medium, Hackernoon, Dzone, Hashnode, etc. The blogs must be publicly accessible to anyone visiting the submitted blog page.
You can submit blog entries only as an individual. Team participation is not eligible.

Judging Criteria

Your blog should be written in English.
Your blog has to be original (not plagiarized) and new material (not a republication) published between 5th May 2022 to 30th June 2022 (both dates inclusive).
Your blog must be non-trivial with a minimum of 500 words. Videos that explain relevant aspects of your topic inside the blogs will carry additional points.
The popularity of your blogs (number of blogs, likes, shares, views, etc) will carry additional points. Blogs that are aligned with Devtron will carry additional points.
Blogs talking about any software or tool should have a fair comparison against Devtron.
Include back-links to the Devtron website and GitHub in a prominent section of the blog, with relevant hashtags at the end of your blog.
You give KonfHub & Devtron, permission to share your blogs in their online resources, newsletters, and social media (you will still own all the rights to your submission).
Winner selections will be at the sole discretion of Devtron.

Scoreboard

Signup for free on our Discord server and join the #devtron-blogathon channel to view the scoreboard. Scores will be updated weekly on the channel.

Is promoting a Blog allowed?

Yes, Definitely! You should promote your published blogs on whichever platforms you want to. You can promote your blogs via Twitter, LinkedIn, Emails, Newsletters, etc. This would help increase the visibility and reach!

While sharing your blogs, Do mention Devtron’s official handles and relevant hashtags including #DevtronBlogathon2022 and #devtron.

The top 10 blogs will be shared from Devtron’s official social handles. Feel free to reach out to us on our discord server for any issues or help.

Decrease your Organization's Carbon footprints using Kubernetes

Abhinav Dubey — Tue, 26 Apr 2022 10:56:44 +0000

If you are running micro-services these days there is a high probability that you're running it on a cloud provider like AWS, GCP, MS Azure etc. The services of these cloud providers are powered by data centres, which typically comprise tens to thousands of interconnected servers and consumes a substantial amount of electrical energy. It is estimated that data centres will use anywhere between 3% and 13% of global electricity by the year 2030 and henceforth will be responsible for a similar share of carbon emission. This post will step through an example with a case study of how to use Kubernetes to minimize the amount of carbon in the atmosphere that your Organization's infrastructure is responsible for.

Carbon Footprint

What exactly is Carbon Footprint? It is the total amount of greenhouse gases (carbon dioxide, methane, etc) released into the atmosphere due to human interventions. Sounds familiar, isn’t it? We all have read about the different ways greenhouse gases get released into the atmosphere and the need to prevent it.

But why are we talking about it in a technical blog? And how can Kubernetes help to reduce your organization's Carbon footprint?

In the era of technology, everything is hosted on cloud servers, which are backed by massive data centers. In other words, we can say data centers are the brain of the internet. Right from the servers to storage blocks, everything is present in these Data Center.

All the machines in the data centers requires energy to operate, i.e, electricity. Irrespective of the source of generation, renewable or nonrenewable. According to a survey conducted by Aspen Global Change Institute, data centers account for being one of the direct contributors of climate change due to the release of greenhouse gases. According to an article by Energy Innovation, a large data center may contain around tens of thousands of hardware and can use around 100 megawatts (MW) of electricity.

But again, how does using another technology i.e, Kubernetes can contribute to this? Before answering the above question let’s learn how to calculate the carbon footprint of a server that we usually create with a public cloud provider like aws. In AWS, we create Instances of different sizes, computation power, storage capacity, etc as per our needs. Let’s calculate the carbon footprint emitted by initializing an instance of type - m5.2xlarge in region - ap-south-1 which runs for 24 hours.

We can calculate the Carbon Footprint, by using the Carbon Footprint Estimator for AWS instances. As you can see in the below image, after giving the values, we can easily estimate the carbon footprint for the respective instance which is 1,245.7 gCO₂eq.

Factors Considered while Calculating

There are primarily two factors which contribute to carbon emissions in the Compute Resource carbon footprint analysis, which are discussed as below -

Carbon emissions related to running the instance, including the data center PUE
Carbon emissions from electricity consumed is the major source of carbon footprint in the Tech Industry. The AWS EC2 Carbon Footprint Dataset available is used for the calculation of Carbon emissions on the basis of how much wattage is used on various CPU consumption levels.
Carbon emissions related to manufacturing the underlying hardware
Carbon emissions from manufacturing of hardware components is another major contributor when it comes to carbon footprint calculations within the scope of this study.

How Kubernetes can help?

Kubernetes is one of the most adopted technologies. As per the survey by Portworx, 68% of the companies have increased the usages of Kubernetes and IT automation and the adoption metrics is still increasing. For any application to be deployed over kubernetes, we need to create a kubernetes cluster which comprises any number of master and worker nodes. These are nothing but instances/servers which are being initialized where all the applications will be deployed. The number of nodes keep on increasing as the load increases which eventually will contribute more and more to the Carbon footprint. But with the help of Kubernetes Autoscaling, we can lower down the count of nodes i.e, reduce the number of instances created as per the requirements.

Let’s try to understand it with a use-case.

A logistic company uses Kubernetes in their production to deploy all their micro-services. A single micro-service requires around 60 replicas which initializes around 20 instances of type - m5.2xlarge in region ap-south-1. If we calculate the Carbon Footprint of a single micro-service in 24 hours, it would be around 24,914 gCO₂eq. This is the amount of carbon footprint emitted just by a single micro-service for 24hrs, and there are thousands of micro-services in a well-versed organization which runs 24*7. Now if you are wondering how this can be reduced. Well you are at the right place.

The maximum traffic that a logistic company's First mile / Last mile app experiences is during the day-time, when the deliveries happen. Generally, from morning around 8:00 AM, there’s a steep increase in the traffic and it experiences its peak in afternoon hours. That's when it would have the most number of pod replicas and nodes/instances. Then post 8:00 PM the traffic decreases spontaneously. During the off hours, when the traffic decreases, the count of replicas also drops to 6 from an average of 60 for each micro-service, which requires only 2 nodes/instances. The micro-service uses throughput metrics based horizontal pod auto scaling using Keda.
Now if we talk about the carbon emissions by 1 micro service after deploying it on Kubernetes paired with horizontal pod auto-scaling, it would drop to around -

51.9 gCO₂eq x 2 (nodes) x 12 (hrs 8pm to 8am non-peak hours) + 51.9 gCO₂eq x 20 (nodes) x 12 (hrs 8am to 8pm peak traffic hours) = 13,701.6 gCO₂eq

51.9 gCO₂eq x 20 (nodes) x 24 (hrs no autoscaling) = 24,912 gCO₂eq

That's a whooping 11,211 gCO₂eq (45% reduction) in carbon emissions [1], and this is just by 1 micro-service in 24hrs. Which translates to 4092 KgCo2eq per year! For the reference of how much this is, a Boeing 747-400 releases about 90 KgCo2eq per hour of flight when it covers around 1000 Kms [2].

Now think of how much your organization is capable to reduce per year by migrating 1000s of micro-services on Kubernetes paired with efficient autoscaling.

Migrating to Kubernetes?

Kubernetes is the best container orchestration technology out there in the cloud native market but the learning curve for adopting Kubernetes is still a challenge for the organizations looking to migrate to Kubernetes. There are a many Kubernetes specific tools out there in marketplace like ArgoCD, Flux for deployments, Prometheus and Grafana for monitoring, Argo workflows for creating parallel jobs etc. Kubernetes space has so many options but they need to be configured separately, which again has it's own complexities.

That's where Devtron helps you, Devtron stack configures and integrates all these tools that you would have to otherwise configure separately and let's you manage everything from one stunning dashboard. Devtron is an open source software delivery workflow for Kubernetes. Devtron is trusted by thousands of users and giants like Delhivery, Bharatpe, Livspace, Moglix etc and has a broad range of community all across the globe. And the best thing is, it gives you a no-code Kubernetes deployment experience which means there's no need to write Kubernetes yamls at all.

Devtron is also running an initiative #AdoptK8sWithDevtron where they are offering expert assistance and help to first 100 organizations to migrate their micro-services to Kubernetes.

[1] When compared to micro-services which are not configured to scale efficiently.

[2] Ref: https://catsr.vse.gmu.edu/SYST460/LectureNotes_AviationEmissions.pdf

All About Helm, The K8s Package Manager

Abhinav Dubey — Tue, 08 Feb 2022 06:16:08 +0000

Helm is one of the most powerful and community adopted Kubernetes Package manager used in industry. It is used to install and manage all the Kubernetes application. In laymen language, think of it as npm or pip for Kubernetes. Helm deploys all the k8s applications in a packaging format called helm charts. It is used to install, upgrade, delete even the most complex Kubernetes applications. Now let's try to understand why do we even need helm charts at the first place?

Need of Helm Charts

Kubernetes provides a command line utility called, kubectl which is efficient enough to deploy, inspect, update, delete, your Kubernetes resources. All the k8s resources are defined in YAML files and can be deployed, update, etc by using kubectl. But then why the hell we need helm charts? Let's try to understand this with an example.

For instance you have a Kubernetes application which have different resources say, deployment, service, service account, role, role-binding, configmap, secret and ingress. Now we need to deploy all these resources in our cluster. Either we can use kubectl apply -f Yamls command to deploy all resources present in Yamls directory, or we can use helm charts. If we are using yamls, then for any new resource, we need to create a new yaml file and then deploy it. In this case, eventually we will have to write multiple yaml files, each for different resource. But this is not the case with helm charts.

Helm charts packages all the different resources of your k8s application in an organized way. It contains a directory called templates where all the different resources are defined which needs to be deployed. The environment variables and deployment-specific parameters are extracted out and put in a separate file called Values.yaml which can be configured every-time you deploy the chart. The advantage of doing so is that you can deploy it to different clusters and even in different environments say, development, staging or production environment without creating the whole chart again.

So, this one of the major advantage of using helm. If you still have doubts, don't worry. We will create a chart from scratch and deploy it on a k8s cluster.

Getting Started

Installing and creating helm charts are quite straight-forward. You can always refer to their installation-docs for installation as they provide a rich documentation to install helm in different distributions. For this example, we will be using script to install helm. Please execute the below commands -

First we need to download the script in our machine

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

Now we need to give execute permission to the shell script

chmod 700 get_helm.sh

Finally need to execute it which will install helm in your system

./get_helm.sh

Great. We are done with installing helm in our system. To verify the installation please run - helm version --short

If you could see the version, the installation is successful.

Create Your First Helm Chart

As we have successfully installed helm in our system, its time to create our own helm chart and deployed a Kubernetes application. We will be creating a chart for a simple go application which can be cloned from here.
[Note: In this blog, I will not be demonstrating how to wrap the application in an image using Dockerfile. Rather I will use an image which I created before and can be accessed from here]
Now let's begin with the hands-on part and create our first helm chart. Please follow the steps below -

Step-1: Helm is efficient enough to provide you with the basic template to begin with. To create the template, execute -

helm create demo-go-app

It will create a helm chart named demo-go-app which contains the basic configuration files & directories in the helm syntactical order as you can see in the below image.

Let's understand the files & directories created by-default

Key	Description
Chart.yaml	The file contains the information of your chart
chart	Its an empty directory which may contain any dependent charts if you have
templates	The directory contains all the yaml files needs to be deployed
tests	It contains files used for testing
values.yaml	This file contains the values which needs to be given while installation

Step-2: Now you can add/remove the files which you don't need for your application. In our case let's delete chart dir, tests dir, ingress.yaml and hpa.yaml as we don't need these for our demo.

Step-3: Now we need to provide the image where our application has been wrapped and needs to be deployed. In our case as I already mentioned above, we already have our application wrapped in an image and pushed in public container registry, so I will be using it.
Feel free to use it if you don't have your own image. One of the benefits of helm charts as we discussed, we just need to make changes in our values.yaml, which contains the parameters extracted from all the resources which we want to deploy. In the files, we just have to add our own image details and we are done with the bare min config to deploy our application. In the default value.yaml file, there are a lot different parameters which can be tweaked as per our requirements. As you can see an extract of few parameters from values.yaml, where I have just manipulated the image details and added fullnameOverride, rest everything goes default.

replicaCount: 1

image:
  repository: alex43/go-demo-app
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "v1.0"

imagePullSecrets: []
nameOverride: ""
fullnameOverride: "go-app"

Now you can make these changes and save the file.

Step-4: Since we are ready with the necessary changes, now we can install our chart. To install the chart in default namesapce we can use the following command.

helm install go-app demo-go-app/

If we want to install the chart in specific namespace, we can use the following command. It will create a new namespace and will install the chart in that namespace. If the namespace already exists, we can omit the --create-namespace parameter

helm install go-app demo-go-app --create-namespace --namespace helm-app

To verify weather the helm app has been created or not, we can simply use the following command with the namespace where it was installed as you can see in the below image.

helm list -n helm-app

Now we have successfully installed/deployed our k8s application with helm chart. Now let's play a bit around helm chart. In the values.yaml, let's say, if we want to add some more parameters which we want to configure while installation or upgrading the chart, we can easily do that. From deployment.yaml, for instance we want to make containerPort: 80 a generic parameter by passing it in values.yaml file so that it can be changed or updated while installation. To pass any value, we need to grab the values by using the syntax - {{ .Values.<AttributeNameGiven_in_Values.yaml> }}

Add a parameter in values.yaml file say,

port:
  containerPort: 80

Now add the following in the containerport parameter in your deployment.yaml so that it can receive the values passed through values.yaml

ports:
 - name: http
   containerPort: {{ .Values.port.containerPort }}
   protocol: TCP

Now if you want to check if the Values you added is properly working or not, you can render the chart locally by using the below command. It will render all the templates with values given in values.yaml. This is mostly used to debug and test your custom created helm charts.

helm template --debug demo-go-app/

The output would look like something in the below image if there isn't any error.

The advantage of doing so is that, we can override the values while installing or upgrading the chart just by using a parameter called --set. Lets upgrade the chart which we have installed.

helm upgrade go-app demo-go-app/ --set port.containerPort=8080 -n helm-app

The command will update the installed chart and will also update the REVISION automatically as you can see in the below image.

Similarly, we can update any parameter passed in values.yaml file while installation or upgradation. Now if we want to access our deployed application, just copy-paste the commands given in NOTES section after upgrading the chart. It will port-forward the port number 8080 of your localhost to the container port you have given. In our case we set it to 8080 so the output would look something like the below image.

Now if you visit 127.0.0.1:8080/, you would be able to see your application. In my case, I have given an endpoint layout.html so I will be able to see my application at the given endpoint as you can see in the image below.

So this was all about helm, and how you can create your own helm charts and deploy over k8s. Now if you want to delete the chart installed, simply execute the below command. It will delete all the resources it created along with it.

helm delete go-app -n helm-app

Since we are familiar with the helm chart concepts, let's talk a bit about its advantages and some of its challenges.

Advantages of Helm Charts

Can package complex applications to deploy over k8s
Easy to get started with per-defined templates
Can use nested helm charts as dependencies
Values can be overridden while installation and you don't have to create helm charts for different environments
Just one click away for deploying all the resources of a k8s application
Helm by-default maintains the database of REVISIONs (version) providing an ease to rollback if something goes wrong
Easy collaborations among team and scalability

Challenges with Helm Charts

It can easily package complex applications, but creating a helm chart for complex applications is itself quite complex
Troubleshooting and debugging is quite difficult in helm for complex applications as it uses templates for different resources
It doesn't provide any UI to manage applications deployed through helm. In scenarios where 100s of helm charts are deployed, it would be very difficult to manage helm apps.

So What next, Introducing Hyperion

In the blog, we have talked about helm, its requirements, creating helm charts, its advantages and some of its challenges. To overcome its challenges and sustain the originality of helm, let me take the pleasure to introduce you to a tool called Hyperion. It is one of its rare kind open source tool where you can easily look for all the helm charts deployed on a cluster through an intuitive dashboard. Hyperion is a lightweight in nature packed with full-fledged debugging features for your Kubernetes workloads. To know more about it, feel free to install & explore Hyperion and let me know your views through comments. I am working on a dedicated blog for Hyperion which will be releasing soon.

devtron-labs / devtron

Tool integration platform for Kubernetes

All About ArgoCD, A Beginner's Guide

Abhinav Dubey — Wed, 19 Jan 2022 13:58:29 +0000

ArgoCD, being one of their 1st in the market known for having a declarative GitOps based deployment over Kubernetes is one of the most adopted Continuous Delivery tool. It has been known for its excellent application deployment and management over Kubernetes and features such as auto healing clusters, user-access management, status check, etc. It is open-sourced on github under Apache 2.0 License.

ArgoCD Existence, Why 🤔?

There are already hell lots of tools in the market, so why do we need another one? To justify the existence of ArgoCD, let's try to understand the workflow for application deployment before-and-after ArgoCD.

Workflow Before ArgoCD

Before the existence of ArgoCD, the pipeline seems something like the image above. A common ci-cd tool is used for both the Continuous Integration and Continuous Deployment.

once the code is being pushed to version-control let's say Github, the tool triggers the other jobs
it runs the test-cases, build images, push the image to respective container registry
then changes the deployment manifests as per the new image build, and then deploy the new manifest using kubectl commands

All these jobs/tasks are being performed by a ci-cd tool. This is how traditional ci-cd workflow works before the existence of ArgoCD. However there are some challenges in this workflow.

We need to install and configure tools like kubectl, helm, etc in the ci-cd tools
We will have to provide access to k8s cluster and cloud providers if using managed services like eks to the respective ci-cd tool
It may lead to security loopholes as credentials are provided to external tools
There's no visibility of deployment metrics, your ci-cd tools doesn't know the status of deployed application once they apply the manifests

Workflow After ArgoCD

After the ArgoCD was launched in the market, the complete workflow has been changed. As you can see in the image, the Continuous Integration and Continuous Deployment has been separated now. ArgoCD uses declarative GitOps based deployment which states that the best practices is to have two different git repositories, one for application source code and another for deployment manifest files.

once the code has been pushed to version, the CI pipeline trigger the job
starts to run test cases, build images, push images to respective container registry and then update the manifest according and push manifests to its respective git repository
once the updated manifests is pushed to its respective repository be it Github, Gitlab, etc as shown in the image, ArgoCD installed within the cluster automatically checks for the updates and apply within the cluster.

This is how, the respective ci-cd tool is limited to CI and ArgoCD handles the CD part and thus separating both the operations. There are many different advantages of using this workflow, some of them are -

it uses git as a single source of truth, thus incorporating GitOps principles for the deployment
since ArgoCD is installed within the cluster and is the only one that makes changes within the cluster, it doesn't require any extra credentials unlike the case of a ci-cd tool
ArgoCD provides a dashboard to manage all the deployed applications hence enables you to get the status of application being deployed or not which we doesn't get in case of previous workflow
easy rollback, as the cluster is synced with a separate git repository so we just need to revert the changes in git and the cluster will be automatically synced with the git repository
disaster recovery, as in case of any disaster you just need to point the git repository to the newly created cluster and it will have all the configurations of the previous cluster

So, these are some of the major advantages of the Workflow after ArgoCD. Now let's dive into ArgoCD and do some practical stuffs.

ArgoCD Getting Started

As we have seen some background concepts of ArgoCD and its need, let dive into some hands-on part. There are two different ways to install and setup ArgoCD in you cluster,

Install using script
Install using helm chart

Let's look into each of these.

[Note: kubectl command must be installed and kubeconfig file should be at the default location(~/.kube/config) before installing argocd]

Installation by script

Just with few commands you can have your ArgoCD installed in your cluster and ready to deploy an application over it. Please execute the below commands for installation -

Create a namespace argocd where all ArgoCD resources will be installed

kubectl create namespace argocd

Install all resources in the created namespace

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

After installation, you need to access the dashboard. There are different methods given in their documentation for accessing the dashboard. We will be using port-forward as we are installing in our local machine. Please execute the command below

kubectl port-forward svc/argocd-server -n argocd 8080:443

Now your ArgoCD dashboard can be accessed in 127.0.0.1:8080 as you can see in the image below.

For the credentials to login, the username is admin and for password, execute the following command -

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

Congratulation 🥳 You have successfully logged into the argocd dashboard.
Now, this was one of the method. It can also be installed using helm chart. Let's see how.

Installation by helm

Recently argo-project has launched their official helm-chart support for ArgoCD, which enables us to install it with helm as well. Please execute the following command to install ArgoCD with helm -

Add the helm repository in your system

helm repo add argo https://argoproj.github.io/argo-helm

Now install the ArgoCD helm chart

helm install my-release argo/argo-cd

The advantage of installing with helm chart is that, you can easily provide the configuration as you want during the installation. For details of the parameters support by ArgoCD helm chart, please have a look at this detailed README

After installation, to access the dashboard and credentials, you can follow the same commands as we did earlier.

[Note: Make sure to remove namespace i.e, -n argocd if you have not provided any namespace during the installation from commands to access dashboard & credentials. To provide the namespace, append this with helm install command --create-namespace --namespace argocd]

This is how easily you can install ArgoCD with the two different methods. For detailed documentation of getting started with ArgoCD, please have a look at this. Now, lets deploy a simple application and configure it to manage by ArgoCD.

Application Deployment

For any application to be deployed and managed by ArgoCD, we need to create a config file say, application.yaml which will have all the configurations required by ArgoCD containing the repository URL to sync with, Path where all manifests are being stored which needs to be deployed, namespace, and other configs. Here's a demo project which we will deploy in our cluster having all yamls and application.yaml file with bare minimum configs.

Let's deploy our application. Please follow along with the following steps.

First, we need to store all the config files, including the application.yaml in a separate gitHub (gitlab, bitbucket, etc) repository as you can see here
Then we just need to deploy the application.yaml which consists config required by ArgoCD in the cluster by using the following command -

kubectl apply -f application.yaml

Now only just by applying the ArgoCD application config file, all other k8s yamls will automatically gets deployed and synced with the cluster. In the below image you can see that, the application, go-app-argo-config is responsible for creating all other resources.

If we want to update the deployment, service or add any other k8s manifests (yamls), we simply need to makes the changes and push in the github repository synced with it and rest will be taken care ArgoCD.

So, this was all about ArgoCD which you need to kick-start and play around it. If you have any doubts or suggestions, please feel free to comment it down, I would be happy enough to answer all your queries.

For more details about ArgoCD please feel free to check out their Github Repository

What I am Working on

As you have seen in the blog, ArgoCD is specifically used for deployment and for other operations you still need other tools. Devtron is an ecosystem of open source tools for Kubernetes. Devtron also uses ArgoCD for GitOps driven deployment along with other industry recognized open source tools like Prometheus and Grafana (for Monitoring), Clair (for image scanning), Casbin (for rbac auth implementation) and many more open source and enterprise level tools all integrated seamlessly in one package.

Currently I am working on another blog, where I will be explaining how Devtron leverages ArgoCD and other tools to provides a seamless experience of the complete Software Delivery lifecycle on Kubernetes.

devtron-labs / devtron

Tool integration platform for Kubernetes

K3d for Local Kubernetes Development

Abhinav Dubey — Mon, 27 Dec 2021 06:19:37 +0000

Hello folks, back here again with another blog. In this blog, we will discuss k3d and how easily it allows developers to set up Kubernetes developer environments. For this example, we will set up Devtron’s local development environment over k3d. Let me quickly introduce k3d and Devtron if you are not familiar with them.

K3d, the name itself suggests k3s-in-docker is a wrapper around k3s - Lightweight Kubernetes that runs it in docker. It is widely known for its rapid cluster creation and deletion and is most widely used for local Kubernetes development.

Now let’s talk a bit about Devtron. It is an open-source software delivery workflow for Kubernetes written in Go. It is known for its slick user interface which allows developers to deploy their microservices over Kubernetes in no time. Not only application deployment, but also it helps in monitoring and logging just through the Devtron dashboard itself. Moreover, it allows developers to integrate their existing open-source systems like ArgoCD, Jenkins, Clair, and others.

K3d - K3s in Docker

K3d has the capability to run k3s - lightweight Kubernetes inside docker within a few seconds. It has been highly recognised by the community and is widely used for Kubernetes local development.

Let’s quickly start with k3d and spin up a cluster.

[Note: Docker must be installed as a prerequisite for k3d installation]

Installation

K3d provides a rich installation method for different operating systems. For details about k3d installation please visit their documentation. I will continue with the installation script.

[Note: I will be using MacOS for the demonstration. You can use any OS and install k3d from their documentation as per your requirements]

Please execute the following command to install k3d in your system.

wget -q -O - https://raw.githubusercontent.com/rancher/k3d/main/install.sh | bash

Now let’s check whether it is installed correctly or not. Please execute the following command. It will print the k3d version installed in your system. Ideally, if you are installing from the above command, it will install the latest version.

k3d version

Congratulations! That’s it for the installation. If you can see the version, k3d has been installed and now we are ready to spin up a cluster and set up our local development environment.

K3d Playaround

Now that we have successfully installed k3d, let's create a k3d cluster and playaround k3d a bit. Please execute the following commands.

I) Creating a cluster

k3d cluster create demo-cluster

It will create a cluster named demo-cluster in your system and run k3s inside docker containers. To verify whether containers are running or not, please execute $ docker ps,it will list down the container running k3s.

If you have multiple clusters created, then you can switch context to the newly created cluster to work on that specific cluster.

$ kubectl config use-context k3d-demo-cluster, you can also see this command when a new cluster is being created as you can see in the above image.

II) Listing down nodes
The below command lists down the nodes available only in the demo cluster, as we have used grep command. If you don't provide the grep command, it will list down all the nodes available for all the clusters created using k3d.

k3d node list | grep demo-cluster

III) Listing down cluster
The below command is used to list down all clusters created using k3d but you can always use grep to find out specific clusters if you have several clusters installed.

k3d cluster list

IV) Stop & start your cluster
K3d also provides this exciting feature to stop your cluster and again start it where you stopped within seconds. The below command shows how easily you can stop and start your cluster in no time.

k3d cluster stop demo-cluster
k3d cluster start demo-cluster

V) Deleting the cluster
As with other commands, it's also very simple to delete the entire cluster within seconds.

k3d cluster delete demo-cluster

So this is how easily we can start working with k3d. For more detailed information about k3d and its commands, please refer to this documentation.

Local Dev Setup

Now as we have understood k3d and its commands, we are ready to set up our development environment with k3d and play around with it.

k3d Cluster Setup

For any Kubernetes development, the basic requirement is to have a Kubernetes cluster be it k3s or k8s. Here the role of k3d comes in. As we have already discussed above it can spin up a cluster in seconds and that’s why it's widely used for local k8s development. Let’s create a cluster.

The below command will create a cluster and expose host port 8082 with 30080 port of the agent which we are creating. Here we need to expose the port because we want to access the application running over k3s inside the docker container.

k3d cluster create devtron-local-dev -p "8082:30080@agent[0]" --agents 1

After the cluster is being created, switch context to the newly created cluster as specified above by using the command -

kubectl config use-context k3d-devtron-local-dev

Now the cluster has been created and we have switched to the newly created cluster. You can verify the weather cluster by listing down nodes and by listing down the containers running in your system as we discussed above in the K3d Playaround section.

Devtron Local Setup

Now we need to set up Devtron locally over the k3d cluster which we created. If you are using MacOS or Windows, make sure you have given the minimum resources required for Devtron installation through Docker Desktop as k3d runs k3s inside docker.

[NOTE: k3d doesn’t have any resource limitations, it takes up all the resources specified in Docker Desktop or Docker-cli if using linux]

Minimum Requirements

2+ cores CPU
4 GB Memory
20+ GB Storage

In my case, I have given 4 CPU and 6 Memory to Docker Desktop as you can see in the image below.

Devtron Installation

After setting up the minimum resources and creating a cluster, we are ready to install devtron locally over the k3s cluster. Please execute the following steps to set up Devtron locally. I will be using helm3 as it is the recommended way as per their official docs. You can also use other methods provided in the documentation.

Step-1: Add Devton helm repo. If the helm is not installed, you can refer to their installation guide.

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

You can check if it’s installed or not by using the following command.

helm repo list

Step-2: Install Devtron using helm3.

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

The install command will take up around 15-20 minutes to spin up all the Devtron micro-services required for installation.

Step-3: Check Installation status.
You can also check the installation status by using the following command. If it is installed successfully it will print Applied else it will print Downloaded as you can see in the below image.

Step-4: Change the devtron-service to NodePort with port number assigned while creating the cluster. It will allow us to access the dashboard using localhost:8082

Use the command - $ kubectl edit svc devtron-service -n devtroncd to edit the service and change the service type to NodePort and NodePort port number to 30080 which you assigned while creating the cluster.
After editing the service, you can check the changes by using the following command.

kubectl get svc -n devtroncd

Step-5: Access the dashboard locally.
To access the dashboard use localhost:8082 in your browser. For admin credentials use username as admin and for password run the following command.

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

Now you can easily login in your dashboard and start using Devtron.

For detailed information about Devtron and deploying your application over it, please refer to their well-maintained documentation.

Devtron Local Development Setup

Following the installation of Devtron over the k3s cluster, now we need to set up the local development environment so that developers can start building and contributing to the open-source project. For building any features or fixing bugs, we need to have the source code of the project in the very first place. Let’s clone the project and run it. Please execute the following steps.

[Note: Please make sure wire module is installed in your system]

Step-1: Clone the project.
The below command will clone the Devtron repo in your system. If you haven’t installed git, please install it from here.

git clone https://github.com/devtron-labs/devtron.git

Step-2: Build the project.
Go to the Devtron directory which you cloned, using the command $ cd devtron and build the Devtron source code into an executable file using the following command.

make build

Step-3: Port Forwarding the Services.
Now we need to port forward a few services to establish a connection between Devtron running with the binary we will execute in the next step. Execute the following commands in different terminals which can help you to check the logs and debug if any connection issues occurs and also do not close the terminal or stop these commands until the work is done.

If any commands are stopped, then please execute them again to maintain the connection with the local setup.

1)kubectl -n devtroncd port-forward svc/argocd-server 8000:80
2)kubectl -n devtroncd port-forward svc/argocd-dex-server 5556:5556
3)kubectl -n devtroncd port-forward svc/postgresql-postgresql 5432:5432
4)kubectl -n devtroncd port-forward svc/devtron-nats 4222:4222

Step-4: Setting up Environment Variables and executing Binary
Now we need to set up a few environment variables to connect the source code with the Devtron which we installed initially. Please run the following commands from the root directory where you build the project. It will set up the environment variable and execute the binary as well. Do not stop the command until the work is not done.

[Note: python3 must be installed in the system]

wget https://raw.githubusercontent.com/devtron-labs/devtron/main/developers-guide/scripts/exporter.py
python3 exporter.py

Yayy! We have successfully set up the Devtron locally in our system and now we can start building features, fixing bugs, etc and start contributing to the project.

Start your Open Source Journey with Git

Abhinav Dubey — Tue, 12 Oct 2021 14:41:41 +0000

Here, we are again with another beginner friendly blog. In this blog we will learn about one of the most popular version control tool, yes you guessed it right. I am talking about git.

In the blog we shall learn about -

What is Version Control
Why do we need Version Control
Git, One of the best Version Control tool
Start with Open Source Contributions

Let's start with the Version Control.

What is Version Control?

Version Control is a system which helps you to keep a track of all the changes you made in files or codes by keeping the track of each version you build so that you can rollback to previous version if needed. In layman language, it helps you to organize the things in a better way.

Why do we need Version Control?

Version Control provides an efficient way to manage your codes or files, but if you are thinking why exactly do we need it, let me give you an example.
Let's assume a scenario, today most of the companies are adopting Work From Home culture. Let's say we have 10 developers working on a product, building features for it from their home, so now how will they organize their code. Here comes the role of Version Control tools like git.

Still confused 🤔!

Let me give you another use-case. For example, you have build an application and deployed it. Everything works fine in the current version. Maybe you have added few new features and again deployed it but this time the application breaks. Now again comes the role of Version Control. By using version control tools such as git you can easily rollback to the previous version of your code.
This is how Version Control tools acts as a Savior for almost every organization.

Introducing Git

In the above section we learned about Version Control and its need. Now let's understand what exactly is Git and why it is so popular in the industry. Git is a version control system which is adopted by many companies and OSS users to maintain their code in local as well as remote repositories. The term repository here refers to storage container where project files are being stored and it can be any repository, be it GitHub, GitLab or Bitbucket. It is mostly used in the Software Development Industry to keep a track of changes made in code and also helps to increase the speed of development by providing a better support for distributed/collaborative development environment.

Begin your opensource contributions

Now let's start with the open source contributions and learn about some of the most useful git commands which are used commonly.

[Note: The blog is specific for open source contributions so we will discuss only those commands which are related to it]

Step-1: For making any Open Source Contribution, first we need to fork the respective repository to your account. Here's how you can fork it -

After the fork is being completed, it would look something like this in your account -

Step-2: Now clone the forked repo in your system using the following command.
Replace RemoteUrl with the URL of Repository you want to clone

git clone RemoteUrl

Step-3: Create a new branch for adding your changes. Use the below command, it will create a new branch and checkout into the newly created branch.

git checkout -b NewBranchName

To verify your current branch you can use git status command. It will give you all necessary details of git initialized repository.

Step-4: Now make the changes which you want as your contributions. After the changes has been done, you need to add those changes to git. Use the following command to add those changes.

git add ChangedFileName

Also you can add all the changes by using period(.) If you have changed multiple files this can be really useful. Move to the root directory of the project and then run the following command.

git add .

Step-5: Now commit the changes you made with a commit message. The message should be relevant to the change you did as it would be helpful for tracing.
For example, I made changes in README.md file so the command would be something like this -

git commit -m "Added discord link in README"

[Note: It is not mandatory, but as a best practice you should add relevant commit messages]

Step-6: Now we need to push the changes we did. We have to push in the same branch in which we are working. Use the below command to push your change -

git push -u origin NewBranchName

Congratulations 🎉! Now we are ready to raise our first Pull Request and make our first open source contribution.

Step-7: Go-to your forked Github Repository, you will see something like the below image. Click on Compare & pull request button in the UI.

Step-8: After that add the necessary details asked, like title of PR, Description, etc and then click on Create pull request button as you can see in the image below.

Tada! We just did our first open source contribution 🎊.

What next?

Contribute & Earn Swags

Now we understood how we can start our open source contributions. If you want to do some quality contributions and be the part of biggest opensource fest, yes I am talking about Hacktoberfest, feel free to check out this repository and unlock the cool giveaways along with the Hacktoberfest swags.
Yes! You read it right. You will get some awesome giveaways from Devtron for contributing on their repositories apart from the hacktoberfest swags. Everyone at any level is invited to contribute and take the giveaways. Please refer the below repository for better understanding of the swags and contributions guidelines.

devtron-labs / hacktoberfest2022

Opensource Celebration

Different Ways of Creating k3s Cluster

Abhinav Dubey — Thu, 07 Oct 2021 03:43:18 +0000

Creating a Kubernetes cluster was quite a tedious task until Rancher Labs introduced k3s - Lightweight Kubernetes. K3s is nothing but a lightweight kubernetes, where the developers has removed millions of lines of code from straight Kubernetes and wrapped it in a binary less than 100mb. Yes, you read it right, "millions of lines of codes".

In straight Kubernetes, we have different ways of creating a k8s cluster such as by using kops, eksctl, kubeadm, kubectl, etc, we also have few different ways of creating k3s cluster. In this blog we'll discuss different ways through which we can create k3s cluster.

1. With k3s

The traditional way of creating a k3s cluster is by using k3s itself as a server and as agent. We can create single as well as multi node or HA cluster using k3s.

[Note] There's no prerequisite for creating a cluster using k3s, you just need to have a system with minimum 512MB RAM and 1 core CPU

K3s single node cluster

Creating a single node k3s cluster or setting up k3s server is just a piece of cake. We need deploy a single command and it will create k3s server for you.

Please execute the following command and its done. Just with single command we can create our k3s single node cluster.

curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644

[Note: We will not go in-depth of commands and flags used, if you want to know, please let me know in the comment section]

K3s HA Cluster

Well in a single command we have created our k3s cluster single node cluster, but for High Availability cluster, we have to fire 3 commands which is pretty less as compared to straight Kubernetes.

Please follow the steps below to create your HA cluster.
Step-1 : Install k3s cluster in our server

curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644

Step-2 : Extract the node-token for adding agent nodes

sudo cat /var/lib/rancher/k3s/server/node-token

Step-3 : Add worker nodes to the master created. This command should be fired on another instance/VM to add it with the master. Replace my-server with master IP which we created above and node-token with the token extracted from above command.

curl -sfL https://get.k3s.io | K3S_URL=https://my-server:6443 K3S_TOKEN=node-token sh -

Hurray! We are done with the k3s HA Setup as well. For futhur in-depth intuition about the k3s, please refer to my previous article.

All about k3s - Lightweight Kubernetes

Abhinav Dubey ・ Aug 11 '21

#kubernetes #opensource #containers #github

Using k3d

One of the most popular and second method of creating k3s cluster is by using k3d. By the name itself it suggests, k3s-in-docker. I have contributed an article as guest author for a community where I wrote about k3d. Please refer to this link to get brief insights of this wonderful tool.
Now let's directly jump into creating our k3s cluster using k3d.

[Note : For using k3d you must have docker installed in your system]

k3d single node cluster

Creating a single node k3s cluster using k3d is like having a conversation with your dad.

Before installing your cluster, you need to install k3d on your system. Please execute the following commands to install k3s and create your single node cluster.

Step-1 : Install k3d

wget -q -O - https://raw.githubusercontent.com/rancher/k3d/main/install.sh | bash

Step-2 : Create a single node cluster.

k3d cluster create demo-cluster

and its done. Just this single command can create your single node k3s cluster in seconds.

k3d HA Cluster

Now let's install k3s HA Cluster using k3d. Well its just a cup of tea. Here's how easily you can install a HA Cluster using k3d.

k3d cluster create --servers 3 --image your/docker-image

Its done. This is how easily you can spin up your cluster using k3d. Fore more detailed information about k3d HA Cluster, please refer to rancher lab's official blog

[Note : We will not discuss the tools & commands in depth as it is beyond the scope of this blog, but if you want depth intuition, please let me know through comments]

Using k3sup

Now, let's move into our third tool K3sup, called as ketcup developed by Alex Ellis. K3sup is really an amazing tool which helps us to create a k3s cluster. I have written a twitter thread around it, feel free to check it out.
// Detect dark theme var iframe = document.getElementById('tweet-1442892364519858181-411'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1442892364519858181&theme=dark" }

k3sup single node cluster

Let's create our single node k3s cluster using k3sup. It require few commands to setup k3sup and then it automates the process of k3s cluster.
I would recommend to create an AWS ec2 instance or any other VM before getting started with the commands.

Step-1 : Download k3sup

curl -sLS https://get.k3sup.dev | sh

Step-2 : Install k3sup

cd /usr/local/bin
sudo install k3sup /usr/local/bin/

Step-3 : Install k3s Cluster in Instance/VM.
Replace the SERVER_IP with your instance/Vm IP and ec2-user with your username. In case of ec2 instance, default will be the same as given.

k3sup install --ip SERVER_IP --user ec2-user

Step-4 : Export kubeconfig file
Execute the following command from the directory where you have executed the above command.

export KUBECONFIG=`pwd`/kubeconfig

Step-5 : Switch Context to default and start firing your kubectl commands.

kubectl config set-context default

and here we go. We are done with the single node k3s cluster setup using k3sup. The beauty of k3sup is that from localhost itself you can run all the commands in your k3s cluster created on server through establishing a ssh connection with the instance.

k3sup HA Cluster

Finally, let move ahead and setup our HA Cluster using k3sup. Well the installation and the process of setting up a k3s cluster would be the same as that in case of single node. We just have to execute a single command and it will join agent nodes to the server running up there.

Please execute the following command to add multiple nodes to your k3s cluster running using k3sup.
Here AGENT_IP will be replaced with IP of Agent Node and SERVER_IP with IP of server and ec2-user with username.

k3sup join --ip AGENT_IP --server-ip SERVER_IP --user ec2-user

Now if we try to list down the nodes using kubectl get nodes, we can see the agent/worker node has been added in our cluster.

For other configurations such as adding external database or load balancers, please refer to this github repository.