Glasskube has been on a tear lately. 🚀

Having only just launched officially last February and having been received incredibly positively by the cloud native and Kubernetes community we are happy to announce that Glasskube Beta is upon us. The Glasskube team as well as the growing community of Glasskube open source contributors have rallied and combined forces to bring the Beta release sooner than expected. Everybody involved deserves a huge round of applause. 👏

As we release Glasskube Beta we aim to bring to Kubernetes engineers tasked with maintaining the lifecycle of the packages that make up their clusters with an expanded and more mature version of Glasskube that delivers on the early promises of on app package configuration, automated updates and an ever growing package catalogue. The Beta release is still not intended to be run in production environments, in order to become production ready in the upcoming releases we hope to get valuable feedback from the Glasskube community.

We are so excited to get this release in the hands of all of you and see what you think. Here as some of the features and updated shipped:

• 👍 Easy package configuration options
• 🏗️ Added dependancy management
• 📊 Shipped graph-based dependency validation
• 🆕 Supported three new packages
• ✨ Many CLI and UI upgrades

Easy package configuration 📦​

One of the main issues we see with traditional Kubernetes package managers is the inability to configure packages without having to depend on third party configuration tools to get the job done. Now with Glasskube if your package depends on additional configuration steps it can be done right in the UI or CLI. Let’s take the example of the k8sgpt-operator, you can decide on which language you want the operators output to be in as well as being able to add the OpenAI API key upon installation to make sure k8sGPT runs right out of the gate.

New package integrations 🆕​

We added to the package catalogue, actively supporting 10 packages. Check out to see both the supported and upcoming packages we will support next right here.

Grafana​

Grafana open source software enables you to query, visualize, alert on, and explore your metrics, logs, and traces wherever they are stored. Grafana OSS provides you with tools to turn your time-series database (TSDB) data into insightful graphs and visualizations. The Grafana OSS plugin framework also enables you to connect other data sources like NoSQL/SQL databases, ticketing tools like Jira or ServiceNow, and CI/CD tooling like GitLab.

K8sGPT​

K8sGPT is a tool for scanning your kubernetes clusters, diagnosing and triaging issues in simple english. It has SRE experience codified into its analyzers and helps to pull out the most relevant information to enrich it with AI.

Kube Prometheus stack​

A collection of Kubernetes manifests, Grafana dashboards, and Prometheus rules combined with documentation and scripts to provide easy to operate end-to-end Kubernetes cluster monitoring with Prometheus using the Prometheus Operator.

Next packaged to be supported ⏭️​

Litmus​

Litmus is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way.

Kubeflow​

The Kubeflow project is dedicated to making deployments of machine learning (ML) workflows on Kubernetes simple, portable and scalable. Their goal is not to recreate other services, but to provide a straightforward way to deploy best-of-breed open-source systems for ML to diverse infrastructures. Anywhere you are running Kubernetes, you should be able to run Kubeflow.

Robusta​

Robusta is an open source observability tool for Kubernetes, which extends Prometheus. Using automation rules, Robusta automatically fetches the data you need to investigate, and attaches it to your alerts.

Check our of webinar last Tuesday with Kunal Kushwaha 🌐​

Here Glasskube co-founder Philip Miglinci walked us through the new Glasskube features, improvements and gave a greate demo that included how to install and manage kubernetes packages using a GitOps framework by leveraging ArgoCD and a super simple process to seemlessly manage your cluster package stack. Really cool talk!

We launched on Product Hunt 😼​

We launched the project on Product Hunt on April 24th.

It was a great exercise to get Glasskube in front of an audience that we might not have known about the project. Product Hunt isn’t best know for showcasing developer tools but he got a great reception from the community and some stellar feedback too. Well worth the effort.

By getting a sizable amount of upvotes for a niche DevTool, we are extremely happy to see those upvotes translating over to many users visiting the GitHub repo and leaving their support and even picking up open issues.

Feedback wanted 🙏​

Glasskube is a tool designed for Kubernetes enthusiasts and engineers alike. As we're currently in the early stages of development, your feedback could be pivotal in shaping the direction and features of our upcoming product roadmap. We invite you to explore Glasskube Beta, integrate it into a non-production Kubernetes cluster, and experience a streamlined approach to managing your third-party cloud-native packages. Share your experience with us, and help us refine Glasskube for optimal usability and effectiveness.

Support is always welcome ⭐​

Do you like the project and want to help us out? Giving us a star on GitHub will really make our day!

TL;DR​

As an open-source project maintainer, you should be obsessed with Developer Experience. I don’t need to convince you that the README.md needs to be clear and informative. Everybody knows how great documentation can elevate a project. Having a top-notch CONTRIBUTING.md file is the missing piece to retain the open-source contributors you attract.

The CONTRIBUTING.md file should not be confused with a tutorial or a project guide, it’s reference material for developers who want to understand what work is available and how to get involved quickly.

