Jenkins has been part of almost every DevOps journey. For many teams, it was the first real step toward automation and faster software delivery.

And to be clear upfront:

Jenkins is still a very good tool for Continuous Integration.

The problem starts when Jenkins is stretched beyond CI and used as a Continuous Deployment engine, especially in Kubernetes-based environments.

This blog explains why Jenkins CI/CD pipelines struggles with modern Kubernetes deployments, not from opinion, but from how the tool actually works and what Kubernetes expects.

What Jenkins Does Exceptionally Well

Jenkins shines when it comes to:

• Running builds

• Executing tests

• Creating artifacts

• Building container images

• Integrating with almost any tool via plugins

For CI workflows, Jenkins is mature, battle-tested, and reliable.

If your goal is:

• Compile code

• Run tests

• Push images to a registry

Jenkins does that job well. Though it has some fundamental issues with the plugin ecosystem from security point of view, but if are using your own scripts for building images or running tests, it does the job pretty well.

How Jenkins Is Commonly Used for Kubernetes Deployment

In most real-world setups, deploying an application to Kubernetes with Jenkins looks like this:

• A Jenkinsfile with multiple stages

• Shell scripts invoking kubectl

• Helm commands embedded in pipelines

• Environment-based conditionals

• Credentials injected at runtime

• Manual approval steps implemented in Jenkins UI

Over time, deployment logic moves into:

• Groovy scripts,

• Bash files,

• Pipeline parameters also known as parameterised builds,

• Jenkins job configuration

This approach works initially for basic setups. But it introduces a deeper problem. As you start scaling, expanding footprints on Kubernetes and cloud-native environments, Jenkins alone wouldn’t be sufficient and you end up stitching different tools, scripts, forcefully making it work somehow.

Deployment Logic Starts Living Inside Jenkins

Once Jenkins is responsible for deployment, ask a few simple questions:

• Where is the desired state of the application defined?

• How do you know what version should be running right now?

• How do you detect configuration drift?

• How do you roll back safely if Jenkins is down?

• How do you audit why a deployment happened?

• How do you do advanced deployment strategies like Canary/ Blue Green?

In most Jenkins-based setups:

• The answer lives inside pipeline code, i.e, Groovy scripts

• Or worse, inside someone’s head

At that point, Jenkins is no longer just a CI tool. It becomes the source of truth for deployments with lousy visibility on cluster and workload status.

That’s where things start to break.

Jenkins Is Imperative. Kubernetes Is Declarative.

Jenkins works by executing steps in sequence and all of that sequence is nothing but your custom scripts, plugins and commands:

Do this → then this → then this

Kubernetes works by continuously reconciling state:

This is how things should look, make it so

This mismatch creates several issues:

• Jenkins pushes changes, Kubernetes expects reconciliation

• Rollbacks require custom scripting

• Failed deployments don’t self-heal

• Drift detection doesn’t exist unless you build it yourself

This is why GitOps tools like Argo CD and Flux CD exist. They align with how Kubernetes actually works. For cloud-native and Kubernetes environments, Kubernetes-native platforms excels and does the job without worrying about custom scripting or manually juggling with plugins, scripts, or custom hacks to make things work.

Jenkins does not.

Jenkins Pipelines Become Increasingly Complex

As applications grow, Jenkins pipelines start accumulating responsibilities:

• Environment management

• Cluster-specific logic

• Secret handling

• Approval workflows

• Rollback rules

• Notification logic

This leads to:

• Long Jenkinsfiles

• Copy-pasted pipelines

• Hard-to-debug failures

• High onboarding cost for new engineers

At scale, teams aren’t managing deployments anymore. They’re managing pipeline complexity. Teams should spend time on writing good quality code, making the infra more resilient, developer-friendly so that there shouldn’t be any dependency on DevOps teams just for troubleshooting issues of getting the logs. Rather, teams are busy on making the pipeline work and managing Jenkins.

Scaling Jenkins in Kubernetes Is Not Trivial

Running Jenkins on Kubernetes introduces its own challenges:

• Agent provisioning complexity

• Resource contention with production workloads

• Plugin compatibility issues

• Unpredictable pipeline failures

• Heavy operational overhead

Kubernetes scales applications naturally. Jenkins requires significant effort to scale reliably in the same environment.

This often results in:

• Over-provisioned clusters

