Forem: Devtron

Devtron Year in Review 2024

Akanksha Bhasin — Sun, 05 Jan 2025 07:51:42 +0000

2024 was a breakout year! As we close the 2024 chapter, we reflect on a remarkable year of growth, innovation and collaboration. This year has been filled with exciting milestones, impactful product updates and meaningful engagements with our global community. From receiving prestigious recognitions from AWS, surpassing new heights on GitHub to connecting with the cloud-native community at events worldwide, 2024 has been a year of impact and progress.

🚀 Key Product Updates

This year, we delivered features to address challenges faced by developers and DevOps teams and simplify Kubernetes management for faster, more secure deployments:

Application Deployment & Distribution:
- The new Software Distribution Hub centralizes management for microservices delivery across multiple customers and including air-gapped environments.
- Deployment windows (Blackout & Maintenance windows) were introduced to control deployments and avoid disruptions.
- Approval Groups enforce robust governance and Runtime Input Parameters provide dynamic CI/CD control.
Streamlined Configuration:
- Compare Configuration across environments to prevent drift, Clone CI/CD Workflows, and lock configurations for enhanced security and consistency. Build Infrastructure Configurations for optimized resource utilization.
Cluster Management:
- Minimizing downtime and MTTR using Auto Remediation and reducing manual intervention and faster error resolution. Simplify Kubernetes upgrades with automated compatibility checks using Silver Surfer
- GitOps Listing: Visualize multi-cluster ArgoCD & FluxCD applications for unified management.
Enhanced Security:
- Secure kubectl access providing developers with controlled terminal access using fine-grained RBAC API tokens.
- User Access Management with SSO mapping for simplified administration.
Intelligence & Monitoring:
- Devtron Intelligence (AI-powered error analysis) and centralized dashboards (Grafana, Kibana integration) for a single pane of glass view.

🏊 Dive deeper into a detailed version of product updates from 2024 now.

🌟 A Special Highlight - The launch of Devtron 1.0, a major milestone that transforms Kubernetes operations for enterprises using AI. Unveiled at KubeCon North America, Devtron 1.0 brings powerful new features like AI-driven troubleshooting, enhanced CI/CD workflows, auto-remediation, and robust RBAC to simplify Kubernetes management at scale. This release signifies a leap forward in DevOps automation, offering enterprises a unified platform for managing the entire application lifecycle and ensuring faster, more secure deployments.

🔗 Read more about it here.

🌟 Notable Achievements in 2024 🌟

2024 had been a great year for Devtron. With loads of new users, feedback, features, product enhancement, and community empowerment, the year had been filled with learning and fun.

🏆 Recognition from AWS

A standout moment for us was winning the AWS Rising Star Award (India) and being recognized as a finalist for APJ Technology Partner of the Year, a testament to our commitment to delivering solutions that simplify Kubernetes adoption while driving innovation in cloud-native application management.

AWS Partner Spotlight - Devtron

We highlighted the collaboration between Devtron and AWS, showcasing how our joint solutions streamline Kubernetes management on Amazon EKS.

Checkout this blog and explore how Devtron's powerful DevOps automation platform, integrated with AWS, helps teams improve development efficiency, accelerate software delivery and optimize costs.

🌍 Conferences

Devtron made its mark at several global conferences, connecting with the cloud-native community including AWS re:Invent, KubeCon North America, KubeCon India, US Fintech Symposium, KCD Hyderabad, KCD Washington DC, KCD Kerala, Cloud Native Rejekts, Dine with DevOps and DevOps Conclave & Awards.

👥 Events

We have hosted and participated in various industry-leading events including:

KubeCon India Networking Dinner

With the first ever KubeCon in India this year, we planned an exclusive KubeCon India networking dinner party post-conference on Day 1 in collaboration with Middleware. We welcomed around 180 folks at the event joining us from different parts of the world. We saw over 500+ professionals including founders, managers and DevOps Engineers signing in a short period. 🎉

The attendees exchanged valuable insights over discussions in the Cloud Native ecosystem and enjoyed the most happening DJ night in the town. 🪩

Top Golf Events

We had a great time hosting Top Golf Events at the United States in Atlanta, Austin and Dallas and inviting Kubernetes Practitioners. They enjoyed exchanging insights on Kubernetes strategies, and basking in an evening filled with good food, drinks and a great company.

Webinar with the AWS team & more

Enhancing DevOps Efficiency on Amazon EKS with Devtron - This webinar provided a comprehensive overview of how Devtron simplifies the deployment, management and scaling of Kubernetes applications on Amazon EKS, enabling teams to streamline operations and focus on building.

🔗 Tune in to watch our previous webinars here.

🗣️ Meetups:

Quite an eventful year I would say! We hosted meetups every month across India in Delhi NCR and Bangalore and partnered with organisations and CNCF communities and covered various topics including Kubernetes Cost Optimization, Observability, Software delivery, Platform Engineering, App Modernisation, Containerization, Cloud and more.

Follow our meetup page to stay updated on all the meetups and webinars we host. Do check out some of our past meetups that we have hosted.

We also expanded our footprint with meetups in the U.S. (at Austin, Virginia & Denver). Our team also attended & presented at various meetups across India, some of the notable ones include the KubernTENes Birthday bash meetup celebrating a decade of Kubernetes, DevOps Days, AWS Community Days, GitHub Constellation, GitTogether and more that fostered cloud-native collaborations.

❤️ Community Growth

Reached an incredible 10k+ followers on Linkedin and 4.6k GitHub Stars, a huge thanks to our growing community for the support and love. These valuable connections & conversations are not just memories; they are the building blocks that are guiding our strategic vision for the year ahead.

🎯 Looking Ahead

As we move into 2025, we remain committed to empowering teams with tools that simplify Kubernetes management and accelerate development cycles. With your support, we’re excited to continue this Cloud Native journey of innovation and community building.

Here’s to another incredible year ahead together, let’s redefine what’s possible in the cloud-native world. 🚀

KubeCon India 2024 Recap

Akanksha Bhasin — Thu, 26 Dec 2024 05:30:51 +0000

KubeCon has always been a significant event in the cloud-native ecosystem. After a long journey, India finally had its first KubeCon in Delhi on the 11th and 12th of December. After a long wait, KubeCon was finally organized in India, giving the Indian community an amazing opportunity to attend a KubeCon and network with some of the amazing folks within the industry. India is among the top five countries with the most active contributors, and this number is rapidly growing.

KubeCon India was a remarkable experience, and there were a lot of key takeaways that team Devtron had from the event. Let’s dive into all of the new announcements and learnings from KubeCon India.

Keynote Highlights

The event started with the iconic KubeCon keynotes. The Day 1 keynotes focused on sharing the amazing scaling power of Kubernetes and highlighted the entire Kubernetes journey from its origin, to where it is today, and what is to come. The Day 2 Keynotes focused more on the role of AI in the Kubernetes ecosystem, and the two technologies will continue to integrate. Let’s take a quick recap of the themes that were being discussed.

Service Mesh Adoption at Scale: Purushotham Malipedda and I V Prasad Reddy from Flipkart, one of India’s largest E-commerce websites, took to the stage to explain their journey of adopting a service mesh. They were facing challenges with scaling their workloads and implementing disaster recovery mechanisms. They onboarded Istio and migrated around 6,000 services, giving them the ability to leverage the mesh’s features such as service graphs and securing east-west traffic.
The Cloud Native Story: Nikhita Raghunath from VMware in her keynote walked through the entire journey of Kubernetes and cloud-native, and how it has evolved over the years. From the creation of the first containers to Kubernetes and where it has evolved from there. We’ve moved over to a standardized container runtime i.e. CRI, and even have the WASM runtime. Kubernetes has matured into a stable technology that folks are beginning to adopt. Nikita shared that the next few years of Kubernetes are going to be all-around optimization, from cost to performance, as well as improving the multi-cloud strategy.
The Unison of Cloud Native and AI: During the Keynotes of Day 2, AI was all the hype. Aparna Subramanian and Sumedh Degaonkar from Shopify talked about how they searched and found Kubernetes to be the perfect orchestration tool for deploying their AI and ML workloads. Arun Gupta from Intel walked through CNCF’s AI Working Group and talked about the entire cloud native AI landscape and how it’s evolving. Finally, Janakiram talked about how they orchestrated AI agents in Kubernetes using the built-in Kubernetes properties such as CustomResourceDefinitions, StatefulSets, and HorizontalPodAutoscalers.

[Fig.1] Keynote Sessions

Recommended Sessions to Watch

KubeCon India had a plethora of talks on AI, WASM, Operational optimization, and much more. While there was a ton of information to learn from the talks, a few stood out. We recommend rewatching some of the following talks once they are out.

How a Small Step turned into a Giant Leap to Cloud Native Adoption for an Enterprise: Ashwin Gupta and Shubham Bansal, from Fidelity share their entire journey on how they adopted the cloud and cloud-native technologies. Initially, they started using open-source technologies and now, they have an entire stack of OSS tools from Kubernetes, Argo, Elastic, Helm, Cilium, and many more. This talk highlights all of the challenges that global financially regulated organizations can face when adopting Open Source technologies and the learnings Fidelity had along the way,
Optimizing 5G Networks: Deploying AI/ML Workloads with AIMLFW of O-RAN SC: Subash Kumar Singh from Samsung explored the AI/ML Framework (AIMLFW) within O-RAN SC (O-RAN Software Community) community. It was designed for dynamic and efficient 5G network management. This talk covered some of the core challenges in AI/ML workflows for distributed 5G networks, and how to overcome them.
Ensuring Seamless Service Continuity in 5G: Enhancing Kubernetes Disaster Recovery in Telecom: Ganesh Chandrasekaran and Saurabh Swaraj from Samsung’s R&D department highlighted the importance of having proper service availability in the telecom industry and the importance of making local and geographic redundancy for disaster recovery. This session explores a Kubernetes native solution to bridge the gap between existing tools such as Velero, Portworx, and Stash and offer seamless redundancy for telecom workload. This talk walks through some CNCF projects including Nephio for intent-based automation and Prometheus for real-time Monitoring in the Telco space.
Is GitOps a Broken Experience? Where’s the Ops in GitOps?: Rajalakshmi Kamath V from VMWare delved into the limitations of GitOps in large-scale Kubernetes environments. The talk focused on GitOps’ inability to provide real-time visibility into the actual state of the system or immediate operational control during outages. Drawing from Walmart’s experience managing over 200,000 workloads and 10,000 daily deployments across thousands of clusters, the session highlighted the need for complementary operational tools. These tools enhance observability and runtime state insights, bridging critical gaps in GitOps workflows and ensuring greater resilience and efficiency in managing Kubernetes workloads.
Scaling Private LLM Model Services with Kserve and Modelcar OCI: A Real-World Implementation: Mayuresh Krishna from Initializ highlighted how Kubernetes, Kserve, and Modelcar OCI storage simplify the deployment and scaling of private LLM services. The talk addressed the challenges of complexity and cost and demonstrated how Kserve enables efficient, scalable model serving with optimized GPU utilization and how Modelcar OCI artifacts streamline artifact delivery by reducing duplicate storage, enhancing download speeds, and minimizing governance overhead.
GenAI Recipes for Cloud Native Deployment: Arun Gupta and Kaushal Desai introduced OPEA, the Open Platform for Enterprise AI, that provides a framework of composable microservices for deploying GenAI applications. It showcased the process for deploying systems like ChatQnA, CodeGen, and RAG on Kubernetes across various Cloud Providers. The session showed the use of diverse data stores, including open-source vector databases and managed services, and highlighted scale testing with over 50,000 documents.
Faster Deployments at PepsiCo with Self-SErvice Continuous Delivery using the App of Apps Pattern: Chaitanya and Prasanti Kadiyala from PepsiCo transitioned to the GitOps methodology using ArgoCD for streamlining the deployment workflows. They leveraged ArgoCD's App of Apps pattern, to define a bootstrapper Application, enabling the automation of application deployment which allowed them to achieve self-service Continuous Delivery, empowering teams to independently manage their deployments while maintaining centralized control and visibility. This talk highlights the various challenges while adopting GitOps including managing dependencies, configuring environments and ensuring consistency across deployments.