Make sure your guidelines are:

• Clear and actionable
• Use precise language
• Easy to skim through
• Point to additional resources

Understand your audience​

Developers are not a monolithic group of internet dwellers who all care about the same problems, have the same experience, or work the same way. Having said that, there are a few things that are broadly applicable. They want to read less and build more. 🏗️

Developers care about getting started quickly and it’s on the project maintainer to remove as many obstacles as possible to make that happen.

How can you reduce the time from when a developer finds your project to when they submit their first PR?

To get started, contributors need to find an issue to work on. Make sure you have open issues ready that are tagged to cater to all potential contributors. If a junior developer wants to learn a new language through your project make sure good first issues are easy to find. If more ambitious, senior types, are ready to make an impact, make sure it’s clear which issues you would like them to consider, pointing them to a current milestone or GitHub project.

Define contribution paths​

Make clear what kind of paths there are to contribute to. Which areas of the project need help? Leverage GitHub tags to segment each project domain. In our case, Glasskube has different components such as a GUI, a CLI and Package Controller, Docs, a UI and the repo itself.

Community engagement​

Ok, so the contributor knows that there are open issues ranging in different levels of complexity and they understand the different areas they can contribute to. How can they let you know they are ready to contribute to the project? What if they have additional questions? Make it clear how you prefer them to communicate with you, through GitHub, Discord, or Slack.

Try to not only limit communication to the GitHub issue itself. For many Open Source contributors the fun is meeting other like minded people to collaborate and share. Not to say they everybody want that, but make sure you invite contributors to a community, since they are not part of it.

Contribution workflow​

Probably one of the most important parts of the Contributor guidelines is for contributors to have clear instructions and answers to the following questions

Detailing the step-by-step process for contributing code changes: 🪜

• Issue selection and assignment.
• Forking the repository.
• Branching, coding, and committing conventions.
• Pull request submission and review.
• Handling feedback and iteration.
• Merging contributions into the main codebase.
• Addressing best practices for commit messages and keeping forks up-to-date.

Development guidelines​

Each open-source project aims to solve a different problem and build on a certain stack that might be new to some contributors. Assume they know nothing about your tool and precisely explain the project’s building blocks.

Focus on informing how the code base is built, how each component fits together and describing setup environments. Ideally, contributors should be able to build local versions of the components they contribute to and validate their work.

If you only find out during the PR review process that it wasn’t clear to the developer, it's a sign that either the guidelines or collaboration process could be improved.

Testing​

I can’t stress the importance of providing clear instructions for testing code contributions 🧪. For example, Glasskube operates within Kubernetes clusters, every contributor must have access to one for local testing before submitting a PR. While imposing testing criteria might be challenging, it's essential to remind contributors that PR reviews shouldn't be the moment where issues with functionality are discovered.

Documentation and best practices​

Leverage your documentation heavily, the contributor guidelines as mentioned are reference material aimed at giving guidance by pointing the contributor in the direction of the answer they are looking for. 🔍

Keep the file structure very clear. Most people skim through this sort of material looking directly for what they need at the time. Make your guidelines skimmable.

Also, it’s safe to assume some contributors will never make it to your CONTRIBUTING.md page, and those who do will spend a limited amount of time there. Share a TL;DR that gives the main points you would like contributors to remember. Also, add the TL;DR to other places outside of the GitHub repo. I’ve added it to the #help-forum on our Discord server

I’m really happy you have a killer README.md file, you have a bunch of well-tagged issues and are ready to welcome as many contributors as possible. But to retain and build trust within your community make sure to nail the CONTRIBUTING.md too.

To understand the value of the CONTRIBUTING.md file. I feel a restaurant analogy might be useful.

💡 We've all been drawn to a restaurant by it’s food menu, only to return for the exceptional service. Similarly, in the realm of Open Source projects, the README.md acts as the initial attraction, the enticing menu. However, it's the CONTRIBUTING.md file and how it enhances the overall developer experience that makes them return for more.

It’s well-established that Discord is a great platform for Developer communities. What’s less established are clear, best practices on how to configure a server from scratch to best serve a community of devs. If you are a community manager or Discord moderator, this blog post aims to give you the definitive guide to getting a working server that will feel welcoming, resourceful, and intuitive for all your community members.

Configuring a top-tier server is not difficult at all, the Glasskube server is an example of a “less is more” approach. Having said that, we will explore some additional intermediate and advanced practices that might make sense for some use cases. Let’s not waste any more time and jump straight in.

1. Don't Reinvent the Wheel 🛞​

As developers we spend a large amount of time working on challenging tasks and solving hard problems, Discord can be complex and a bit daunting as a beginner to the platform, but if you take away anything from this blog post it should be that you do not need to over-engineer your server for it to be highly effective.

Any community platform should have the following ingredients:

• Clear lines of communication
• Clearly document known or past bugs
• Easy to navigate
• Relevant and customizable to each community member
• Safe from Bot attacks or raids
• And if it’s fun, even better