• Reserved capacity for CI/CD

• Slower feedback loops

This not only impact the delivery timelines but also cost the teams in different ways. For example, hiring more engineers just to manage the configs and files, dealing with delayed time-to-market, and much more.

Security and Access Control Become Pipeline Concerns

When Jenkins handles deployments:

• Kubernetes credentials are stored in Jenkins

• Access control lives outside the cluster

• Secrets are injected dynamically

• Audit trails depend on pipeline logs and that too shallow audit trails

This creates risks:

• Over-privileged credentials

• Limited visibility into who deployed what

• Hard-to-enforce environment boundaries

In Kubernetes-native CD tools, these concerns are handled at the platform level.
In Jenkins, they are handled at the script level.

That difference matters.

Jenkins Has No Native Concept of Application Lifecycle

Jenkins understands jobs and builds. Anything that is beyond that, Jenkins simply doesn’t care about it.

Modern applications require:

• Environment promotion

• Rollback strategies

• Deployment history

• Health-based deployments

• Multi-cluster visibility

To support this in Jenkins, teams invent:

• Naming conventions

• Folder structures

• Parameterized jobs

• Manual governance processes

This works until it becomes brittle.

Jenkins Is Still Great at CI; Just Not CD

None of this means Jenkins should be abandoned entirely. Jenkins still plays a crucial role when it comes to deployments on VM machines, or for monolith applications. But when it comes to Kubernetes deployments, Jenkins simply is not the right choice.

A more sustainable approach looks like this:

Jenkins for CI:

• Builds

• Tests

• Image creation

Kubernetes-native tools for CD

• Declarative deployments

• GitOps workflows

• Drift detection

• Rollbacks

• Environment management

This separation reduces complexity and aligns tools with what they do best.

Why Teams Are Looking for Jenkins Alternatives

Teams searching for Jenkins alternatives are usually not unhappy with CI.

They are struggling with:

• Kubernetes deployments

• Operational overhead

• Pipeline sprawl

• Security concerns

• Scaling delivery safely

• Audit trails

• Day-2 operations on Kubernetes

• Poor visibility of workloads

Platforms like Devtron exist because these problems are common, not theoretical. They move deployment concerns out of pipelines and into platforms designed for Kubernetes.

For teams that already have significant investment in Jenkins, migration is often the hardest part. This is where structured migration approaches become useful.

Devtron, for instance, is running a Jenkins migration program aimed at helping teams move legacy Jenkins pipelines toward Kubernetes-native CI/CD setups without breaking existing delivery workflows. The focus is on modernization and operability, not a rip-and-replace exercise. It offers:

• Guided Onboarding & Setup

• Free Devtron Enterprise for 6 months

• Support 24x7 Always On

Final Takeaway

Jenkins helped define the Continuous Integration (CI) but Kubernetes changed how applications are deployed. Using Jenkins as a Continuous Deployment (CD) tool in Kubernetes often leads to:

• Hidden complexity

• Fragile pipelines

• Operational drag

The question is no longer:

“Can Jenkins deploy to Kubernetes?”

It’s:

“Should it?”

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.

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

2. 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.

3. 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.

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.

But, Is Kubernetes a forte of Developers? The answer is No! Developers are not meant to learn Kubernetes concepts, commands, etc and deploy their applications over Kubernetes. Enforcing developers to do what they are not meant to be doing may result in -

• Delayed delivery of applications

• Decreased productivity

• Unnecessary Stress & Burnouts

Now the question arises, how to empower developers with Kubernetes deployments?

Can Developers Deploy on Kubernetes?

Yes, Developers can deploy on Kubernetes!

Developers require an abstraction over the infrastructure layer, which should be a unified platform where they can deploy their code in different environments without being proficient in the domain. The platform should have the following features to empower Developers with deployments -

• Unified Dashboard for all the operations

• Debugging & Observability capabilities

• Handy enough to operate with no/bare-min knowledge in k8s

• Capability to build images from multiple branches, tags, PR, etc

• Easy to integrate and run test cases, check code quality, etc

• Deploy on multiple environments without writing/learning k8s manifests

• Quick CI/CD setup

These are some of the features that a platform should have to empower its Developers. With these abstractions, a developer only needs to know about the branches on which he/she is working, and the rest of the thing will be handled by the platform itself.