Devtron at KubeCon India

[Fig.2] Team Devtron at KubeCon India

The Devtron team had attended KubeCon India, with high spirits and a secret plan in the works. During the main conference, we had some amazing conversations with folks who have been involved in the tech and cloud-native landscape for decades. Some of the memorable conversations we had have been around Platform Engineering, Kubernetes Challenges, WASM, Observability, and how the cloud-native landscape has evolved over the past couple of years.

Close to the end of the first day of the event, Devtron’s secret plan had begun execution. We organized a memorable networking party with our friends at Middleware. It was an evening full of insightful industry conversations, where founders, engineering managers, and Kubernetes experts from various companies came together over dinner to exchange ideas and foster new connections. Later we threw a DJ night and it was the most happening party in the town ever!

Here are some pictures to help attendees relive the excitement, and for folks who couldn’t make it, we hope to see you at the next KubeCon.

Conversations with Industry Veterans

In the two exciting days of KubeCon, we were also able to interview some people who are working on some groundbreaking technologies and who have been involved in the landscape for years to ask them their thoughts on where the industry is headed as a whole.

Please check out our YouTube channel to hear our conversations and gain insights into the direction of Kubernetes and cloud-native.

See you all at our next event!

Best 5 Alternatives to Kubernetes Dashboard

Akanksha Bhasin — Wed, 30 Oct 2024 17:23:44 +0000

While Kubernetes excels at scaling and operating systems efficiently, at larger scales the complexities of Kubernetes hamper the operational efficiency of teams. Key challenges emerge when organizations manage multiple clusters across regions, primarily relying on traditional command-line tools like kubectl. The absence of comprehensive visibility and frequent context switching between clusters for routine tasks significantly impacts productivity, making cluster management increasingly challenging at scale.

To eliminate the operational challenges of Kubernetes and provide an ease of managing Kubernetes clusters the Kubernetes dashboard was introduced. The Kubernetes dashboard is a web-based interface for managing your Kubernetes clusters. The Kubernetes dashboard provides a visual overview of your Kubernetes clusters and their workloads. You can use the Kubernetes dashboard to deploy containerized applications, troubleshoot your containerized applications, and manage the cluster resources. To read more about the Kubernetes dashboard refer to this blog.

In this blog, we will discuss powerful alternatives to the Kubernetes dashboard and examine their features and capabilities.

Why to Look for Alternatives to Kubernetes Dashboard

The default Kubernetes dashboard offers basic visualization and operational capabilities for infrastructure management. However, it falls short of being a comprehensive Kubernetes management solution. Some of the key limitations of the default Kubernetes dashboard are:

Limited Multi-Cluster Management : The default Kubernetes dashboard is designed to manage single clusters, making it inefficient for organizations running multiple clusters across different regions. Teams need a unified view to manage and monitor all clusters from a single interface.
Lack of Advanced Analytics : The native dashboard provides basic metrics and visualization capabilities, lacking advanced analytics, and detailed insights needed for effective resource optimization and troubleshooting at scale.
Limited Access Management Support : The dashboard does not provide a user-friendly way to implement fine-grained RBAC policies. Even with a Kubernetes dashboard, you need to manage robust RBAC through complex CLI tools.
Limited Dashboard Functionality : The default Kubernetes dashboard provides basic cluster visualization and simple operations but lacks advanced features like real-time monitoring, robust troubleshooting tools, and integrated logging capabilities, requiring administrators to use multiple external tools for comprehensive cluster management.

Alternatives to Kubernetes Dashboard

1. Devtron

Devtron’s Kubernetes dashboard is a modern Kubernetes management platform that provides operational efficiency over multiple Kubernetes clusters. The Devtron’s Kubernetes dashboard provides 360-degree visibility for the resources of your multiple Kubernetes clusters. Along with the visibility the dashboard provides capabilities like taking actions like visualizing and editing live Manifests, checking Events, and Logs, and a dedicated Terminal for debugging specific pods, which helps teams in troubleshooting tasks.

When it comes to managing access to your multiple Kubernetes clusters, Devtron’s Kubernetes dashboard simplifies the RBAC and provides you with the capability to configure robust and fine-grained access control through an intuitive UI. Devtron also provides support for seven SSOs to facilitate access to your Kubernetes infrastructure.

Devtron's Kubernetes dashboard extends its capabilities with comprehensive application management across Kubernetes clusters. Devtron comes with an in-built marketplace for Helm applications that streamlines the configuration and deployment of Helm applications. Beyond Helm support, Devtron provides unified visibility for applications deployed through tools like ArgoCD and FluxCD applications, offering a centralized view of all applications running within specific Kubernetes clusters.

Overview:

Multi-Cluster Operations Hub - Centralized dashboard providing 360-degree visibility and operational control across multiple Kubernetes clusters, enabling efficient management of distributed infrastructure from a single platform.
Advanced Troubleshooting Suite - Comprehensive debugging features like live manifest visualization/editing, event monitoring, real-time log streaming, and integrated pod terminal access for quick problem resolution.
Enterprise-Grade Access Control - Simplified RBAC management through intuitive UI with fine-grained access control capabilities and support for seven SSO providers, making Kubernetes infrastructure access both secure and convenient.
Unified Application Management - Built-in Helm marketplace for streamlined application deployment, plus integrated visibility for GitOps tools (ArgoCD, FluxCD), providing centralized control over all applications across clusters.

Streamline your Kubernetes workflow with Devtron's intuitive dashboard and check out their GitHub repository to get started.

2. OpenLens

OpenLens is an open-source distribution of the popular Lens IDE. It’s specifically tailored for those who want the Lens experience but with more flexibility and less vendor lock-in. OpenLens is lightweight, user-friendly, and provides a powerful visual interface for managing Kubernetes clusters. OpenLens focuses on providing a streamlined experience, making it easier to manage and troubleshoot clusters without the overhead.

OpenLens focuses on providing a simpler, more streamlined experience, making it a good choice for those who prefer a more lightweight tool without sacrificing power.

Overview:

Multi-Cluster Management - Unified view and management of multiple K8s clusters through a single pane of glass. Which enables teams to perform quick switches between clusters and consolidated monitoring across your entire K8s infrastructure.
Real-Time Resource Visualization - Interactive graphical displays of pod status, resource usage, and cluster metrics with drill-down capabilities for detailed analysis of containers, logs, and events in real-time
Built-in Terminal Access - Direct terminal access to containers and nodes from within the UI, allowing quick debugging and troubleshooting without needing to switch between tools or use kubectl commands separately.

3. Skooner

Skooner (formerly K8Dash) is a web-based Kubernetes dashboard that offers a clean and straightforward interface for managing your clusters. It’s designed to be fast and intuitive, making it a great choice for teams that need a simple yet powerful tool. Skooner keeps things simple, focusing on what matters most—efficient cluster management.

Skooner shines when you need a quick and easy way to monitor and manage your Kubernetes clusters without getting bogged down in complex features.

*Overview: *

Resource-Centric Navigation - Skooner provides an Intuitive navigation capability around K8s resources (pods, services, deployments) with quick filters and search capabilities that make it easier for you to find and manage specific components in large Kubernetes clusters.
Live Health Monitoring - Real-time health status indicators for all resources with visual alerts for issues, enabling you to quickly spot and respond to problems across namespaces and resource types.
Lightweight & Fast Interface - Minimalist, performance-focused design that loads and updates quickly even with large clusters, making it more responsive than the default dashboard for day-to-day operations.

4. Headlamp

Headlamp is another excellent alternative to the default Kubernetes dashboard, offering a more developer-centric approach to Kubernetes management. It’s open-source, with a focus on providing a great user experience for those working directly with Kubernetes. Headlamp is particularly well-suited for development teams who need quick access to the details of their clusters without dealing with the complexities of the CLI tool.

Headlamp offers a clean and intuitive UI, providing a refreshing alternative that’s easier to navigate.

Overview:

Developer-Focused - Designed with developers in mind, offering quick access to necessary tools.
Multi-Cluster Management - Seamless handling of multiple clusters with easy switching and unified view, while maintaining separate contexts and configurations for each cluster.
Resource Editing & Management - Direct YAML editing and updating of Kubernetes resources through the UI, with validation and preview capabilities before applying changes to prevent configuration errors.

5. Octant

Octant is a highly visual, open-source tool designed for inspecting and understanding Kubernetes clusters. It’s particularly strong in providing insights into what’s happening within your clusters, making it a valuable tool for debugging and troubleshooting. Octant offers a more in-depth view of your Kubernetes environment compared to the default Kubernetes dashboard.

Overview:

Plugin Extensibility - Built-in plugin system supporting integration with tools like Helm, Starboard, and Knative, allowing developers to extend functionality beyond basic Kubernetes operations based on their needs.
Resource Viewer & Navigation - Comprehensive view of workloads and resources within namespaces, with filtering capabilities and real-time status updates of applications, making it easier to monitor and manage Kubernetes cluster resources.

Conclusion

While the default Kubernetes dashboard provides a basic interface for managing Kubernetes clusters, its limitations in multi-cluster management, advanced analytics and role-based access control. Tools like Devtron, OpenLens, Skooner, Headlamp and Octant offer enhanced capabilities that address these shortcomings, providing users with improved visibility, streamlined operations, and better troubleshooting features. By adopting these alternatives, organizations can significantly enhance their operational efficiency and effectively manage their Kubernetes environments at scale.

Additional Resources to Read

If you have any questions, or want to discuss any specific usecase, feel free to connect with us or ask them in our actively growing Discord Community.

Happy Deploying!

SSO and RBAC: A Secure Access Strategy for your Kubernetes

Devtron — Fri, 16 Aug 2024 03:12:22 +0000

In the ever-evolving world of cloud-native computing, Kubernetes has emerged as a standard solution for container orchestration. However, managing access control across multiple Kubernetes clusters can quickly become a complex task, especially in large organizations with numerous teams and members. This is where the power of Single Sign-On (SSO) and Role-Based Access Control (RBAC) comes into play, providing a secure and efficient solution for access management.

Authentication/Authorization

The very first way to secure something in the digital world is to set authentication and authorization. The authentication can be handled by SSO, and the authorization can be done through RBAC for the Kubernetes environment.

The Challenge of Manual Access Control

Imagine yourself as a seasoned DevOps engineer in a fast-paced cloud-native organization, responsible for managing access control across 50 Kubernetes clusters. Multiple teams are collaborating and performing deployments on these clusters at lightning speed. Manually managing access for all team members across all clusters can quickly become a nightmare.

Traditionally, you would need to distribute Kubeconfig files among team members, granting them access to specific clusters. However, this approach has potential security risks because misconfigurations or misplaced files can leave clusters vulnerable to data breaches and unauthorized access. Additionally, manual RBAC configuration for each cluster is time-consuming, error-prone, and lacks fine-grained control. So when managing access control over large numbers of Kubernetes clusters using traditional methods, you can end up with the following:

Vulnerable clusters: Team members need to have a kubeconfig file for each cluster to access it. Any misconfiguration in these files can leave clusters vulnerable to data breaches and security threats.
Distribution of Kubeconfig: Sharing Kubeconfig files with team members is a challenge. An accidental leak or unauthorized access can compromise the entire cluster.
Complex RBAC: In the Kubernetes cluster, you need to configure the RBAC manually. This process is time-consuming and error-prone. With this, you may not get proper, fine-grained control over your Kubernetes cluster.

These are some major challenges that you may face when you choose to manage multiple clusters manually. And definitely, you don't want to spend time navigating through these complexities rather than focusing on what truly matters: efficient deployments and innovation.

Single Sign-On (SSO) for Authentication

SSO provides ease to the process of authentication by leveraging the concept of federated identity. Users can authenticate themselves using the existing credentials from identity providers. Using an authentication based on SSO for accessing all Kubernetes clusters. SSO will eliminate the need for distributing and managing multiple kubeconfig files to access the Kubernetes cluster, along with reducing the risk of unauthorized access to your clusters.

We Devtron, a platform for managing your Kubernetes environments, offers an SSO solution. It's tailored specifically for Kubernetes workflows. Devtron with SSO provides you with the ease of accessing all authorized clusters with a single click. You can log in to Devtron with your single set of credentials (e.g., Google, GitHub, GitLab, etc.) and access all your Kubernetes clusters on the Devtron dashboard. So no more juggling with complex Kubeconfig files and static tokens. Devtron sprints for one extra mile; understanding the preferences and needs of every organization can be unique. For that, Devtron offers seven SSO integrations. Empowering organizations and users to choose the SSO that perfectly aligns with their existing infrastructure and security practices. Devtron offers SSO with most of the providers which can be used for authentication. Here are some of them.

Configure SSO with Google, GitHub, GitLab, Microsoft, LDAP, OIDC, and OpenShift. You can also integrate other identity and access management tools like Okta and Keycloak for managing user permissions.

Fine-Grained Access Control with RBAC - Authorization

While SSO solves the authentication challenge for you. RBAC addresses the authorization aspect by allowing you to define granular permissions and restricting access to cluster resources for users. In Kubernetes, you can define roles, cluster roles, role bindings, and cluster role bindings to control access at both the namespace and cluster levels. While setting the manual configuration, you can face issues like:

Error-Proneness and Complexities: Configuring a vast number of roles and permissions in Kubernetes makes it difficult to configure them all accurately. You can face the issue of inconsistent configuration.
Scalability: To allow a new team member to access your cluster, you need to configure the RBAC again. Imagine doing this for each new member and every new cluster. Manually configuring RBAC results in inefficiency.
Security Concerns: While configuring the RBAC manually, there are chances of granting more user access than is required. These will allow users to access sensitive resources like the production database. Now think you mistakenly granted permission to users for databases, and users will fire a delete query on that.

Devtron simplifies this process by providing a graphical user interface (GUI) for managing RBAC. RBAC in Devtron is specifically designed for the workflow of Kubernetes. It allows the administrator to manage access to Kubernetes clusters, environments, and all resources in the cluster. Ensures least-privileged access and creates a secure environment by defining roles and restricting access for other users. Devtron allows you to manage fine-grained access control down to the Kubernetes cluster resource level. You can grant users precise permissions for specific resources in the cluster. The User Access Management feature in Devtron allows you to add other users, like support engineers', and manage their access on your Devtron dashboard. You can mark the status of users as ‘Active’, ‘Inactive’, or ‘Keep active until’ (TTL). This feature gives you control over how other qualified users access your Devtron dashboard.

The Power of SSO and RBAC Combined

By combining SSO and RBAC, organizations can achieve a robust and secure access control strategy for their Kubernetes environments. This combination offers several benefits:

Enhanced Security

SSO for the Kubernetes environment allows you to centralize the process of authentication. Allowing you to use already-existing credentials to access all authorized clusters. SSO removes the chances of clusters getting compromised due to some misconfigurations or misplaced kubeconfig files.
RBAC allows super admins to define fine-grind permissions for users to access clusters and resources. RBAC is an authorization for your Kubernetes environment that restricts unauthorized users from accessing resources that are not permitted. This adds a layer of security post-SSO.
Setting RBAC and SSO manually for your Kubernetes environment can bring complexities. To simplify the process of setting SSO and RBAC, you can look at tools like Devtron. In Devtron, you can set SSO and RBAC both using a single dashboard and without any complexities.

Improved Manageability

Managing multiple clusters across various environments becomes simpler with SSO. Administrators can centrally manage access for clusters rather than configuring each cluster separately.
With RBAC, administrators can also optimize the Kubernetes environments for cost. Using RBAC, they can restrict user access and utilization of resources.

Scalability and Flexibility

SSO and RBAC can keep up with the scale of your Kubernetes environments. SSO and RBAC provide a robust framework to manage the scale of users and Kubernetes clusters. With the increased number of users, administrators can authenticate them using their Active Directory and use RBAC to allocate permissions and define roles.
Devtron allows administrators to map their existing Active Directory with Devtron SSO. With this, they can authenticate and allow team members to access all authorized microservices with a single click. Along with this, they can apply predefined roles and permissions to them. All of these are possible from a single dashboard.

Conclusion

In the dynamic world of cloud-native computing, securing access to Kubernetes clusters is paramount. By leveraging the power of SSO and RBAC, organizations can streamline access management, enhance security, and ensure efficient collaboration across teams. Devtron offers a comprehensive solution, simplifying the implementation of SSO and RBAC while providing a centralized dashboard for access control management. Embrace the simplicity and security of SSO and RBAC in your Kubernetes environment, and empower your teams to innovate with confidence.

Devtron's RBAC can also be extended and can be used for more secure and controlled kubectl access. Users don't have to log in to the dashboard and can use kubectl commands which would be proxied through Devtron with limited access and api-tokens given for the respective user. To learn more, check out this blog about control and secure kubectl access.

If you have any queries, don't hesitate to connect with us. Join the lively discussions and shared knowledge in our actively growing Discord Community.

12 Tools to make Kubernetes management easier in 2024

Akanksha Bhasin — Mon, 12 Aug 2024 15:55:15 +0000

Kubernetes, the revolutionary container orchestration platform, has empowered developers to build, deploy, and scale applications with unparalleled flexibility and efficiency for a decade. But let's be honest, Kubernetes' sheer scale and complexity can sometimes feel overwhelming, even for seasoned DevOps engineers. You're still battling tangled deployments, resource conflicts, and security concerns frequently. Developers may face distractions from core application development due to manual operational tasks and the steep learning curve.

But fear not, Intrepid CloudNative Warriors! This blog post is your guide to navigating the intricate world of Kubernetes with ease. We'll explore 12 essential tools that streamline workflows, boost efficiency, and make managing your Kubernetes management easier in 2024.

But Wait! Why Simplify Kubernetes - Management?

Let's face it, modern applications are demanding. You're juggling containerized workloads, scaling for peak usage, and ensuring everything runs smoothly. This is where efficient management tools come in, offering these crucial benefits:

Reduced Complexity: No more wrestling with Kubectl commands or endless configuration files. These tools offer intuitive interfaces and automated processes that make your life easier.
Increased Efficiency: Let's be real, you're a busy person. These tools automate repetitive tasks and streamline workflows, freeing you up to focus on problem-solving & innovation.
Enhanced Security: Security is non-negotiable. Dedicated security tools proactively scan for vulnerabilities, enforce policies, and help you keep your applications and infrastructure safe from harm.
Improved Cost Optimization: You want to make the most of your resources and cost analyzers and autoscale help you optimize resource utilization, preventing over-provisioning and saving you money.

Now that we've recognized the significance, let's delve into 12 essential tools that streamline Kubernetes management.

1. KEDA

Keda (Kubernetes Event-Driven Autoscaling) is an event-driven autoscale for Kubernetes workloads. Simply defined, it can scale an application based on the number of events needing to be handled.

Installing KEDA

KEDA has well-documented steps for installation in their documentation. You can install it with Helm, Operator Hub, or YAML declarations. In this blog, let's go with the helm.

Step 1: Add Helm Repo

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

Step 2: Update Helm Repo

helm repo update

Step 3: Install KEDA in keda Namespace

helm install keda kedacore/keda --namespace keda --create-namespace

Use Cases

KEDA is a classic example of autoscaling based on different metrics. When you want to autoscale your application beyond the resource metrics like CPU/ Memory, you can use KEDA. It listens to specific events such as messages from message queues, HTTP requests, custom Prometheus metrics, Kafka lag, etc. To deep dive into KEDA, check out this blog.

2. Karpenter

Built in AWS, Karpenter is a high-performance, flexible, open-source Kubernetes cluster auto-scaler. One of its key features is the ability to launch EC2 instances based on specific workload requirements such as storage, compute, acceleration, and scheduling needs.

Installation

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

Step 1: Install Utilities

Karpenter can be installed in clusters using a Helm chart. Install these tools before proceeding:

AWS CLI
kubectl - the Kubernetes CLI
eksctl (>= v0.180.0) - the CLI for AWS EKS
helm - the package manager for Kubernetes

Configure the AWS CLI with a user that has sufficient privileges to create an EKS cluster. Verify that the CLI can authenticate properly by running aws sts get-caller-identity.

Step 2: Set Environment Variables

After installing the dependencies, set the Karpenter namespace, version and Kubernetes version as follows.

export KARPENTER_NAMESPACE="kube-system"
export KARPENTER_VERSION="0.37.0"
export K8S_VERSION="1.30"

Then set the following environment variables which would be further used for creating an EKS cluster.

export AWS_PARTITION="aws" # if you are not using standard partitions, you may need to configure to aws-cn / aws-us-gov
export CLUSTER_NAME="${USER}-karpenter-demo"
export AWS_DEFAULT_REGION="us-west-2"
export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"
export TEMPOUT="$(mktemp)"
export ARM_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-arm64/recommended/image_id --query Parameter.Value --output text)"
export AMD_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2/recommended/image_id --query Parameter.Value --output text)"
export GPU_AMI_ID="$(aws ssm get-parameter --name /aws/service/eks/optimized-ami/${K8S_VERSION}/amazon-linux-2-gpu/recommended/image_id --query Parameter.Value --output text)"

Step 3: Create a Cluster

The following configs will create an EKS cluster with the user configured in aws-cli having the relevant permissions to create an EKS cluster.

curl -fsSL https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > "${TEMPOUT}" \
&& aws cloudformation deploy \
  --stack-name "Karpenter-${CLUSTER_NAME}" \
  --template-file "${TEMPOUT}" \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides "ClusterName=${CLUSTER_NAME}"

eksctl create cluster -f - <<EOF
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_DEFAULT_REGION}
  version: "${K8S_VERSION}"
  tags:
    karpenter.sh/discovery: ${CLUSTER_NAME}

iam:
  withOIDC: true
  podIdentityAssociations:
  - namespace: "${KARPENTER_NAMESPACE}"
    serviceAccountName: karpenter
    roleName: ${CLUSTER_NAME}-karpenter
    permissionPolicyARNs:
    - arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}

iamIdentityMappings:
- arn: "arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}"
  username: system:node:{{EC2PrivateDNSName}}
  groups:
  - system:bootstrappers
  - system:nodes
  ## If you intend to run Windows workloads, the kube-proxy group should be specified.
  # For more information, see https://github.com/aws/karpenter/issues/5099.
  # - eks:kube-proxy-windows

managedNodeGroups:
- instanceType: m5.large
  amiFamily: AmazonLinux2
  name: ${CLUSTER_NAME}-ng
  desiredCapacity: 2
  minSize: 1
  maxSize: 10