Discord as a product has evolved immensely in the last few years allowing community managers to easily adapt the platform to the needs of their ecosystem.

Focus on applying some of the tips in this blog post to build an MVS (minimum viable server), there will always be time to pivot and add fancy features down the road. Let’s take each point one by one.

2. Establish Clear Lines of Communication 🗣️​

Before creating your first channel, think to yourself, what brings a user to your server? Whether it’s product updates, open-source development, or job searching. Make sure those as the main channel lanes.

It’s always good to have a #general, catch-all channel and then a handful of other channels that might guide server members to more targeted conversations around troubleshooting bugs, asking for help, or even having off-topic conversations. If you see the need, consider dividing your channels into categories to give further context.

When a new member joins an overly complicated and cluttered server, it can be daunting to engage and integrate into the community. “Where do I even start?” - Me on most servers.

Simplifying the structure by focusing solely on essential channels, categories, roles, and resources is crucial. This approach creates a welcoming environment where newcomers can easily navigate and become active participants in the community.

3. Are you Into Role-Play? 📛​

Nah, me neither, but they are useful on Discord. Roles are a great way to understand the different user profiles that make up your community and to assign custom permissions.

Most new members are shy and you might not want to force them to introduce themselves when they join. A good way around this is by assigning roles by asking onboarding questions. We will see how to do that in a bit.

Also, not every community member might have the same interests, roles can be used as a filtering system to direct the right people to the appropriate channels.

On the Glasskube Discord server, all members have access to all channels but in the intermediate steps, I’ll show you how to unlock channels based on different roles.

💡 Each Discord server has the default @everyone role. Use the principle of least privilege when configuring this role. Allow @everyone to view and interact in text channels and voice channels, but make sure no actions can be taken upon other members nor any management permission given either. To add permissions to users, create roles and attach the roles to the user directly.

4. Enable the Community Feature ✅​

If you’ve set up Discord servers in the past you more than likely used bots like “carl” bot for onboarding, role assignments, and moderation. No need for that now, let the Community feature take care of that for you. This feature does 80% of the heavy lifting for you as a Discord Community Manager by combining security, member verification, and onboarding all in one. Just follow the instructions to set up:

1️⃣ Onboarding questions 2️⃣ Server guide 3️⃣ Safety guidelines

💡 To enable the community server feature, click on your Server name at the top right > Server settings > Community Overview > Activate.

By enabling the Community feature you unblock additional channel types such as forums, stages, and announcements.

5. Have a Short but Effective Onboarding Process 👋​

An onboarding process should serve two major functions, first of all, to get to know new members better, and second to let members know what they can find on your server. Customize the onboarding questions and answers to your liking, and assign roles or even channels to the user depending on the answer given. Here are the two questions we ask new Glasskube community members.

6. Structured Help and Support Forums 🆘​

Don’t let questions asked in your community go to waste. Persist them in a centralized place so newcomers can learn from others’ past questions. The best way to do so is by using channel Forums.

They act as a useful supplement to the official project documentation. Many OSS software projects struggle to keep their documentation up to date and here is where the forums can lend a hand, by documenting and persisting conversations revolving around troubleshooting efforts. If new members pose questions that have already been answered in a forum, send the forum thread instead of resolving the same issue twice.

Check out the questions forum on the Wasp discord server, they are a great example of neatly, well-tagged questions that are a huge help to community members old and new.

💡 When setting up your forum section create useful and relevant tags and enforce their usage on each question so they can be easily filtered and contextualized when needed.

7. Keep the Announcements Coming 🎉​

As a vibrant OSS project, you are probably releasing as much as possible and sharing community-relevant topics regularly. Make sure to have at least one Announcement channel and keep it up to date.

💡 Announcement channels, different from other channels can be subscribed to and viewed from outside your server. If you want to push updates to your channel followers make sure to click the “Share with followers! Publish” button once an announcement is shared.

Announcement channels accept webhook integrations making YouTube videos, live Twitch streams or Canny roadmap updates appear automatically.

8. How to Avoid Raiding, Spam, and Nukes ⚠️​

We have all seen spam and sometimes inappropriate messages and links to crypto scams on Discord servers before. Hopefully none of you will ever have to see a fully wiped server that suffered from a nuke attack. In the past, you would lean on the healthy ecosystem of Discord bots which many of them had a generous free tier that would secure your server to a pretty high level. Now, those third-party safety bots are just not needed, since Discord add many layers of Raid and Spam protection as well as some AutoModerator functions and easy to congure setting which you can set once and forget. Once configured, Discord in the background with scan and vet each message, attachment, and new member as they join.

💡 In DM and Spam protection, you can choose the verification level. I like to set it to Medium which will only verify a member once they are part of the server for over 5 minutes. Therefore, weeding out potential bot traffic.

9. Adding Fun with Emojis and Stickers 🤣​