Now another question arises, why exactly do we need such a platform when you already have Kubernetes CLI and dashboards?

Why a Unified Platform?

When it comes to deploying your application quickly to a production or dev environment, then Kubernetes makes it really complex to handle that.

E.g. say you're a developer, and you are working on an application, for testing this out you may need a lot of things to be set in prior.

Here are some of the things you'll need -

• A Dockerfile to containerize your application

• You need to push that container image to a registry

• You will create a pod or deployment manifest for Kubernetes

• You will apply those manifest in your cluster with kubectl

• You will expose those deployments application with the help of a service

• Sometimes if you're working with manifests then it may grow in complexity when you start including probes like startup, readiness, and liveness probes.

This all sounds easy to perform, but in between if any one of the steps gets broken then the whole cycle will be messed up. You need everything in between to work properly, and then only you will be able to see your application on a given port. In fact, before going ahead with these steps, you should be proficient in Kubernetes concepts, container registries and cloud concepts which is again not a forte of developers. These are certain things that a developer doesn’t know and learning all these things will take a lot of time which will affect the entire software development process. Now how do we streamline the process? Which platform you can use to improve productivity?

The answer is Devtron! It is a CI/CD platform for Kubernetes that helps you build, test, deploy and debug your applications across the software development lifecycle.

Simplifying Kubernetes Deployments with Devtron

Generally, Developers write their code on their favourite editor, and they will automate the testing covering the edge cases. For testing across the organization one needs to set up automated testing so that whenever a new commit is pushed, the automated testing gets triggered.

Devtron greatly simplifies automated testing for developers. They can easily configure it while creating a build pipeline using the pre-build stage, during the build stage and post-build stage. Devtron comes with some default plugins such as k6 for load testing, Sonarqube for code-quality checks, etc. For more details about the plugins, please refer to the documentation.

With Devtron, developers can easily deploy on the top of the Kubernetes cluster with the help of an intuitive Devtron dashboard. It allows you to easily build, test, deploy and debug your applications through the Devtron interface itself. Apart from these, it also provides you with a lot of flexibility to easily integrate any of your existing stacks like Kibana for logs, with applications deployed through Devtron.

The main benefit here is that you don't have to worry about Kubernetes manifests.

Most of the time, a developer who writes code and works on a feature doesn't want/doesn't know how to write a Kubernetes manifest. Devtron simplifies deployments with ready-to-deploy templates that can be easily configured by the developer just by tweaking some values as per the need and are ready to go. To know more about the Deployment Template, feel free to check out the documentation.

Pro-tip: You don’t have to be an expert with yamls and k8s configs as Devtron provides you with the README of the template where you can learn about all the parameters and how to use it.

What about Debugging & Logging?

One of the most important features that a platform can offer is the ability to debug and check out the logs in real-time. With Devtron, it becomes really easy to check out the logs of micro-services deployed or helm charts deployed. It comes with a default log analyzer which helps you to check out the combined logs of all containers in a particular micro-service.

Devtron also empowers you to easily debug your applications with the features such as - exec into containers, check out events, logs of per pods, application metrics, etc. Here’s a quick sneak-peak into the debugging capabilities of Devtron.

Observability

It enables you to easily check out the CPU usage, Memory usage, Throughput and Latency of the micro-services. For more detailed information on the k8s workloads, just hover over the resource and you would be able to see the options for Manifest, Events, Logs and Terminal.

To expand the details, just click on any of the options available and you will be able to see the entire manifest of the pod, or events if any, logs of the pod and also Devtron enable you to easily get into the container and debug the applications for any issues.

Kubernetes Manifest

Devtron provides you with the easiest possible way to check the manifests of all Kubernetes workloads deployed in that particular microservice.

Exec into Container

The tool also allows users to exec into pods if required for debugging and all that from the intuitive user interface. Users don't have to provide cluster terminal access as everything can be managed by Devtron.

So these are some of the functionalities of Devtron that can help you empower your Developers with Kubernetes Deployments. There are a lot more features that Devtron offers to manage the entire software development lifecycle, helping out Developers and DevOps accelerate their journey of k8s and improve their productivity.

Check out the blog for more insights on how to deploy applications with Devtron. Feel free to connect with me on Twitter and LinkedIn if you have any questions.

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.