addons:
- name: eks-pod-identity-agent
EOF

export CLUSTER_ENDPOINT="$(aws eks describe-cluster --name "${CLUSTER_NAME}" --query "cluster.endpoint" --output text)"
export KARPENTER_IAM_ROLE_ARN="arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}-karpenter"

echo "${CLUSTER_ENDPOINT} ${KARPENTER_IAM_ROLE_ARN}"

Unless your AWS account has already been onboarded to EC2 Spot, you will need to create the service-linked role to avoid the ServiceLinkedRoleCreationNotPermittederror.

aws iam create-service-linked-role --aws-service-name spot.amazonaws.com || true
# If the role has already been successfully created, you will see:
# An error occurred (InvalidInput) when calling the CreateServiceLinkedRole operation: Service role name AWSServiceRoleForEC2Spot has been taken in this account, please try a different suffix.

Step 4: Install Karpenter

# Logout of helm registry to perform an unauthenticated pull against the public ECR
helm registry logout public.ecr.aws

helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version "${KARPENTER_VERSION}" --namespace "${KARPENTER_NAMESPACE}" --create-namespace \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.interruptionQueue=${CLUSTER_NAME}" \
  --set controller.resources.requests.cpu=1 \
  --set controller.resources.requests.memory=1Gi \
  --set controller.resources.limits.cpu=1 \
  --set controller.resources.limits.memory=1Gi \
  --wait

Once the installation is done, you can create NodePool and define the instance family, architecture, and start using Karpenter as your cluster autoscaler. For detailed installation information and its usage, feel free to refer to its documentation.

Use Cases

Karpenter is used to automatically provision and optimize Kubernetes cluster resources, ensuring efficient and cost-effective scaling. It dynamically adjusts node capacity based on workload demands, reducing over-provisioning and underutilization, thus enhancing performance and lowering cloud infrastructure costs. Check out this blog to understand in-depth about Karpenter and Cluster Autocaler.

3. Devtron

Devtron is a tool integration platform for Kubernetes and enables swift app containerization, seamless Kubernetes deployment, and peak performance optimization. It deeply integrates with products across the lifecycle of microservices i.e., CI/CD, security, cost, debugging, and observability via an intuitive web interface.

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

Installation

Run the following command to install the latest version of Devtron along with the CI/CD module:

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

helm repo update devtron

helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd \
--set installer.modules={cicd}

Check out the complete guide here. If you have questions, please let us know on our discord channel.

Use Cases

Devtron simplifies Kubernetes adoption by addressing key challenges, making it easier to deploy, monitor, observe, and debug applications at scale.

Here's how Devtron helps:

1. Simplifying the Adoption Process:

Single Pane of Glass: Provides a unified view of all Kubernetes resources, enabling easy navigation and understanding of cluster components.
Real-Time Application Status Monitoring: Displays the health and status of applications in real time, highlighting potential issues and unhealthy components.
Simplified Debugging: Offers tools like event logs, pod logs, and interactive shells for debugging issues within the Kubernetes environment.
Containerization Made Easy: Provides templates and options for building container images, simplifying the containerization process for various frameworks and languages.

2. Streamlining Tool Integration:

Helm Marketplace: Integrates with the Helm chart repository to easily deploy and manage various Kubernetes tools.
Built-in Integrations: Offers native integrations with popular tools like Grafana, Trivy, and Clair for enhanced functionality.

3. Simplifying Multi-Cluster/Cloud Workloads:

Centralized Visibility: Provides a unified view of applications across multiple clusters and cloud environments, enabling consistent management.
Environment-Specific Configurations: Allows setting environment-specific configurations, making it easier to manage applications in diverse environments.

4. Simplifying DevSecOps:

Fine-Grained Access Control: Enables granular control over user permissions for Kubernetes resources, ensuring secure access.
Security Scanning and Policies: Offers built-in security scanning with Trivy and allows configuring policies to enforce security best practices.

4. K9s

K9s is a terminal-based UI to interact with your Kubernetes clusters. This project aims to make it easier to navigate, observe, and manage your deployed applications in the wild. K9s continually watch Kubernetes for changes and offer subsequent commands to interact with your observed resources.

Installation

K9s is available on Linux, macOS, and Windows platforms. You can get the latest binaries for different architectures and operating systems from the releases on GitHub.

MacOS/ Linux

 # Via Homebrew
 brew install derailed/k9s/k9s

Windows

# Via chocolatey
choco install k9s

For other ways of installation, feel free to check out the documentation of K9s.

Use Cases

K9s make it much easier as compared to other Kubernetes clients like kubectl to manage and orchestrate applications on Kubernetes. You get a terminal-based GUI which helps you manage your resources,

Resource Monitoring and Visibility : It provides continuous monitoring of your Kubernetes cluster, offering a clear view of resource statuses. It helps you understand your K8s cluster by displaying information about pods, deployments, services, nodes, and more. With K9s, you can easily navigate through cluster resources, ensuring better visibility and awareness.
Resource Interaction and Management : K9s allows you to interact with resources directly from the terminal. You can view, edit, and delete resources without switching to a separate management tool. Common operations include scaling deployments, restarting pods, and inspecting logs. You can also initiate port-forwarding to access services running within pods.
Namespace Management : This lets you focus on specific namespaces within your cluster. You can switch between namespaces seamlessly, making it easier to work with isolated environments. By filtering resources based on namespaces, you can avoid clutter and stay organized.
Advanced Features : It also offers advanced capabilities, such as opening a shell in a container directly from the UI. It supports context switching between different clusters, making it convenient for multi-cluster environments. Additionally, K9s integrate with vulnerability scanning tools, enhancing security practices.

5. Winter Soldier

Winter Soldier is an open-source tool from Devtron, it enables time-based scaling for Kubernetes workloads. The time-based scaling with Winter Soldier helps us to reduce the cloud cost, it can be deployed to execute things such as:

Batch deletion of the unused resources
Scaling of Kubernetes workloads

If you want to dive deeper into it, please check the following resources -

Installation steps - https://devtron.ai/blog/winter-soldier-scale-down-your-infrastructure-in-the-easiest-possible-way

Please star us on our Github: https://github.com/devtron-labs/winter-soldier

Use Cases

Winter Soldier is a valuable tool for anyone who wants to:

Optimize Cloud Costs: By automatically scaling Kubernetes workloads based on time, Winter Soldier helps reduce unnecessary resource usage, lowering cloud bills.
Automate Routine Tasks: Tasks like deleting unused resources or scaling workloads at specific times can be automated, freeing up time for other initiatives.
Improve Resource Utilization: By ensuring resources are only allocated when needed, Winter Soldier maximizes resource utilization and improves overall efficiency.
Implement Time-Based Scaling: It's ideal for scenarios where workloads have predictable usage patterns (e.g., a website that experiences heavy traffic during specific hours) or when resources need to be adjusted based on time.

Examples:

E-commerce Website: Scale up resources during peak shopping hours and scale down during off-peak periods to reduce costs.
Data Processing Jobs: Schedule resource scaling for batch processing jobs that run only during specific time windows.
Development and Testing Environments: Automatically scale down development and testing environments after hours to minimize resource usage.

Key Benefits:

Cost Reduction: Optimizing resource utilization translates to lower cloud bills.
Improved Efficiency: Automating resource management frees up time for other tasks.
Enhanced Reliability: By ensuring resources are allocated appropriately, Winter Soldier helps improve the reliability of Kubernetes applications.

6. Silver Surfer

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

Installation

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

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

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

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

Removed ApiVersion
Deprecated ApiVersion
Newer ApiVersion
Unchanged ApiVersion

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

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

This activity is performed for both current and new ApiVersion.

Check out our Github repo and give it a star ⭐️: https://github.com/devtron-labs/silver-surfer

Use Cases

Pre-Upgrade Planning: Silver Surfer helps you identify potential issues before the upgrade, giving you time to plan and resolve them.
Streamlined Upgrade Process: The tool provides detailed guidance, minimizing downtime and errors during the upgrade.
Kubernetes Object Management: Silver Surfer provides greater visibility into the compatibility of your objects with different Kubernetes versions, aiding in managing your cluster.

Key Benefits

Reduced Upgrade Complexity: Simplifies the Kubernetes upgrade process, reducing stress and the potential for errors.
Improved Uptime: Minimizes downtime during the upgrade process.
Enhanced Cluster Management: Provides a better understanding of your Kubernetes objects and their compatibility with different versions.

7. Trivy

Trivy is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System. Trivy detects vulnerabilities of OS packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container.

Installation

Installing from the the Aqua Chart Repository.

helm repo add aquasecurity https://aquasecurity.github.io/helm-charts/ 
helm repo update 
helm search repo trivy 
helm install my-trivy aquasecurity/trivy

Installing the Chart.

To install the chart with the release name my-release:

helm install my-release .

The command deploys Trivy on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Know more about Trivvy installation here.

Use Cases

DevSecOps Integration: Trivvy seamlessly integrates into your CI/CD pipelines, identifying vulnerabilities early in the development process and enabling automated remediation.
Secure Container Deployment: It ensures only secure container images are deployed to production by scanning them before deployment and integrating with container registries for continuous scanning.
Ongoing Security Monitoring: Enables regular vulnerability scans and provides detailed reports, allowing for proactive security maintenance and tracking of remediation efforts.
Beyond Containers: Extend security assessments to operating systems, server configurations, and other infrastructure components.
Software Supply Chain Analysis: Analyze your entire software supply chain, from source to deployment, to identify and address vulnerabilities at every stage.

8. Cert-Manager

Cert Manager is an open-source tool designed to automate the management and provisioning of digital certificates in Kubernetes environments. It solves the challenge of handling TLS/SSL certificates for applications running on Kubernetes by simplifying the process of obtaining, renewing, and distributing certificates. Cert Manager enhances security and reduces operational complexity, ensuring that applications have valid and up-to-date certificates for secure communication.

It automates the lifecycle of your TLS certificates! No more manual renewal!

Installation

You don't require any tweaking of the cert-manager install parameters.

The default static configuration can be installed as follows:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.1/cert-manager.yaml

Checkout our blog to learn how to setup cert-manager using Devtron: https://devtron.ai/blog/kubernetes-ssl-certificate-automation-using-certmanager-part-1

Use Cases

Automated Certificate Acquisition & Renewal: Effortlessly obtain and renew certificates from providers like Let's Encrypt, eliminating manual effort and ensuring continuous security.
Secure Ingress Controllers: Automatically provision certificates for Ingress controllers, enabling secure HTTPS communication for services exposed through the Ingress.
Centralized Certificate Management: Manage all your certificates from a single point of control, simplifying issuance, renewal, and revocation.
Enhanced Application Security: Strengthen encryption and protect sensitive data by ensuring valid and up-to-date TLS/SSL certificates.
Streamlined Operations: Reduce operational overhead, minimize downtime, and ensure continuous application availability by automating certificate management.

9. Istio

Istio extends Kubernetes to establish a programmable, application-aware network. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments.

Check out the Istio docs for Getting Started and a complete walkthrough of Canary Deployment with Flagger and Istio on Devtron.

Use Cases

Simplify Microservice Communication :

Istio abstracts away complex networking concerns like service discovery, routing, and load balancing.
Developers can focus on business logic while Istio handles communication between microservices.

Enhance Security:

Implement consistent authentication, authorization, and encryption across all services using Istio.
It mitigates security risks by enforcing security policies throughout the mesh.

Traffic Management :

Istio enables A/B testing, canary deployments, and blue-green deployments.
You can control traffic routing, timeouts, and fault injection seamlessly.

Observability and Monitoring :