It’s important to not be so serious and enjoy yourself too. Make sure to provide some inbuilt stickers and emojis that your community can relate to and use to express themselves.

Find some cool stickers here: https://stickers.gg/ Download enojis here: https://emoji.gg/

You can find the emoji and sticker settings in the Server settings section also.

What the Glasskube server looks like now, join us! 🧊​

Having put all the tips mentioned above in practice this is what our Discord server looks like. If you feel like checking it out or becoming part of the community join us here.

10. Let’s Talk Intermediate and Advanced features 🤓​

All of that seemed pretty straightforward, right? In case you are looking to get fancy, let’s explore a couple of intermediate and advanced features.

💡 Discord has a subscription plan which uses Nitro as currency, Nitro can be bought with fiat currency. By buying boosts you can unlock many features and add-ons, mainly cosmetic and image quality-related, but feel free to check them out.

Intermediate​

It might be the case that over time your server grows and so do the number of channels. Since a large number of available channels can be disorientating for new members you can allow members to opt-in through additional onboarding questions.

💡 Note that even if you don’t answer the questions during onboarding you can always click on Channels and Roles in the top left-hand corner of the server to answer any onboarding questions to gain access to any locked channels.

To get started, navigate to Server Settings> Community Onboarding > Default channels, and only select the channels you want all members to see.

Then edit the onboarding questions and unlock channels depending on the answer by adding the channel to part 2 Assign channels and/or roles

Advanced​

Similarly, if you have a growing server with multiple announcement channels that you want to give granular access to. For example, if a user with the @contributor role only wants Glasskubee updates and not general Kubernetes updates you can gain this level of granularity by switching to Advanced mode in the Onboarding section of the Server settings page.

You can also be granular about the amount of time is needed for a new member to send a message in a particular channel by editing the Slowmode setting, under channel settings.

Let’s Wrap It Up​

A community platform is a place that should be conducive to creativity, comradery, and collaboration. Of course, some rules and guidelines should be in place to keep the place welcoming and inclusive to all, but all in all the key takeaway is to not overthink or over-engineer your server. Decide on some key roles, and key channels and resolve people's issues in a centralized way with answers to questions easy to find and hopefully don’t always depend on your input.

A community is made up of individual connections to try to focus more on initiatives that will lead to open conversation and always try to acknowledge key community members when they deserve it.

Get involved​

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

⭐ glasskube/glasskube ⭐

Glasskube v0.1.0 was released on March 21st, introducing new features like Dependency Management and Dark Mode as well as many useful features for an improved CLI and GUI experience.

Glasskube is fully open-source. Support us by leaving a star: ⭐ glasskube/glasskube ⭐

🙏 Special thanks to all our contributors 🥰​

Once again, we can't thank our community enough for their valuable input and exciting contributions to Glasskube. We are happy you choose to be part of our journey in making Kubernetes package management easier for everyone.

This release includes:

• 👥 a total of 10 contributors
• 🛠️ 53 commits
• 💥 no breaking changes

Watch our release video to get an overview of what has changed:

Most notable changes​

Dependency management 🔗​

Building on the package installation features shipped in the previous weeks, we now offer an in-built way of managing and installing the dependencies used by your desired package. Now package maintainers can define the appropriate dependencies, for each Glasskube supported package as well as recommending the range of suitable dependency versions, this way ensuring that packages are always compatible to accompanying dependency.

Package dependencies will show on the installation drop down in the GUI. They will also be shown when installing a package via the CLI.

Dark Mode 🕶️​

Great news, we shipped the "must-have" feature any OSS project can't survive without, Dark Mode. Glasskube's dark mode is linked to the display mode defined on your local system. Access your system preferences menu and try it out!

Further improvements​

We also worked hard on improving existing commands and our GUI. Here's a list of further notable changes:

• The --latest flag was added to the glasskube bootstrap command to ensure the latest version of the package controller is being used.
• The GUI now reflects the available dependencies for selected packages.
• We expanded the describe command to include the installed dependencies.
• You will now be greeted by a notification pop-up if "open" fails.
• Version mismatch detection was added to the package controller.

BREAKING changes​

This release does not contain any breaking changes.

All Release Notes​

The release notes can be found here: v0.1.0 release on GitHub

All changes can be found here: Comparing v0.0.4 to v0.1.0

How to upgrade​

Follow the installation instructions below to download the latest version of the Glasskube client. After that you need to upgrade the server component (Package Operator) by bootstrapping Glasskube again:

glasskube bootstrap --latest

Getting started​

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

brew install glasskube/tap/glasskube

dnf install https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.rpm

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.deb
sudo dpkg -i glasskube_v0.4.0_amd64.deb

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.apk
apk add glasskube.apk

nix-shell -p glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved​

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

⭐ glasskube/glasskube ⭐

Glasskube v0.0.3 was released on February 27th, introducing package updates and many useful features for improved CLI and GUI experience.