[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.

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

K3s & its History

K3s is an opensource, lightweight distribution of Kubernetes which is packaged all in a binary less than 100mb. It was initially launched as component of Rio, an experimental project launched by Rancher Labs, but due to its efficiency and high demand, they launched it as a separate open source project. K3s was officially launched on 26 Feb, 2019. It has been seen a great success of k3s in Edge, IoT, CI, Development, ARM and Embedding K8s. It can be installed as single node as well as multi-node cluster and is fully conformant production-ready Kubernetes distribution.

K3s Architecture

The above image shows the basic architecture of k3s. You can observe that in case of k3s we have two major components, k3s server and k3s agent as like of master node and worker node in k8s. In both server and agent, all other components combined together run as a single process which makes it really lite-weighted unlike in k8s where each component runs as a individual process. In fact in case of single node cluster, both the server and agent can run as a single process in a single node which helps to spin up the cluster within 90s. Most of the components are similar to that used in k8s and their functionalities are also pretty much similar as that of in k8s except SQLite, Tunnel Proxy and Flannel which are introduced in k3s. For detailed understanding of the individual components please have a look at k8s documentation. Talking about SQLite, it is a replacement of etcd which is used in k8s, and removing dependency from etcd allowed running single node cluster with SQLite but its only in case of single node. K3s uses external databases in case of HA k3s cluster. Coming to Tunnel Proxy, basically kube-proxy uses a number of ports for connecting with api-server, but in case of k3s, it connects to api-server with the help of tunnel proxy. Behind the scene, tunnel proxycreates a uni-directional connection to reach out api-server but once the connection is established, bi-directional communication is enabled and this makes a more secure connection by using single port for communication. For cluster networking, Flannel can be seen in the picture which is used as Container Network Interface(CNI) in k3s. So this is a general insight of k3s architecture. For more detailed information please refer to documentation.

Cluster Setup using k3s

Setting up a Kubernetes(k8s) cluster is quite a hectic task but not in the case of k3s. We can easily set up the k3s single node or multi node clusters just within few commands. In this blog, we will discover both the methods starting with single node setup.

Single Node Cluster

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

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

In the above command, we have used an extra flag i.e, --write-kubeconfig-mode. Basically by default the KUBCECONFIG file which is located at /etc/rancher/k3s/k3s.yaml have only read permissions for root user. So we need to make it readable for other users as well (the recommended method). That's all, we have successfully setup our k3s single node cluster.

Multi Node Cluster

Setting up multi node cluster is also very simple in k3s. We can have as many no. of worker nodes for our master in just few commands. Please follow the steps to configure your High Availability(HA) production grade k3s cluster. Step-1. Firstly we need to set up the server as we did in case of single node cluster by using the same command -

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

Step-2. After that, from the below command, we need to find the node-token, which will be further used by the k3s-agent to add as many worker nodes you want for your cluster.

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

Step-3. The next command is used to create a k3s-agent for the master node which we set up from the above command and we will use the Server IP and node-token extracted from the master node. Please replace my-server and node-token from the master node IP and token which we generated from the above command. Please execute the following command in a separate instance/system to make it worker node for the master created.

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

Bingo! We have successfully set up the HA production grade k3s cluster. Now we are ready to begin with our deployments on k3s cluster.

Now, after we understood different ways of setting up the cluster, let's see the advantages of using k3s and does it really used by the industry?

Benefits of k3s

• Quick Installation,

• Less Resources Required,

• Easy to setup cluster,

• Smaller in size,

• Very easy to add/remove nodes, etc. These are some of the advantages of having k3s clusters. Now the question arises, Is it really used in the Industry?

Companies using k3s

Due to its easy configurations and flexible nature as it can support something with as small as Raspberry Pi or something as large as an AWS a1.4xlarge 32GiB server, it is highly adopted by organizations in their production. Some of the companies using k3s are -

• Civo - The cloud native service provider

• Qubitro - IoT platform to design and develop IoT projects.

• LoyaltyHarbour - Provide support for eCommerce stores.

• TWave - Condition Monitoring Systems

• Lunar Ops, Inc - DevOps as a Service company based in Bronx, NY

So, these are few of the companies using k3s in their production.

I hope the blog was worth of your precious minutes you invested. Feel free to like, share and comment down your thoughts about the blog.

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

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.

{% github devtron-labs/devtron no-readme %}

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,

1. Install using script
2. 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.

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, let's 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.