Monitor service behavior, track performance metrics, and troubleshoot issues with Istio.
It integrates with observability tools for better insights into your microservices.

10. KRR

Robusta KRR (Kubernetes Resource Recommender) is a CLI tool for optimizing resource allocation in Kubernetes clusters. It gathers pod usage data from Prometheus and recommends requests and limits for CPU and memory. This reduces costs and improves performance.

The installation is pretty straight-forward. You can install the binary directly from their releases. To install the CLI, depending upon your operating system, you can install the KRR cli and use it for optimizing the resources. You can use Brew for installing on mac:

brew tap robusta-dev/homebrew-krr

brew install krr

Use Cases

Cost Savings: Reduce cloud bills by recommending optimal resource requests, eliminating over-provisioning.
Performance Boost: Improve application responsiveness by preventing resource contention and ensuring sufficient resources.
Data-Driven Insights: Gain insights into resource usage patterns for better planning and scaling decisions.
Automated Optimization: Integrate with CI/CD pipelines to automatically adjust resource allocation for continuous optimization.

11. Kyverno

Kyverno is a Kubernetes-native policy engine designed for Kubernetes platform engineering teams. It enables security, automation, compliance, and governance using policy-as-code. Kyverno can validate, mutate, generate, and cleanup configurations using Kubernetes admission controls, background scans, and source code respository scans in real-time. Kyverno policies can be managed as Kubernetes resources and do not require learning a new language. Kyverno is designed to work nicely with tools you already use like kubectl, kustomize, and Git.

Installation

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

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

Scan the new repository for charts.

helm repo update

Optionally, show all available chart versions for Kyverno.

helm search repo kyverno -l

Check the whole guide here.

And be sure to check out our blog on securing Kubernetes clusters with Kyverno policies.

Use Cases

Security: Enforce policies to prevent deployments with root privileges, restrict resource requests, control network access, and secure sensitive data.
Compliance: Implement auditing, labeling, and access control policies to meet regulatory requirements.
Best Practices: Automate resource validation, enforce naming conventions, and manage resource lifecycles.
Extend Kubernetes: Customize admission control and validate custom resources.

12. Opencost

OpenCost is a vendor-neutral open-source project for measuring and allocating cloud infrastructure and container costs. It’s built for Kubernetes cost monitoring to power real-time cost monitoring, showback, and chargeback. It is a sandbox project with the Cloud Native Computing Foundation (CNCF).

Check out the Installation guide to start monitoring and managing your spend in minutes. Additional documentation is available for configuring Prometheus and managing your OpenCost with Helm.

Use Cases

Identifying Costly Workloads: Identify specific pods or deployments consuming excessive resources and take steps to optimize their resource allocation.
Allocating Costs to Teams: Use OpenCost to generate detailed reports showing the cost incurred by each team or project using your Kubernetes cluster.
Right-sizing Resources: Optimize resource requests and limits for pods based on actual usage, reducing unnecessary resource allocation and saving costs.
Predictive Cost Management: Forecast future costs based on historical data and identify potential spikes in resource consumption to proactively adjust resource allocation or budget.

Conclusion

Kubernetes has revolutionized the way we build and deploy applications. However, its complexity can be daunting. The 12 tools we've explored provide a comprehensive toolkit for simplifying and optimizing your Kubernetes management.

The Coud-native landscape is overflowing with tools, each serving a specific purpose. Remember, there's no one-size-fits-all solution. Carefully evaluate your use case and choose the tools that best address your specific needs for a more efficient, secure, and cost-optimized Kubernetes experience.

By leveraging these powerful tools, you can unlock greater efficiency, reduce costs, enhance security, and ultimately, focus on delivering innovative applications faster. So, embrace these powerful tools and build a better infrastructure with confidence!

If you have any questions, or want to discuss any specific usecase, feel free to ask them in our Discord Community.

Happy Deploying!

Securing Kubernetes Production: Avoid These 11 Common Misconfigurations

Devtron — Fri, 02 Aug 2024 05:44:33 +0000

We know how scary it is when the production is down due to some misconfigurations. Do you know what is even scarier than misconfigurations? It is presenting RCA (root cause analysis) to your manager.

In production, there is a mountain of configurations, when production is down someone has to find that single annoying misconfiguration. Finding it feels like looking for a needle in a haystack.

It's important to know the common misconfiguration which can be done by anyone. This blog will show those and how to prevent scary situations. Here are 11 common misconfigurations that should be avoided in any environment, be it Production or UAT.

1. Not enough available IPs in the vnet/subnet

IPs are required for communication within a cluster and outside of a cluster as well. While creating a Kubernetes cluster using EKS, AKS or GKE, VPC or Vnet is used for IP Address management, network isolation, and security. The IPs for pods, services, and nodes are taken from the subnet.

Each node requires an IP address within the network. If the available IP addresses are limited, there will be a point where no more nodes can be added to the cluster, which restricts the cluster's ability to handle additional load and autoscaling.

Difficulty in Maintenance: Maintenance activities, such as updating nodes or migrating workloads, become more challenging if IP addresses are scarce. The lack of available IPs can complicate tasks, like gracefully moving pods during maintenance.

To solve the issues caused by fewer available IPs in the subnet, take the precautionary actions that before doing any activity such as upgrading a cluster, adding a node, increasing the replica count, or deploying a large applications, check the numbers of IPs available and how many IPs will be need.

2. No or misconfigured liveness or readiness

Liveness and readiness probes are mechanisms used to determine the health and availability of application. They play a crucial role in ensuring the reliability and stability of applications.

If an application encounters a deadlock, memory leak, or any other internal issue that causes it to become unresponsive, the liveness probe will detect this state and restart the pod, attempting to bring the application back to a healthy state.
A readiness probe determines whether or not a pod is ready to receive traffic. Before a pod is added to the load balancer, the readiness probe checks if it is ready to handle incoming traffic. This prevents traffic from being routed to pods that may not be fully initialized or ready to serve requests.
When it comes to scaling down an application or performing upgrades, readiness probes are essential. When a pod's readiness probes fail, it will not receive additional traffic, allowing it to finish processing existing requests and perform a graceful shutdown without impacting the user experience.

These are some issues which may be encountered when configuring liveness and readiness incorrectly:

Unnecessary Pod Restarts
Delayed Failure Detection
Delayed Scaling
Rollback Issues

3. PDBs not configured/ incorrect configurations

PDBs (Pod Distribution Budgets) are particularly useful for applications that require high availability and where maintaining a minimum number of operational instances is critical. They help prevent scenarios where all pods of an application are taken offline simultaneously, ensuring that a certain level of service availability is maintained even during maintenance or unexpected failures.

Incorrect PDB configurations can also be problematic. For instance, when upgrading the Kubernetes version of a cluster, if there is a wrong configuration in PDB that says ReplicaCount = 1 and maxUnavailability = 1, Kubernetes is not allowed to perform pod evictions. This will become a blockage for cluster upgrade activity. It's important to find a balance between availability and maintenance requirements.

4. Horizontal Pod Autoscaler not enabled

HPA (Horizontal Pod Autoscaler) is a resource controller in Kubernetes that automatically adjusts the number of replica pods in a deployment, statefulset, or replica set, based on observed CPU/Memory utilization or custom metrics. Key components and concepts related to the Horizontal Pod Autoscaler:

Metrics: indicate the current utilization of resources or custom application metrics
Target Resource Utilization
Current Resource Utilization
Scaling Algorithm

Some basic misconfigurations that may cause issues:

Inappropriate “--horizontal-pod-autoscaler-sync-period”, this will create a delay in scaling of pods.
If some of the Pod's containers do not have the relevant resource request set, CPU utilization for the Pod will not be defined and the autoscaler will not take any action for that metric.
Selection of fluctuating metrics, this will create confusion for HPA when deciding whether or not to scale up or scale down the resources.
If the wrong metrics are chosen, or metrics that don't accurately reflect application's behavior, the HPA might make incorrect scaling decisions. This can result in over or under-scaling, affecting performance and resource utilization.

5. Incorrect Autoscaling configurations

We all know how important autoscaling is, but all the efforts are in vain when auto-scaling doesn't work with correct configurations. Here are some basic misconfigurations:

Defining the wrong tag or region for a nodegroup or node-pool. In simple words, the autoscaler doesn't know which nodegroups or node-pool needs autoscaling.
The max size of nodegroups or node-pool was already reached, thus autoscaler is not able to increase the node count.
Incorrect IAM permission where the cluster autoscaling pod is running. In the case of AWS, check the cluster autoscaler pod logs for permission issues. Node IAM role must have a policy defined. https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#iam-policy
Node type is not available in the availability zone. Lets say autoscaler wants to add a new node of type “t3.medium” and our region is “ap-south-1”, the “t3.medium” node type is not available in “ap-south-1”. To overcome this, configure node type correctly based on the region.

Feel free to check out this blog for detailed understanding of autoscaling and how to scale applications in Kubernetes.

6. Not using the latest Kubernetes API versions

Using old/ deprecated Kubernetes API versions will open the door to various unexpected issues such as:

Security Vulnerabilities
Compatibility Issues
Lack of Support
Limited Access to Tools and Integrations
Incompatible Add-ons
Configuration Complexity

Plan on regular maintenance and upgrades of Kubernetes versions for reducing the vulnerabilities. While updating the cluster, make a backup and have a well-defined rollback plan in case any issues arise during the upgrade process.

7. Running "kubectl apply" manually in clusters and editing resources directly from cloud console

When we talk about production being down, what is the first question that your manager asks? “ Who did this ?” If this is the question then most managers are the same. We need an audit and better monitoring system for giving response to the manager. When someone runs the “kubectl apply” or “kubectl edit”, it becomes difficult to track the changes, and auditing them is even more difficult.

Common issues that can be seen:

Configuration Drift: The actual state of resources diverges from the desired state.
Inconsistent Changes: When multiple team members manually apply changes, there's a risk of conflicting updates or unintentional changes, leading to confusion and unexpected behavior.
Overwriting Changes: When manually editing resources, critical configurations might accidentally be overwritten, leading to outages or unexpected behavior.
Difficulty in Reproducing Issues: Troubleshooting issues becomes harder when changes are applied manually without proper records, as it's challenging to reproduce the state where the issue occurred.

A Platform Engineering tool like Devtron is tailored to provide all the audit and monitoring of an application and its whereabouts. Feel free to check this out for access management at scale in Kubernetes

8. Sharing admin Kubeconfig with users or not having separate creds for each team member

In a Kubernetes, sharing an admin Kubeconfig or failing to provide distinct credentials for each team member could cause serious security and accountability problems. Sharing administrator credentials allows uncontrolled access, which can lead to misconfigurations, safety hazards, and a lack of accountability for actions committed. On the other side, not having different credentials restricts proper access control and segregation of roles, making tracking and auditing user actions difficult. To solve these problems, it's critical to build granular Role-Based Access Control (RBAC), create individual user accounts, and enforce best practices such as credential rotation and multi-factor authentication. This guarantees that access is properly restricted, operations are traceable, and the cluster's overall security posture is maintained.

To learn more about securing Kubernetes CI/CD, feel free to check this blog.

9. Not setting up logging and monitoring stacks

In a Kubernetes cluster, neglecting to set up appropriate logging and monitoring stacks might result in multiple problems and risks. Without these critical tools in place, visibility into application behaviour, system health, and performance is hampered, making debugging issues and assuring optimal performance difficult. Furthermore, the lack of extensive surveillance may hinder security efforts, restrict compliance with industry standards, and gaining clear visibility of the values of the deployed applications is difficult. To prevent these consequences, it is critical to have strong logging and monitoring practices, use technologies such as Prometheus, Grafana, Elasticsearch, and Fluentd to efficiently collect and analyze metrics, logs, and events.