Glasskube is fully open-source. Support us by leaving a star: ⭐ glasskube/glasskube ⭐

🙏 Special thanks to all our contributors 🥰​

Once again, we can't thank our community enough for their valuable input and exciting contributions to Glasskube. We are happy you choose to be part of our journey in making Kubernetes package management easier for everyone.

This release includes:

• 👥 a total of 10 contributors
• 🛠️ 64 commits
• 💥 no breaking changes

Watch our release video to get an overview of what has changed:

Most notable changes​

Package Updates​

Updating packages is one of the most essential features of any package manager. That's why most of our efforts in the past two weeks have gone into the support for such updates via CLI and GUI. It's as easy as typing glasskube update into the command line, or a button click in the GUI.

During package installation you now can decide whether you want automatic updates for the package, in which case the Glasskube package operator will take care of keeping you up to date at all times. You can of course opt out of this feature if you prefer to handle updates manually. Apart from that, with the --version flag you can choose which version of a package is to be installed, if your use case requires a specific version.

For technical details, please have a look at the package operator documentation.

Further improvements​

We also worked hard on improving existing commands and our GUI. Here's a list of further notable changes:

• The glasskube describe command – and its GUI-complement, the package detail page – have been implemented for you to have a more detailed view on each of the packages available in Glasskube.
• glasskube list has been extended with the new flags --outdated – listing only outdated packages, and --show-latest – showing the latest available version for each package.
• All commands check for a newer version of Glasskube, and notify you if you are not up to date anymore.
• Glasskube is now even easier to set up: The GUI comes with handy pages for selecting a kubeconfig and for bootstrapping Glasskube in a cluster. All CLI commands will also support you in setting up Glasskube in your cluster.
• Streaming any kind of package status change directly into the GUI, making it easier for you to recognize when something is happening in the background.

BREAKING changes​

This release does not contain any breaking changes.

All Release Notes​

The release notes can be found here: v0.0.3 release on GitHub

All changes can be found here: Comparing v0.0.2 to v0.0.3

How to upgrade​

Follow the installation instructions below to download the latest version of the Glasskube client. After that you need to upgrade the server component (Package Operator) by bootstrapping Glasskube again:

glasskube bootstrap

Getting started​

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

brew install glasskube/tap/glasskube

dnf install https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.rpm

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.deb
sudo dpkg -i glasskube_v0.4.0_amd64.deb

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.apk
apk add glasskube.apk

nix-shell -p glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved​

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

⭐ glasskube/glasskube ⭐

In this blogpost we are reviewing Kubernetes Management Frontends and discuss how these tools are being built.

The rise of Kubernetes in recent years has led to an astonishing number of open-source Kubernetes management tools seemingly appearing out of nowhere. The goal of the research leading to this article was to merely understand the architecture of some of these tools and to subsequently provide a brief overview and options for developers trying to get started with their own Kubernetes frontend. We will not dive deep into the actual tools and what problems they are trying to solve, but instead focus on the software engineering aspect. We are also exclusively exploring open-source and self-hosted tools and leaving the PaaS/IaaS platforms of cloud providers aside — that would be a whole different article.

Setting up and interacting with your first cluster can be overwhelming. Just like me, you might have come across the infamous kubernetes/dashboard, followed the installation instructions, and asked yourself: "What did I just do and why exactly does this work the way it works?" And after some tinkering with your cluster, you might have installed even more external tools that help you with some specific aspects of cluster management, providing you with either a CLI or a Web UI.

As a software engineer mostly engaged in web development in recent years, I was curious about how these kinds of tools are built and deployed.

Let's first clarify some of the basics needed for the following exploration of different Kubernetes UIs. After that, we will see what they have in common and what makes this kind of software special, to finally form a recommendation of how one could build a Kubernetes Web UI themselves.

Kubernetes Basics​

The official documentation is more than helpful anyway; there is just one important thing to remember: Whenever and wherever you interact with your cluster, you do it via the Kubernetes API — this holds true at least for the scope of this article, though there might be other use cases.

As a consumer of this API, one needs to know where it is hosted and how to authenticate against it. The Kubernetes API can be accessed both from inside a cluster (i.e., from an application running on a pod) and outside a cluster (e.g., from your command line). In some cases however, the API is only available from within a VPN.

Since we are looking at tools with a web UI, this UI and its backend need to be exposed such that a user can access it. The options are:

• using kubectl proxy to open a proxy from the local machine to the cluster (see Accessing Clusters),
• using kubectl port-forward to forward a local port to a specific pod of the cluster (see Use Port Forwarding to Access Applications in a Cluster),
• using a Kubernetes service of the type LoadBalancer to access an application of the cluster (see Use a Service to Access an Application in a Cluster).

Alternatively, the web server could be running on the local machine of a user as well, in which case one doesn't need to worry about these options. However, a user needs to have a valid kube config on their machine for any of these approaches to work.