Check out this blog for setting up a monitoring stack on Kubernetes.

10. Not setting-up autoscaling for cluster infra essentials

In a Kubernetes cluster, failing to enable autoscaling for cluster essentials such as the nginx-ingress controller , kube-prometheus-stack, elasticsearch, CoreDNS, etc. might result in significant performance bottlenecks and decreased reliability. These components play key roles in network traffic management and DNS resolution, making them vulnerable to increasing demand during traffic spikes or heavy workloads. If autoscaling is not implemented, the cluster may struggle to handle additional traffic efficiently, resulting in latency, interruptions, and even application unavailability. Enabling autoscaling for these critical services guarantees that resources are dynamically assigned to meet demand, boosting performance, optimizing resource utilization, and ensuring uninterrupted service delivery even under variable workloads.

11. Not adding deletion protection on ALB

Failure to include deletion protection in an AWS Application Load Balancer (ALB) can result in accidental data loss, service outages, and unwanted consequences. Deletion protection is a security feature that prevents essential resources such as ALBs from being removed mistakenly, hence protecting the infrastructure from human errors or unauthorized acts. Without deletion protection, a vital ALB used to route traffic to the applications could be erased, resulting in application downtime, altered user experiences, and potential revenue loss. Enabling deletion protection on ALBs adds an extra layer of security against accidental or malicious deletions, assuring the stability and availability of applications.

Conclusion

Preventing common misconfigurations is essential for maintaining operational stability. This blog highlighted 11 such pitfalls, including IP scarcity, improper probes, and inadequate logging. Proper strategies, like Pod Disruption Budgets and accurate HPA setups, can enhance availability. Staying updated with Kubernetes API versions, avoiding manual changes, and securing credentials are vital for a robust system. Robust monitoring, autoscaling essentials, and deletion protection for ALBs, ensure optimal performance. Proactive avoidance of these misconfigurations enhances reliability, security, and overall operational efficiency.

If you have any questions feel free to reach out to us. Our thriving Discord Community is just a click away!

Best Practices for Creating Container Images

Devtron — Wed, 10 Jul 2024 05:34:18 +0000

Imagine running 100s of microservices in production without knowing the dos and don'ts around creating container images. It’d be chaotic. You don’t want to spend hours building your container images and also you would not want to deploy images with vulnerabilities.

Containerization has become a cornerstone of modern software development and deployment, offering numerous benefits in terms of scalability, consistency, portability, and efficiency. One of the key elements in the container ecosystem is the creation of optimized and secure container images. In this blog, we will delve into the best practices for creating container images to help you build lightweight, reliable, and most importantly secure images to make sure that your image is production-ready.

Hacks for optimizing container images

Creating a container image and optimizing it are two sides of a coin. For container creation, there are different ways which might involve writing a declarative Dockerfile or maybe using cloud-native buildpacks depending upon the use-cases. When it comes to optimization, it's true for all types of images being created. Here are some of the methods that can be used to optimize your container image and ensure the uptime of your applications.

1) Docker Hub image pull rate limit

In cases when you are dealing at scale, for instance - running a daemon set that is pulling its docker image from Docker Hub on a 100-node cluster at a time. In such scenarios, you’ll frequently face issues of rate limit. For example: You have reached your pull rate limit

Now, How do we deal with it?

i) Look for an alternative container registry where your helm chart’s public image could be available for instance, quay or ghcr. In these container registries, there aren't any image pull limits. [Recommended]

ii) Keep the image in your organization’s container registry like ECR, ACR, etc. Make sure that the node has appropriate permissions for the pod to inherit. There would be an overhead to keep updating the image in case you are using your private registries for public helm charts.

Note: In the case of Docker Hub, 100 pull requests per 6 hours for anonymous users on a free plan. Enforced based on your IP Address. And 200 pull requests per 6 hours for authenticated users on a free plan.

2) Use Build Contexts

Avoid building your docker images like this - Docker build -t . , unless you want to set the context as the current working directory. Here period (.) means context as the current working directory.

Let’s say you have two directories: i) app and ii) consumer having the app’s code and consumer’s code respectively within the same repository then your build context should be app/ and consumer/ respectively. This would be helpful in scenarios where you are using COPY . . in Dockerfile as you will only be copying content from a specified folder instead of a complete repository and hence it’ll decrease time.

PS: It is super easy to configure the build context if you are building your Dockerfile from Devtron

3) Multi-architecture Builds

If you have multi-architecture nodes in your cluster, i.e., ARM-based and AMD-based machines, then you will need to set the –platform flag to specify the target platform. By default, you can only build for a single platform at a time. With IDPs like Devtron, you can easily build container images for multiple architectures at your fingertips.

4) Implement Image Caching

A container image has multiple different layers. Imagine the size of container image is in Gegabytes. Everytime you build an image, it will start from the initial layers and build each and every layer. Those layers comes from the steps given in your dockerfile or the steps involved in building the image. Once you build your image, in subsequent builds, it will again create all those layers which will increase the time to build. To optimise the build time, it is highly recommended to implement caching mechanism so that next time when a new image will be build, it will leverage the cache of previous build for all those steps which were not changed and using the existing cache, build time will be reduced.

5) Golden Image Creation

It is one of the widely recommended practices to have golden images for your application. If all of your applications require a certain package, you don’t want to install it at run time; every time instead you can include it in the golden image and use that image as a bage image for your container images. It’ll save a lot of time.

Techniques for optimizing container image
Now let's discuss some of the common techniques that can help you optimize your container images.

1) Multi-Stage Builds

Multi-stage builds enable you to create a final image that only includes the runtime dependencies and necessary artifacts. Unnecessary build tools, libraries, and intermediate files are discarded in subsequent stages, resulting in smaller image sizes. This reduction in size leads to faster image pulls and deployments, optimizing resource utilization. For applications such as Java which uses maven/gradle files, a multi-stage dockerfile can be helpful.

2) Minimize Layers

Concatenate RUN commands to make your Dockerfile more readable and create fewer layers. Fewer layers mean a smaller container image. Each RUN statement in the Dockerfile creates a layer that gets cached. Concatenating reduces the number of layers.

3) Use Lightweight Images

Always choose the smallest base images that do not contain the complete or full-blown OS with system utilities installed. You can install the specific tools and utilities needed for your application in the Dockerfile build. This will reduce possible vulnerabilities and the attack surface of your image.

Creating a Secure Container Image

Making sure the container image is secure and ready to be used in production is another important aspect and a part of DevSecOps practices. Here are some of the practices that can be incorporated for building a secure image.

1) Environment Variables

Never inject environment variables within your container image. Embedding env variables within your container image means you are hardcoding them within the image. This way the image would not be generic to use across various microservices. So always use configMaps and Secrets to store env variables and credentials.

2) Vulnerability Scanning

Never deploy images with critical CVEs into production as this way you would be an easy target for hackers to hack into your application. Make sure to integrate vulnerability scanning tools in your pipeline so that you ship an application without vulnerabilities. On top of vulnerability scanning, having governance policies such as automatically blocking the image with critical CVEs can help you strengthen the pipeline.

Check out this blog to understand more about vulnerability scanning of container images using Trivy and how Devtron integrates with it.

3) Non-root User

By default, Docker containers run as the root user, which can pose security risks if the container gets compromised. In such cases, the hacker would have root access to your host and could bring the entire node down. So always ensure that your images run as non-root by defining USER in your Dockerfile.

4) Avoid using :latest

The latest image tag for any public repository might bring in unexpected bugs. So it’s always recommended to specify a specific version instead of the latest.

Conclusion

Creating high-quality container images is a crucial aspect of modern application development and deployment. By following these best practices, you can produce container images that are optimized, secure, and well-suited for deployment in various environments. Well-crafted images contribute to faster deployment, improved security, better resource utilization, and enhanced application performance, setting the foundation for successful container-based workflows.

If you have any queries, don't hesitate to connect with us. Join the lively discussions and shared knowledge in our vibrant Discord Community.

Kubernetes Dashboard Part 3: Helm Release Management

Devtron — Wed, 12 Jun 2024 04:43:16 +0000

TL;DR: In this blog, the authors talk about the helm dashboard by Devtron and how it can solve various issues related to helm CLI and help you manage everything around helm through the intuitive dashboard.
This blog will discuss how the HELM dashboard is used to view the installed Helm charts, see their revision history and corresponding k8s resources, and how it brings convenience to the developer and DevOps team in all organizations.

This blog is the third part of the Kubernetes Dashboard blog series. Read part 2 on the Kubernetes dashboard for cluster management to understand how to simplify multicluster cluster management for large teams. Read Part 1 on Kubernetes Dashboard for Application Management to witness the ease of deploying apps onto Kubenrtess on day 1.

Devtron, an open-source Kubernetes-native application management platform, introduced the HELM dashboard to get real visibility of all your HELM deployments across multiple clusters in one plane.

Challenges while deploying with HELM
As HELM came with the ability to template, package, and deploy applications, more and more organizations started adopting Kubernetes. It is said that at least 70% of the companies using Kubernetes today use HELM for deployments.
However, a few operational challenges exist while deploying apps at scale using HELM.

Since HELM is a CLI-based tool, it involves a learning curve to remember all the commands for app deployments.
No solid mechanism to view the health and status of applications deployed using HELM
Lack of understanding of the relation between workloads resources for respective HELM charts
Identifying the difference in HELM chart versions while troubleshooting issues is a big pain as the activity is carried out manually.
And the visibility into various apps getting deployed into multiple clusters is time-consuming work.
Popular GitOps tools such as Argo CD, which supports HELM deployments, don't store historical data of HELM charts.

Hence Devtron has launched the open-source HELM dashboard to bring convenience for developers and DevOps while deploying with HELM.

Devtron HELM Dashboard for app visibility and management

Devtron HELM Dashboard is an open-source web interface for HELM-based app deployments. It provides visibility into the status of HELM-based deployments across clusters and helps you to view resources such as pods, workloads, resources, services, infrastructure, etc, in a single pane. With Devtron, your developers and Ops team can troubleshoot and diagnose problems in HELM releases from the UI.

Multicluster visibility of all HELM deployments

Devtron HELM dashboard provides information about all the HELM-based deployment across multiple clusters in a single plane. The dashboard provides information such as namespace, health status, deployment date of all the applications deployed using HELM in from Devtron or the CLI.

HELM Chart store

Devtron dashboard provides HELM charts for key tools and software important to automate the CI/CD process for Kubernetes app deployments. Our platform allows you to upload your own HELM charts to our store too. The best part is you can select and group the HELM charts of all the apps you need and deploy them at once. This feature is helpful for developers or the DevOps team while creating new environments.

Application deployment details in real-time

Devtron HELM dashboard provides details of the resources of each application. Developers can visualize all resources grouped according to classes, such as workloads, services, networking, and configuration and storage.

Configure HELM values from the web interface

Devtron HELM dashboard allows developers and the DevOps team to configure all the values of HELM charts from the UI itself. Since Devtron stores all the HELM charts in its store, teams can quickly view the Readme docs and make necessary edits quickly.

Troubleshooting pods in the HELM dashboard

After HELM-based deployment, using the Devtron HELM dashboard, one can easily log in to any of the pods and go through the logs to troubleshoot issues or simply diagnose or validate the health status of pods.

Understand the difference in the HELM charts

Devtron HELM dashboard allows you to identify the difference between different HELM charts of an application. Suppose a new deployment is improper or applications are not behaving as expected. In that case, developers should be able to debug and identify newly done changes to HELM charts and fix the problem. In case they feel the changes cannot be undone, they can quickly select a previous version of HELM charts to roll back the application.