Management Frontends​

Now, let's take a look at some commonly used frontends and how they are built.

kubernetes-dashboard​

The Kubernetes Dashboard is a popular Web UI used to view and manage all kinds of Kubernetes resources within a cluster. In the latest stable version 2.7, both the backend and frontend are part of the same container. The Go backend serves both the API and the Angular UI assets. This deployment strategy requires users to use kubectl proxy to access the web application.

In the newer 3.0 version, which is still in alpha, the deployment strategy has changed: both the backend and frontend are each running in a dedicated container. Therefore, accessing it via kubectl proxy no longer works because the UI needs to access the backend, which is running on a different pod and port. The port-forwarding approach described here should be used instead.

ArgoCD​

ArgoCD is a GitOps continuous delivery tool for Kubernetes. It comes with several components, including its own API server and a web UI. All the backend components are written in Go, and the UI is a React application.

As with the Kubernetes Dashboard, the server (including the UI assets) is deployed inside the cluster, making it necessary for the user to perform port-forwarding or use a LoadBalancer. This is described in their documentation.

Lens​

Lens is a Desktop UI, but still interesting for our exploration. It is being developed with Electron, React, and Typescript. The Lens App uses the Typescript Kubernetes client to connect to a cluster, and since the Desktop app is clearly running outside a cluster, it uses a locally provided kubeconfig to connect to it.

glasskube​

Yes, a pretty shameless plug (I work there), but it's also an interesting alternative to consider. For the UI of the Glasskube package manager, we spin up the web server locally via a CLI command and serve the UI assets from there. We decided to go this route because it simply makes more sense in our use case. Whenever the user needs the Glasskube UI, they host it themselves for as long or as short as they want — there is no need to have it running 24/7 inside the cluster.

Findings​

Many open-source Kubernetes management UIs are coded in a similar way — with a Go backend utilizing the powerful Kubernetes-go client, and a Single Page Application in JavaScript as the frontend. In most cases, the web assets (e.g., JS files) are served together with the backend, meaning one container serves both the backend and frontend. It was actually difficult to find something that is not built like that.

Inside cluster vs. Out of cluster​

When it comes to deploying such a web tool, there are only two options:

• The webserver is deployed on a pod inside the cluster and is accessible either via proxy, port-forwarding, or ingress.
• The webserver is deployed outside the cluster, directly (locally) on the users' machine.

The Kubernetes clients (e.g., Go client) support developers with both methods to connect to a cluster, as we can see in the following examples.

The piece of code it all comes down to:

These simplified examples are heavily based on the official examples seen here and here.

Let's have a look at how to connect to the Kubernetes API when running the application inside the cluster:

import (
	"context"

	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/rest"
)

func main() {
	// retreive the config for the cluster we are currently in:
	config, err := rest.InClusterConfig()
	if err != nil {
		panic(err.Error())
	}

	// create the clientset for this config:
	clientset, err := kubernetes.NewForConfig(config)
	if err != nil {
		panic(err.Error())
	}

	// do something with the clientset, e.g. getting all pods in the cluster:
	// pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
}

The Go client implementation uses the pod's service account and the environment variables KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT to identify which cluster it is placed in. Subsequently, it creates the REST config object, with which the clientset can be obtained.

Similarly, when running outside the cluster, one needs to create the config object, but this config is read from the local kube config:

import (
	"context"
	"flag"
	"path/filepath"

	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/tools/clientcmd"
	"k8s.io/client-go/util/homedir"
)

func main() {
	// get the passed (or default) kube config file path
	var kubeconfig *string
	if home := homedir.HomeDir(); home != "" {
		kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional) absolute path to the kubeconfig file")
	} else {
		kubeconfig = flag.String("kubeconfig", "", "absolute path to the kubeconfig file")
	}
	flag.Parse()

	config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig)
	if err != nil {
		panic(err.Error())
	}

	clientset, err := kubernetes.NewForConfig(config)
	if err != nil {
		panic(err.Error())
	}

	// do something with the clientset, e.g. getting all pods in the cluster:
	// pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
}

Again, the Kubernetes Go client has us covered with a simple function to parse a kubeconfig file to get a config, which can then be used to create a clientset.

When trying to run these simple examples, you will also come across one difference between these two approaches: Running the local tool is easier because you don't need to build an image, push it to a registry, and then pull it into the cluster.

Which one to choose?

Say you were to build your own Kubernetes UI in a similar fashion. When it comes to the decision of where the webserver of your tool should run, there are several things to consider:

• Distribution: Running your tool inside the cluster means you have to build and distribute a docker image. On the contrary, you will have to distribute a native binary if you want users to install it on their machines. For both cases, there are lots of tools and resources online.
• Availability: When your cluster is down for whatever reason, users might not be able to reach the tool hosted inside the cluster. This leads us to the next point:
• Onboarding User Experience: This might be an edge case, but a locally hosted web tool is available before all of its components are installed in the cluster. This means you could implement some sort of UI onboarding flow for new users, making the tool easier to install and set up.
• Compatibility: Multiple users of the same cluster could have different versions of your (locally hosted) tool installed. This can not happen if there is just one webserver running inside the cluster.
• Persistence: When needing to store tool-specific data (i.e., non-Kubernetes resources), you could store it inside the cluster (e.g., in a ConfigMap). For the locally deployed variant, you could additionally store user-specific data like settings on the users' machine. This decision is highly use case dependent.
• Developer Experience: There seems to be no significant difference, but it is worth noting that when developing an in-cluster webserver, during development this server still needs to support the out-of-cluster config approach somehow. Otherwise, one would have to build and deploy an image into the cluster after every change.

Eventually, whether the tool is deployed inside or outside of the cluster is completely up to you, but it's always important to consider the use cases and be aware of the context in which it is used. You can also opt for providing both options to your users.

For us at Glasskube, it was clear that we want to provide an easy-to-use interface for new users (especially those new to the Kubernetes world), who might not have yet set up all the Glasskube cluster components. These users can be supported by having a CLI command hosting the local webserver with a supportive Web UI.

Conclusion​

In this article, we have explored a few Kubernetes tools offering a web UI and analyzed the web aspect of those tools from a software engineer's point of view. There is clearly no ultimate one-size-fits-all solution for how to design and develop such tools, but the list above hopefully gives some hints in the right direction. As always in software engineering: It depends.

One more plug: I work at Glasskube, where we are building the missing Kubernetes package manager. If you are interested in our work, make sure to star us: glasskube/glasskube. We are also working on an article shedding some light on different CLI frameworks, if you are more of a command line person. And if that's not enough, we might write about using htmx soon because it's trending, and we need your attention. I can already see the headline: "How we reduce our codebase by 95% by using seemingly old-school technology" — I think this has not been done before ;)

Glasskube v0.0.2 was released on February 9th, just 9 days after initial technical preview release.

Glasskube is fully open-source. Support us by leaving a star: ⭐ glasskube/glasskube ⭐

🙏 Special thanks to all our contributors 🥰​

We didn't anticipate rolling out our second preview release just one week after the initial one, but thanks to the remarkable contributions from our community, that's exactly what we've done.

This release includes:

• 👥 a total of 14 (mostly new) contributors
• 🛠️ 58 commits
• 💥 no breaking changes

Watch our release video to get an overview of what has changed:

Most notable changes​

Of all changes, bugfixes and improvements, two new features stand out in the second release:

The open command​

Introducing Glasskube's newest feature: the open command! Gone are the days of laboriously setting up multiple TCP tunnels with kubectl port-forward just to access specific services. With Glasskube, accessing your desired services is now as easy as a click or a simple command. Say goodbye to unnecessary complexity and hello to effortless convenience.

Realtime updates with htmx​

The second-biggest achievement of this release: The integration of htmx for real-time updates. This advanced feature enables automatic and instantaneous updates to your graphical user interface, eliminating the need for manual page refreshes. With htmx, your application stays dynamically synchronized with backend changes, ensuring a seamless and responsive user experience.

BREAKING changes​

This release does not contain any breaking changes.

All Release Notes​

The release notes can be found here: v0.0.2 release on GitHub

All changes can be found here: Comparing v0.0.1 to v0.0.2

How to upgrade​

Follow the installation instructions below to download the latest version of the Glasskube client. After that you need to upgrade the server component (Package Operator) by bootstrapping Glasskube again:

glasskube bootstrap

Getting started​

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

brew install glasskube/tap/glasskube

dnf install https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.rpm

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.deb
sudo dpkg -i glasskube_v0.4.0_amd64.deb

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.apk
apk add glasskube.apk

nix-shell -p glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved​

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

⭐ glasskube/glasskube ⭐

🧊 Glasskube is the next generation Package Manager for Kubernetes 📦

Featuring a GUI and a CLI. Glasskube packages are dependency aware, GitOps ready and can get automatic updates via a central public package repository.

Support us by leaving a star on GitHub: ⭐ glasskube/glasskube ⭐

We got accepted into the CNCF Landscape​

Glasskube is now visible next other relevant projects in the cloud native ecosystem landscape like Helm or Backstage.

The goal of the cloud-native landscape is to gather and categorize projects that are relevant to the cloud native developers, offering a comprehensive overview of the existing ecosystem.

By exploring this landscape, project teams can make informed decisions about tooling, technology stack selection, and best practices. Moreover, it facilitates access to emerging innovations, fosters community collaboration, and ensures compatibility and interoperability, all of which are critical for the success of Kubernetes deployments.

Glasskube is part of the Application Definition & Image Build category​