Guaranteed outcomes of Devtron Kubernetes dashboard

With the Kubernetes dashboard, you can improve Kubernetes admin and Ops team productivity in managing Kubernetes clusters and reduce mean time to resolve issues with central plane visibility and controls of all nodes across clusters.

Kubernetes Dashboard Ecosystem
Open source Devtron Kubernetes dashboard is available in different deployment options on-prem and managed. Recently Devtron has also released a desktop client version for the Kubernetes dashboard.
Try Devtron open-source Kubernetes dashboard for free.

Kubernetes Dashboard Part 2: Cluster Management

Devtron — Mon, 10 Jun 2024 02:42:33 +0000

TL;DR: In this blog, the author talks about the burning issues in cluster management and how Devtron's Kubernetes dashboard helps you manage the on-prem/ cloud Kubernetes clusters efficiently through an intuitive dashboard.

We will discuss how the Kubernetes dashboard by Devtron can be leveraged for cluster management and how it brings immense value to all organizations' developers, DevOps, and SRE/Ops teams.

This blog is the second part of the Kubernetes Dashboard blog series. Read part 3 on the Kubernetes Helm Release management to experience how easy it is for all organizations' developers and DevOps teams to manage the Helm App lifecycle. Read Part 1 on Kubernetes Dashboard for Application Management to witness the ease of deploying apps onto Kubenrtess on day 1.

Devtron, an open-source Kubernetes-native application management platform, has introduced the Kubernetes dashboard for easy application management from a UI. Various teams can get a single-plane visibility of all resources across clusters and can edit, deploy, or troubleshoot them from the UI.

What is K8s Cluster management?

Kubernetes cluster management is how an Ops team manages a group of Kubernetes clusters. With more microservices migrated to the cloud and containers, Kubernetes clusters are becoming more distributed and complicated to manage. Secondly, many microservices will be deployed into multiple clusters dedicated to various environments such as dev, test, pre-prod, and prod. For efficient operation, these clusters must be maintained at regular intervals for seamless deployment and delivery of applications.

Challenges of Kubernetes cluster management

Managing and maintaining multiple clusters in the software delivery process is difficult, especially when they are spread across different cloud providers and private data centers. Following are a few challenges that the Ops team face during the cluster management process.

High cost of maintaining multiple clusters and nodes in time

A cost-effective solution for IT organizations is to create dev and test environment clusters in local data centers and choose production clusters in public clouds like AWS or GCP. With time, multiple microservices will be built and deployed, and accordingly, the number of clusters also increases. Without a centralized tool, the Ops team doesn't get a consolidated view of which cluster needs attention in a particular time period. If they don’t proactively manage the cluster, there are chances of overutilizing resources, resulting in a huge cloud bill.

Dependent on experts

Kubernetes is still a new technology and few experts can manage infrastructure. Only a few experts can easily perform cluster management tasks, such as creating, updating, and deleting Kubernetes clusters across multiple private and public clouds or quickly troubleshooting and resolving issues across your federated domain.

The use of CLI is not scalable

The Ops team might like to use the Kubectl command for a few clusters. It can appear as fun to fetch data of resource utilization and take action from the CLI initially. But with time when multiple clusters have to be managed on time, Kubectl is not a scalable solution. Applying policies, carrying out node operations such as health checks, taint or cordon, and troubleshooting is time-consuming work through CLI. Additionally, it often involves a learning curve and Ops teams don't enjoy any part of it.

Devtron has launched the open-source Kubernetes dashboard for cluster management to overcome all these challenges.

Kubernetes dashboard for effective cluster management

360° visibility of multiple clusters

Devtron Kubernetes dashboard allows users to see all the clusters across the enterprise in one plane. They can see the number of nodes in each cluster and the total CPU and memory allocated. DevOps and Ops leads can quickly visualize the resources deployed across clusters, and nodes of each cluster, and make informed decisions like cordoning or deleting a node to save cloud costs.

Node Insights

The ops team can drill down into each cluster and find the granular details of all the nodes. They can visualize the status of each node along with other information such as roles, K8s versions, number of pods running, labels, annotations, resources, etc. The best part is the Ops team can see the resource utilization metrics such as CPU request, memory request, and namespace of each pod in a node.

Node Operation

Devtron dashboard allows the Ops and Admins team to choose a node and carry out maintenance work such as delete, edit configurations, drain, taint, or cordon. They carry out these node operation duties easily with the click of a button from the UI. So Kubernetes admins and Ops team don't have to learn and use Kubectl all the time for setting any taint & toleration, making nodes unschedulable, or any other node operations.

Troubleshooting

Devtron Kubernetes dashboard allows Ops or admins folks to access the cluster resources from the terminal. You can troubleshoot and debug errors with the help of tools such as Kubectl, HELM, curl, busybox, and other utilities - already provided by Devtron for Ubuntu, Alpine, and CentOS. Devtron provides you the facility to change the namespace and shell (bash/ssh) from the UI itself.
Devtron Kubernetes dashboard also provides real-time visibility into node conditions such as Network unavailability, memory pressure, or disk pressure so that you can take immediate actions. Similarly, you can also edit your node YAML to configure your node like adding labels, or annotation, increasing CPU or memory limits.

Guaranteed outcomes of Devtron Kubernetes dashboard

With the Kubernetes dashboard, you can improve Kubernetes admin and Ops team productivity in managing Kubernetes cluster, and reduce mean time to resolve issues with central plane visibility and controls of all nodes across clusters.

Kubernetes Dashboard Ecosystem

Open source Devtron Kubernetes dashboard is available in different deployment options on-prem and managed. Recently Devtron has also released a desktop client version for the Kubernetes dashboard that can help you manage your k8s resources and multi-clusters.
Try Devtron open-source Kubernetes dashboard for free.

Kubernetes Dashboard Part-1: Application Management

Devtron — Fri, 07 Jun 2024 13:01:22 +0000

This blog will discuss the Kubernetes dashboard for application management and how it brings immense value to the developer, DevOps, and SRE/Ops team in all organizations.

Challenges of application management in Kubernetes

With CI/CD and GitOps tools, numerous features, changes, or bug fixes are deployed into Kubernetes quickly and frequently (almost daily). With many features released into the various environments, checking the status of each application's health pods is a painstaking process. Here are a few challenges that bog down DevOps and SREs teams while managing applications after deployments.

Lack of holistic visibility of all the resources

Without a centralized tool, DevOps and SREs often don't know about all the resources, such as pods, Deployments, Statefulset, Services, Secrets, Configmaps, etc., deployed into a cluster. Ops teams often need a holistic understanding of resource consumption across multiple clusters to make decisions. Fetching information about all the Kubernetes objects across clusters and environments about their health and status can be time-consuming.

Dependent on experts

Collaboration between teams (developers, Ops, and SREs) can only be possible with holistic information about clusters, app deployments, and resources. Various team members, such as developers, often depend on a particular person to fetch the data for decision-making.

Applying "kubectl" at scale is frustrating.

Using the kubectl command and fetching information about applications or pods in a cluster can be fun. However, applying commands to check the status of new deployments or pod health is repetitive and frustrating for the Ops team. For environments where developers and testers would deploy an image and perform unit testing and system integration testing, carrying out pod operations such as health checks and troubleshooting is a context switch for developers. It often involves a learning curve; developers don't enjoy any part of it.
Devtron has launched the open-source Kubernetes dashboard for application management to overcome all these challenges.

Kubernetes dashboard for Application Management

Devtron Kubernetes dashboard is an open-source web interface to manage Kubernetes applications and cluster resources on-demand. Let us see all the features (watch the below video) of the Kubernetes dashboard for app management.

360° visibility of multiple clusters for informed decision-making

Devtron Kubernetes dashboard allows users to see all the resources- grouped as workloads, Configmaps and storage, networking, RBAC, and CRDs- in one plane. Developers and Ops leads can quickly visualize the resources deployed across clusters and make informed decisions like deleting a few obsolete pods to save cloud costs.

Granular visibility and control of resources

The ops team can drill down into each resource, say a pod, and find the granular details. They can visualize the manifest, events, and logs for each help. They can edit a manifest in the run-time and apply it from the UI. Like resource management, the Ops team can also visualize and modify namespaces in a cluster from the Kubernetes dashboard.

Troubleshooting with logs and terminal

Devtron dashboard allows users to choose a container for a resource to find the out logs. This helps understand the behavior of a resource and troubleshoot immediately in case an application is not working correctly. Devtron Kubernetes dashboard also allows the Ops team to use the terminal (ssh, bash, PowerShell) from the browser for troubleshooting.

Application deployments health status

Since Devtron also provides CI/CD pipelines and GitOps workflows for deployments, the dashboard provides the health status of each application. The dashboard offers the golden metrics- CPU usage, memory usage, throughput, and latency- to measure performances of each resource category- workloads, networking, configmaps & storage, etc.

RBAC for least privilege on resources

Providing teams with the least privilege access to various resources is essential in large organizations. Devtron Kubernetes dashboard allows admins to provide actions such as view, edit, and delete to cluster and resource levels. Suppose you want to grant a developer the editing ability on dev-namespace and viewing ability to their respective application resources in prod-namespace. In that case, you can easily do that using the RBAC functionality of the Devtron Kubernetes dashboard.

Guaranteed outcomes of Devtron Kubernetes dashboard

With the Kubernetes dashboard, you can improve developer and Ops team productivity and reduce mean time to resolve issues with central plane visibility and controls of all the resources across clusters.

Kubernetes Dashboard Ecosystem
Open source Devtron Kubernetes dashboard is available in different deployment options on-prem and managed. Recently Devtron has also released a desktop client version for the Kubernetes dashboard that would help you to manage Kubernetes resources and multi-clusters.
Try Devtron open-source Kubernetes dashboard for free.

How to Deploy MERN Stack over Kubernetes

Devtron — Wed, 05 Jun 2024 02:33:02 +0000

Hello Everyone, Welcome to another blog! In this blog post, we will talk about how easily you can deploy your MERN stack over Kubernetes with just a few clicks using Devtron.
Yes, you read it right! You don't have to write a number of yamls or pipelines to deploy your entire stack over Kubernetes.
Let's go ahead and see how we can achieve this.

MERN Stack

MERN Stack is a combination of different technologies summing up the entire stack. It consists of the following technologies:

MongoDB - Use for database
Express(.js) - Used node.js web framework
React(.js) - Used for developing client-side JavaScript framework
Node(.js) - Used for developing the premier JavaScript web server

Why Kubernetes?

Before we start with the hands-on journey, Why do we need to deploy MERN Stack over Kubernetes? To answer this question, let's take a step back.
Traditionally, for deploying containerized applications/stacks, docker was heavily used. We can containerize each of the technologies say - MongoDB in a container, react in another container, and node-express in a different container and link them all with certain port numbers to work together. Or we can use docker-compose to deploy the entire stack.
But when you talk about auto-scaling and high availability, these tools aren't enough to meet the requirements. This is where Kubernetes comes into the picture.
It is an open-source container orchestration platform for automating deployments, scaling, and management of containers. To know more about why you need to migrate to Kubernetes, please click here

Getting Started

Now that we know the need for migration, let's get our hands dirty. In this blog, we will show how to deploy a simple CRUD application that is divided into three parts -

- Database (MongoDB)
- Backend (Node & Express)
- Frontend (React Code) For the database, we will use a community helm chart. All the deployments will be carried out by using Devtron.

[Note: If you haven't installed Devtron, feel free to check out the well-managed documentation and join the devtron discord community for any help]

Deploying MongoDB

To deploy MongoDB, we will use bitnami/mongodb(13.1.2) chart that is easily accessible in Devtron's Chart Store as you can see in the image below.

Once you get the chart, click on it. It will open the configuration window where you have to provide details for the App Name, Project, and Environment in which you want to deploy. Additionally, it also shows all the chart configurations where you can make any changes if required. For this, please make the following changes:

auth:
rootUser: root
rootPassword: "abhinav123"

Once you click the Deploy Chart button, your database is up and running. You will be able to check out all the resources it has deployed, including the status of the application, the chart version, and many more as shown below.

Now that our chart is deployed, let's move ahead and deploy the backend of our application.

[Note: To deploy any helm chart using Devtron, please have a look at this blog].

Deploy Backend

To deploy the backend (Express & Node), we have to create a custom app from the Devtron dashboard. Devtron is capable enough to deploy any kind of application irrespective of the language or stack chosen for the project. Let's move ahead and onboard the backend app.
Step 1: Click on the Create dropdown, and select Custom App, it will open a window and ask for details as shown below. Provide the necessary details and click Create App

Step 2: After creating an app, you will be redirected to the App Configuration tab where you need to provide the Git Repository (source code URL), Docker Build Config (container repository name), configure Base Deployment Template (k8s configs), ConfigMaps & Secrets if any. For a detailed understanding of App Configuration, feel free to check out the documentation.
For this tutorial, we will configure the ingress and port number in the Deployment Template. For ingress, make sure that the ingress controller has been deployed. Feel free to check out this blog to configure the ingress controller using Devtron.

ContainerPort:
- envoyPort: 8799
port: 8082

ingress:
annotations: {}
className: nginx
enabled: true
hosts:
- host: backend.devtron.info
pathType: ImplementationSpecific
paths:
- /

After making these necessary changes, leave all the configurations as default. That's the beauty of the deployment template provided by Devtron. You don't have to write big YAMLs for k8s configuration. Everything, right from the pod specs, hpa, keda-autoscaling, service, ingress, etc. is pre-configured. You just have to tweak some values as per the requirements and deploy it.
Step-3: Now let's move ahead and create a CI/CD pipeline using Workflow Editor. Just click Build Pipeline → Continuous Integration and provide the necessary details to create your CI Pipeline.

After the CI Pipeline is created, Click the + icon to create a CD Pipeline corresponding to that CI. Configure the details, and click Create Pipeline.

Woohoo! We are done with creating the pipeline for our backend application. Now that we don't have any ConfigMaps or Secrets for this application, let's move to the Build & Deploy tab and trigger the CI Build.
Step-4: Click Select Material, select the commit against which you want to build an image, then click Start Build. It will start building your image. You can see runtime logs, commit details for the particular build, security results (if enabled), and artifacts.

Step-5: After building the image, click on Select Image your deployment pipeline, and deploy the image that you have built. You can also check the commit for which image was built on the deployment dashboard itself.

Now for more details of the deployment, navigate to App Details tab and you can see all the information about your application. The environment in which it is deployed, k8s resources it has like pods, services, etc, manifests, logs, and much more can be found on the Devtron dashboard itself just like we had in the MongoDB chart when it was deployed.

Deploy Frontend

Now that our backend is deployed, let's deploy the frontend application (React). To deploy it, we need to follow the same steps that we followed in the case of the backend. But instead of configuring all the configs again, we can use the clone feature of Devtron that would do all the configs for us. We would just have to replace the git repo of the source code, minor changes in the deployment template, and then we are good to build & deploy the application.
Step 1: Create a custom app, check the clone button, and select the mern-backend (backend application name)

Step 2: After the app is created, it will take you to App Configuration tab wherein you have to replace the git URL with the frontend URL. Then move to the Deployment template, change the port number, and ingress hostname. In our case, we have made the following changes.

ContainerPort:
- envoyPort: 8799
port: 80
servicePort: 80
ingress:
annotations: {}
className: "nginx"
enabled: true
hosts:
- host: frontend.devtron.info
pathType: ImplementationSpecific
paths:
- /

After making these changes, build the image as we did for the backend application and deploy it. Once the application is up and running, we will be able to access the application at the host we have provided in ingress configurations.

Hurray! The application is up and running. It is also connected with the backend and the backend is connected with the database as you can see in the above image we have added a New Book and it is successfully added.
You can try out the application too at frontend.devtron.info/
The entire MERN Stack deployment can be seen on Devtron's preview dashboard. Feel free to sign up for the dashboard using GitHub and explore Devtron's features.
If you like Devtron, do give us a start on Git Hub and join the Discord community for all the latest updates.

How to Deploy a Django Full-stack Application over Kubernetes

Devtron — Mon, 27 May 2024 02:41:18 +0000

TL;DR: In this tutorial, we will learn to deploy a sample Django Full Stack Application on Kubernetes using Devtron and implementing GitOps.
Welcome to another blog from the Devtron ecosystem! In this tutorial, you'll learn to deploy a Django Full-stack Application over Kubernetes using Devtron. The best part is you don't need to worry about manually working with K8s configuration files or setting up a CI/CD pipeline. The Devtron platform would seamlessly do everything with a few button clicks.
Let's see how it is done!

Pre-requisites

Before moving forward, let's look at all the things you'll require to follow along:

A full-stack Django Application on GitHub
For this tutorial, we'll be using a simple To-Do List application with PostgreSQL as the database. The application can be accessed from the repo.
Devtron installed and configured on your machine
If you haven't installed Devtron, feel free to check out the well-managed documentation and join the Discord community for help!

Setting up the database - PostgreSQL

Our application uses PostgreSQL as the database, so the very first step would be to deploy that. Here, we'll be using a community Helm Chart and deploying it with the help of the Helm dashboard by Devtron.

Step 1: Visit Chart Store

Navigate to the Chart Store on the Devtron Dashboard and search for postgresql. For this tutorial, we'll be using the bitnami/postgresql(12.1.6) chart, as shown below:

Step 2: Chart Selection

Click on the preferred chart where you may refer to the README to learn more about the helm chart.
Head over to Configure & Deploy, where you'll be further setting up your chart configurations.

Step 3: Chart Configuration

In the configuration window, the following details must be provided:

App Name
Project
Environment

You can directly make changes in the chart's configuration file (values.yaml) here as per your requirements. For this tutorial, please add the following details:

auth:
      postgresPassword: "<root_password>"
      username: "<new_user>"
      password: "<user_password>"
      database: "<database_name>"`
Once these parameters are properly set, you are ready to deploy your chart.
Click `Deploy Chart

Congratulations! Your PostgreSQL database is up and running! You can now view the chart details by heading to Helm Apps/PostgreSQL on the dashboard.
You will be able to check out all the resources it has deployed, including

status of the application,
chart version, and many more, as shown below.

NOTE: Please note the service name from here, as that will be used while configuring the Django application.
In this case, it's postgresql-2-devrel

Configuring the Application - Database Settings

Before we dive into deploying our app using Devtron, we have to make some changes to the database settings. Head over to settings.py of our Django application, which contains the configuration for your SQL database.
Make sure the configurations in settings.py match the ones of the PostgreSQL Helm Chart we deployed in the steps above.
In this case, we are providing all the root user's details.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': '<database_name>',
        'USER': '<root_username>',
        'PASSWORD': '<root_password>',
        'HOST': '<service_name>',
    }
}

Once we have configured these settings, we are ready to deploy the application using Devtron

Deploying the Application

It's interesting to know that Devtron is capable of deploying any kind of application irrespective of the language or tech-stack chosen for the project.
Before we create an application, ensure your Global Configurations are set and properly validated.
Please refer to the documentation for more information on the different sections of Global Configurations available in Devtron.

Step 1: Create a Custom Application

Head over to the Create drop-down on the Devtron dashboard and select Custom App. Provide the necessary details asked in the prompt window and click Create App

Step 2: App Configurations

After creating an app, you will be redirected to the App Configuration tab, where you need to provide the following details:

Git Repository: The link to your project on GitHub

In this case, we are using a simple To-Do app

Build Configuration: Provide all the docker-related information to build and push docker images of your app

Provide the details for the container repository to store your image
We are using a Dockerfile for our application, so we will give the path to the same
You can also choose buildpacks as an option to deploy your application if you don't have a Dockerfile. For more information, please refer to the documentation

Base Deployment Template: The main deployment configuration goes here. The beauty of using the Deployment template is that you don't need to manually configure things like pod specs, hpa, service, ingress, etc. All these come pre-configured with the template, and you just have to tweak some values as per the requirements. Following are the steps to configure the deployment of our app: Step 1: Select a chart type from the following options:

Deployment (Recommended)
Rollout Deployment
Job & CronJob

Step 3: Configure Ingress

Configuring the ingress controller parameters as follows:

ingress:
              annotations: {}
              className: "nginx"
              enabled: true
              hosts:
                - host: <YOUR_DOMAIN>
                  pathType: ImplementationSpecific
                  paths:
                    - /<END_POINTS>

You can also refer to the README for the specific Deployment Chart, provided on the platform itself to configure more parameters as per your requirements.
Feel free to check out this blog to configure the ingress controller using Devtron.

Workflow Editor: Here, you can set up a simple CI/CD pipeline for the application in no time using the platform itself. There are mainly 3 types of pipelines that can be created here: (More information in the documentation)

Continuous Integration
Linked CI Pipeline
Incoming Webhook

Furthermore, the CI pipeline may also include Pre and Post-build stages to validate and introduce checkpoints in the build process. These can either be configured using some preset plugins like k6, Sonarqube, etc. (as shown below) or using custom scripts as well.
For more information on Pre-build/Post-build tasks, please refer to the documentation.

Creating a CI/CD pipeline for our Django Application

Step 1: Create CI Pipeline

For creating a CI pipeline, click on + New Workflow -> Build & deploy the source code. In the Create Pipeline window, provide the necessary details as shown below and click on Create Pipeline:

Step 2: Create CD Pipeline

To create the deployment pipeline, click the + icon corresponding to the CI. Configure the details as required, and click on Create Pipeline.

Awesome! You now have a fully configured CI/CD pipeline for your application.

To know more about using the Workflow Editor, refer to the documentation.
As we don't have any ConfigMaps or Secrets for this application, let's move to the Build & Deploy tab and trigger the CI Build.
Step 3: Build and Deploy
In the Build & Deploy tab, click Select Material then select the commit against which you want to build an image, then click Start Build.

This will start building your image. You can also view runtime logs, commit details for the particular build, security results (if enabled), and artifacts.
Once the build is successful, the status will be updated accordingly!

Step 4: Deploy using the Image

Now is the time to deploy the application using the image we built in the previous step.

Now, we can check the status of our deployment on the App Details tab. Once the deployment is successful, it will reflect the Application Status: Healthy.
Furthermore, you can view all additional information about your deployed application such as:

The deployment environment
K8s resources like pods, services, etc
Manifests of individual resources
logs, and much more

Step 5: View your Deployment
We have successfully deployed our Django app over Kubernetes 🎉
To check whether our application and database are running successfully, we can view this in our browser.
The syntax is: http://<hostname>/<path>
hostname & path would be the ones given in ingress while configuring the Deployment Template (refer to the steps above)

NOTE: An additional step here could be mapping your domain_name with the load balancer IP address, which can be found in the manifest of ingress (as shown below)

status:
  loadBalancer:
    ingress:
      - ip: <IP_ADDRESS>

Conclusion

We have successfully deployed our Django Application over Kubernetes using Devtron. If you like Devtron, do give us a ⭐️ on GitHub, and feel free to join the Discord community for all the latest updates.