Application definition and image build tools encompass developer-focused and operations-focused functionalities, aiming to simplify Kubernetes deployment and app management. They address challenges of complexity in containerized environments, offering solutions for reproducible image creation, standardized app deployment, and simplifying developer and operator experiences. Tools include Helm for deploying third-party apps, the Operator Framework for building and deploying operators, and Cloud Native Buildpacks for containerizing application code. These tools help streamline Kubernetes development and operations, offering diverse solutions for various use cases.

Accepted in just 7 days after the launch​

The pull request #3735 got accepted just 7 days after the released of our first technical preview of Glasskube.

Glasskube was accepted into the CNCF landscape category due to its ability to effectively address the critical challenges within application definition and image build, underscoring its importance in streamlining Package Management on Kubernetes.

View Glasskube in the CNCF Landscape​

Glasskubes entry in the CNCF landscape

Try out Glasskube yourself​

You can already get your hands on Glasskube and install the first available packages. You can find the correct installation instruction for your operating system:

brew install glasskube/tap/glasskube

dnf install https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.rpm

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.deb
sudo dpkg -i glasskube_v0.4.0_amd64.deb

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.apk
apk add glasskube.apk

nix-shell -p glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved​

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated.

Let us know what you think, we would love to hear from you or support us by leaving a star:

⭐ glasskube/glasskube ⭐

The aim of this post is to share our technical preview of how a cloud native package manager could work and what challenges need to be solved.

Glasskube is fully open-source. Support us by leaving a star: ⭐ glasskube/glasskube ⭐

Introducing Glasskube — The next generation Package Manager For Kubernetes​

Package Management on Kubernetes is one of the most pressing issues in the Cloud Native community. A concept which is widely known from other ecosystems like desktop and mobile computing has yet not been realized for cloud computing. For example on Android and iOS, millions of developers publish their packages in the Play Store or App Store to reach their users. The package manager also makes sure all users receive the latest version published by the developer and the developer receives crash reports and user feedback as a return to improve their applications, but as a cloud native developer there is no package manager you can rely on — yet.

Our first release (v0.0.1) already features a working prototype that can install basic packages, but a lot of challenges still need to be solved.

A cloud native architecture​

Glasskube itself is designed as a cloud native application. Featuring an easy to install client that comes with a graphical user interface and autocompletion for your favorite shell.

At the heart of the Glasskube package ecosystem lies our central package registry which holds the package manifests. In a future version we also plan to support 3rd party registries and the possibility to use multiple registries in a cluster.

The Glasskube package operator syncs the latest manifest into the cluster and makes sure it will be updated as soon as a new manifest is available.

Challenges that need to be solved​

We already covered some our upcoming features in our public roadmap, but I would also like to take this opportunity to shortly speak about broader challenges.

Kubernetes version compatibility​

Kubernetes releases minor versions every 4 months, which often come with new API versions. Package authors need to adapt their packages to these changes. In Kubernetes, a particular release might include more than one API version of a resource, so that packages can be compatible with a broader range of Kubernetes versions. These compatible versions are often only documented in the package distributors' changelog. Glasskube aims to incorporate this kind of metadata in combination with automatic checks from tools like kube-no-trouble or Pluto.

The user should not be required to drudgingly check all packages for compatibility and package developers should get feedback if their package is not compatible with the latest API versions.

Package dependencies​

Cloud native applications often interoperate and there are some packages that can be found in almost every Kubernetes cluster. For example: cert-manager, Ingress controllers or database operators. Due to the lack of a package manager and ecosystem these dependencies are still often only documented in the Getting started section of an application.

In an ideal world a package author could simply specify a dependency of their package and the package manager ensures that all these prerequisites are fulfilled.

Testing​

In order to support multiple Kubernetes versions, dependencies and packages Glasskube needs to build massive automated testing infrastructure for all packages in its central package registry.

Feedback and package quality​

As seen in other package managers like the arch user repository or the Play Store and App Store users' feedback and reviews help other users to decide between different packages. Also, application developer will incorporate users' feedback to gain popularity and better ratings in the package manager.

Glasskube and Helm​

Glasskube is no replacement for Helm. Helm has its strengths in configuring releases through templating and having the ability to perform upgrades and rollbacks.

Glasskube is laser focused on the administrator who needs to only install and kustomize (pun intended 😉) a single application, but who also needs to make sure multiple packages are kept up-to-date and secure throughout multiple Kubernetes version upgrades and adapting to inevitable breaking changes.

Getting started​

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

brew install glasskube/tap/glasskube

dnf install https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.rpm

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.deb
sudo dpkg -i glasskube_v0.4.0_amd64.deb

curl -LO https://releases.dl.glasskube.dev/glasskube_v0.4.0_amd64.apk
apk add glasskube.apk

nix-shell -p glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Release Notes​

All release notes can be found on GitHub: https://github.com/glasskube/glasskube/releases/tag/v0.0.1

Release Video​

Get involved​

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated.

Let us know what you think, we would love to hear from you or support us by leaving a star: ⭐ glasskube/glasskube ⭐