Forem: Kubeshop

Introducing Botkube Fuse: The Platform Engineer’s Copilot

Kubeshop — Tue, 03 Sep 2024 18:42:31 +0000

The daily grind of platform engineers entails constant switching between tools, handling infrastructure issues, and responding to a never-ending stream of requests. It's not just about keeping things running—it's about doing so while juggling multiple tasks, troubleshooting, and making sure nothing falls through the cracks. We created Botkube Fuse because we know the pain firsthand and wanted to build something that makes our work not just manageable, but truly efficient.

The Problem: Context Switching is Draining Your Productivity

We’ve all been there—midway through troubleshooting a failing CI/CD pipeline, only to be pulled into another task. Whether it’s answering a developer’s query about infrastructure or checking the latest status on a Kubernetes deployment, the constant need to switch contexts is exhausting. Every time focus is shifted we risk losing critical details, slowing down our response times, and increasing the likelihood of errors. It’s frustrating and it eats into the time we could be spending on more impactful work.

The Solution: Your Intelligent Platform Assistant, Right in Your Terminal

Botkube Fuse is built by platform engineers, for platform engineers. It's not just another tool; it's a powerful assistant that understands the ins and outs of your infrastructure and day-to-day tasks. We designed Fuse to help you cut through the noise, automate the repetitive stuff, and keep you focused on what really matters—solving problems and driving innovation.

Fuse is your intelligent Platform Engineer assistant, embedded right into your workflow. It brings together insights from your CI/CD pipelines, infrastructure, and services, so you can get the information you need, when you need it—without the constant back-and-forth between different platforms. Whether you’re managing secrets, checking on CI runs, or troubleshooting an outage, Fuse is there to assist with just a few commands all within your terminal window.

Let’s talk about the real impact of Fuse on your day-to-day tasks:

Stop Wasting Time on Repetitive Tasks: Fuse automates the mundane, like managing secrets or digging through logs, so you can focus on the tasks that actually require your expertise.
Get Instant Answers, Stay in Flow: Instead of switching tabs and tools, ask Fuse a question and get the information you need right where you are. Whether it’s checking which database is used by a service or figuring out why a deployment failed, Fuse gives you the answers directly in your terminal.
Make Informed Decisions Faster: Fuse analyzes data from multiple sources–initially Google Cloud Platform (GCP), Kubernetes, and Github with more to come–and provides you with actionable insights such as detecting secret mismatches, identifying IAM misconfigurations, and pinpointing flaky tests.‍
Minimize Distractions, Maximize Focus: By centralizing your tasks and providing intelligent recommendations, Fuse reduces the mental load of context switching, keeping you in the zone and more productive.

Botkube Fuse in Your Daily Workflow

Imagine starting your day by getting a clear summary of your CI/CD pipeline’s stability for the past month, with insights on any flaky tests and suggested fixes—all without having to manually check every run. Or multiple pods in your production GKE cluster are crashing, and instead of scrambling through logs and dashboards, you simply ask Fuse to investigate. Within minutes, Fuse provides a detailed analysis of the pod issues, recent IAM permission changes, and correlated data, along with recommended steps to resolve the issue.

How It Works

Botkube Fuse is a terminal tool powered by a new AI assistant, designed to help with your daily tasks. It’s agentless, operating as a single CLI binary. Just type fuse 'your prompt here…' or fuse to enter interactive mode and start chatting.

Fuse leverages OpenAI’s GPT-4o model and integrates tools for Kubernetes, Google Cloud Platform, GitHub, git, and local filesystem operations. It can even generate and execute Python code. User confirmation is required for potentially dangerous operations, ensuring full control.

Fuse stands out by aiming for end-to-end knowledge of your infrastructure. Currently it introspects GCP projects, with more features planned to provide comprehensive assistance.

Fuse addresses real user problems, especially those at the intersection of different infrastructure parts. It offers AI guidance for scenarios like GitHub Actions secret management, pipeline analysis, GKE troubleshooting, and local environment operations. The assistant categorizes your queries and applies custom instructions, with more scenarios and user customization options coming soon.

Ready to Dive In? Set Up Botkube Fuse in Minutes

We built Botkube Fuse because we needed it ourselves—something to cut through the noise, automate the repetitive, and keep us focused on solving real problems. We’re excited to share it with you and see how it transforms your workflow.

Ready to reduce your context switching and increase your productivity? Getting started is easy. Visit the Botkube Fuse website to download the tool and integrate it with your existing platforms. We currently support Google Cloud Platform (GCP), Github, and Kubernetes with more integrations coming soon. Once you’re set up, start asking Fuse questions directly in your terminal and let it take care of the heavy lifting.

Monokle, Helm & Quality Kubernetes Deployments

Kubeshop — Tue, 22 Nov 2022 00:54:13 +0000

Monokle, Helm & Quality Kubernetes Deployments

Before the cloud native era, we built infrastructure from Digital Ocean tutorials. Developers and IT teams were responsible for provisioning individual servers with all the hardware, networking, OS configurations, and services necessary to run services or apps on the web. That meant installing and configuring an Nginx web server or MySQL database dozens or hundreds of times following pre-approved—and extremely tedious—steps.

Eventually, DevOps emerged and took hold among technology-savvy organizations, which also led to a progression away from raw Linux administration and toward provisioning/configuration management and automation tools like Ansible and Puppet. That was a major step in the right direction, but these teams quickly started to look for faster and more reliable ways to deploy their apps to the web than administering multiple nodes via configuration files.

But now, in the cloud native era, where infrastructure as code (IaC) is not only best practice but also expected, Kubernetes developers shouldn’t have to recreate their infrastructure repeatedly, right?

Unfortunately, we’ve fallen into the same trap. As Kubernetes clusters ballooned in complexity, DevOps engineers found themselves recreating manifests for commonly-needed resources, like web servers or databases, more often than they would like. And as soon as they replicated those assets in multiple places, making minor tweaks here and there, their manifests were no longer reliable sources of truth.

And to complicate matters more, most attempts to add version control—a necessary step in modern DevOps toolkits, were unsuccessful. In an era where the industry continues to trend toward automating deployments with GitOps, reliable version control has become a non-negotiable must-have.

What if the Kubernetes development community had a package manager—like Homebrew for macOS or apt for certain flavors of Linux—for discovering, editing, and maintaining Kubernetes manifests and deployments?

How teams leverage Helm in Kubernetes deployments

Helm is a tool for managing charts, which are packages of pre-configured Kubernetes resources. Charts contain a description of the package in the Chart.yaml file, plus one or more templates containing Kubernetes manifest files in YAML.

Kubernetes developers and DevOps teams are already using Helm for lots of robust use cases, pulled straight from the Helm README on GitHub:

Find and use popular software packaged as Helm Charts to run in Kubernetes
Share your own applications as Helm Charts
Create reproducible builds of your Kubernetes applications
Intelligently manage your Kubernetes manifest files
Manage releases of Helm packages

Overall, Helm provides great benefit for Kubernetes-based organizations eager to speed up their workflows around creating the resources needed for a functional and effective cluster. Instead of rewriting the same common resources repeatedly or mismanaging multiple versions of a manifest, they can use Helm to deploy standard templates with their customizations layered on top.

Unlike Kustomize, which utilizes a locally-stored base and patches YAML files, Helm is most commonly used to install Charts from a public repository like Artifact Hub. For example, Helm simplifies the process of installing the kube-prometheus-stack, which deploys end-to-end Kubernetes cluster monitoring with Prometheus, into just three commands:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install [RELEASE_NAME] prometheus-community/kube-prometheus-stack

What are the challenges of working with Helm charts?

Three commands to install three thousand lines of Kubernetes manifest YAML. For all the advantages Helm creates in terms of “time to deployment,” there are a few headaches that may be experienced in abstraction, visibility, and debugging.

Abstraction: Helm charts are complex groups of rules, configurations, and resources, but the CLI tooling and public repositories make it remarkably easy to deploy to your production environment—for better or worse. In its default settings, kube-prometheus-stack has nearly 3,000 lines of YAML code—how’s that for 1000X abstraction?

Visibility: Most developers and DevOps engineers using Helm will deploy resources and services without ever reading a single line of YAML—which can be extremely freeing or monstrously frustrating, depending on how the deployment goes. And Helm doesn’t make it particularly easy to view and analyze the manifests and templates it deploys by default. Your best option is to manually run helm show values, which only gives you the default part of the picture.

Debugging: For most workflows, the only way to understand what kind of manifests and resources you’re dealing with is by running Helm with helm install --dry-run --debug and hoping you get some meaningful information from the resulting manifest file. Just one extra (and often unnecessary) step that gets in the way of development velocity.

Customization: Helm charts include a values.yaml file that includes the parameters available for customization. The values.yaml file can be quite complicated if the developer wants to add flexibility, but it is not totally flexible: anything not included in the file won’t be parameterizable. Do you want to add a label to the pods for cost management? Bad luck unless the chart already includes it.

How does Monokle Desktop help with deploying to Kubernetes via Helm?

Image of Monokle Desktop Helm Preview

Monokle Desktop is a cross-platform desktop app that helps DevOps teams and developers define, compare, and audit the desired and actual states of their Kubernetes cluster. By layering Kubernetes configuration management and version control into your existing processes around building, optimizing, and troubleshooting complex Kubernetes manifests, Monokle helps you deploy faster and error-free.

And we’ve built Monokle Desktop to be the perfect accompaniment to Helm charts—its configuration management and rich diffs on current vs. future cluster state solves all your core problems around using Helm while retaining the streamlining and simplification you need to work effectively. That starts with native support for creating, analyzing, debugging, and deploying Helm charts.

Navigate your Helm charts

When you add a folder with Helm charts to Monokle, it immediately organizes your Chart.yaml, values.yaml, and template files as shown in the screenshot above. You can see and edit the source code for any selected resource, file or template in the Editor.

Since Monokle understands your Helm templates and their usage of properties provided in your values files, you can interactively identify where properties referenced in your templates are defined:

And correspondingly hovering a property in a values file will show you which template(s) that use it:

Monokle will also help you identify any property references that might be invalid - and since all validation is in real-time you can edit your templates and get corresponding feedback that your errors are fixed accordingly.

Preview and debug Helm charts

Click the Preview button next to any values.yaml file to run Helm on the selected file and show the generated resources in the Navigator. Select a resource to show its generated YAML in the Editor, and use the popups next to each resource to explore how it interacts with others on either side of an incoming/outgoing link.

Through the incoming/outgoing links icons that appear before or after your generated resources, you can quickly understand how the deployments, jobs, pods, and more are interconnected.

You can of course edit any file or template in your Helm Chart and re-run the preview, which helps you immediately understand how your changes impact the generated YAML manifest and, ultimately, your Kubernetes cluster.

It’s a perfect way to make meaningful changes or perform debugging in a controlled, highly-visible environment. Catch bugs before deploying to production or share your Helm chart with others.

Monokle’s Helm preview feature is also customizable—you can even have multiple preview configurations based on your needs. You can select which files to use (and in what order), choose between helm template and helm install, and set other environment variables. Monokle then shows you the complete command it’ll run to create the preview for full visibility.

Example: Defining releases with Helm

A few months ago, you deployed v1.0 of your web application, which consisted of 20 Kubernetes resources. You defined everything in a Helm chart, including a few manifests that serve as templates for multiple resources that require a few small tweaks depending on whether you’re deploying to staging or production.

After the v1.0 release, you immediately got started on v2.0. Along the way, Monokle Desktop’s IDE features, like resource validation and the resource form editor, helped you quickly write new code and prevent any basic YAML syntax errors.

But now that you think you’re ready to launch v2.0, it’s the perfect time to put Monokle into Preview mode to explore the changing relationships and the generated manifest files visually.

Why is this an important step? Because of some new efficiencies, you added to your chart, your web app now only needs 15 Kubernetes resources.

You’re confident that it works, but it’s a dramatic change. With Monokle’s Helm preview and resource navigation tools, you have full visibility into your chart’s inner workings, but you don’t have to scan multiple YAML files or do dry runs on the CLI to debug the output.

You can even click the Diff button to visualize changes in how specific resources will get deployed to your cluster.

It’s the confidence you need to push v2.0 into your version control and prove, through your CI/CD pipeline, that you can deliver a powerfully functional Kubernetes cluster the first time.

Next steps for Monokle

Monokle Desktop roadmap is full of additions to our functional support for Helm. We are adding support for templates, repo management, and many other features that will help you create your own Helm charts easily, fast, and with confidence.

Join the conversation and help us by suggesting functions that will make your job easier.

Take the Helm with Monokle

To get started, hop over to our downloads page to get Monokle for macOS, Windows, or Linux. If you don’t already have Helm installed, you should start there as well.

Whether you’re developing new Helm charts to share with the Kubernetes community or modifying the charts you get from Artifact Hub, we’d love to hear about your experiences with our Manifest IDE. Join us on Discord to share details about your workflows and chat with other Kubernetes developers who are eager to help their Helm-loving comrades better manage manifests at scale.

A Dream Fulfilled at KubeCon NA

Kubeshop — Tue, 01 Nov 2022 00:00:00 +0000

My buddy Jared and I started kubefirst because cloud native platforms take too long to build from scratch. Well, as it turns out, solving that problem also takes a long time - it took us years to mature our instant cloud native platform to the point where we could build a team around it to see the vision through. Over the course of those years, you could pretty regularly find Jared and me on a zoom late at night, waiting for some cloud resources to provision, often killing that time daydreaming about what it would be like to have our platform on the KubeCon floor. Last week, that daydream was realized as our newly acquired project and freshly built team at Kubeshop traveled to KubeCon + CloudNativeCon NA in Detroit.‍

Let's hear it for the sponsors!

We hadn't been at KubeCon more than 30 seconds before we discovered our brand on display and both of our hearts exploded. If you've been working on your project for a long time and share the dream of seeing your logo on a KubeCon wall - YOU MUST KEEP GOING!!‍

Walking around before the show felt a lot like Media Day before the Super Bowl. There was a lot of big energy and anticipation, everyone pushing boxes around with purpose, but it was coupled with a fun show-business kind of vibe. Our sponsor badges afforded us a peek behind the ropes and it was super cool to soak it in first hand. The keynote stage was being set up and all I could do was stare at its absolute enormity with a "some day" pinned to my heart.

GitOpsCon vs `kubefirst local`

We had Monday and Tuesday to get the booth set up and organized. As technical founders we interpreted that to mean that we absolutely had 2 extra days to work on the product. We were almost finished with a new release that would make the installation of kubefirst completely free and 6x faster so we were pretty incentivized to wrap it up.We had originally planned to set up our booth and then head over to GitOpsCon on Tuesday, but with the release unfinished we ended up working through the event and into the night. It was a really tough call to miss GitOpsCon, but we're really glad we pressed on. We needed every last second and ended up wrapping up the release at 1am on the morning that KubeCon opened its doors to our booth. It was such a big team effort to pull off too - we were so excited that we got kubefirst local out the door in time for the big show!!!

Walking through KubeCon is like walking through a kubernetes cluster

Wednesday - at long last our time to show our product to the cloud native world was here!! Walking into the room was the coolest experience ever. When you love kubernetes like I do, the booths instantly turn into physical manifestations of kubernetes namespaces, which is a pretty surreal experience in real life. Walking through KubeCon is oddly like walking through a kubernetes cluster - nginx, cert-manager, hashicorp, linkerd, argo, crossplane - they're all right there - each in their own tidy confined little space.
When I got to our booth I found Jared adding some finishing decorative touches to our namespace. These amazing kubeshop plushies got a lot of attention and were a really fun way to kickstart conversations.‍
We got our first reps in on our product pitch: we're sick of cloud native taking forever to start from scratch, we built a free thing that puts free things together so that the problem goes away. Folks that stopped by our booth loved our vision, our passion for solving the problem, our energy, our relentle-- omg is that Kelsey Hightower?!?!? IT IS KELSEY HIGHTOWER!!!

Meeting some of the great folks in the space

My first star-struck moment came from a handshake with Kelsey Hightower and the conversation that followed. Kelsey was giving some of his time for a book signing just a few booths away from ours, and we couldn't possibly miss the opportunity to meet him in person. Kelsey has given so much over the past half decade to demystifying and simplifying the message of complex technologies - and Jared and I, along with the rest of the kubernetes community, have greatly benefited from his anecdotes.
When we told him our kubefirst story - that after 3 years we had finally made it to our first KubeCon - he offered to put the book line on hold for a quick moment, so we could jog over to our booth for a photo with the Kubeshop family that helped make it happen. Uh – yeah, Kelsey, that sounds pretty freaking amazing actually!!‍I'm the guy who looks like he just met his childhood hero 😅. Don't zoom in, it's sort of embarrassing. We jogged back to his book signing line and he continued to offer us helpful ways for us to stay in touch, and how he might be able to help our project, and on and on and on, as if we didn't totally just hold up his line. It was like we were the only people in the world for a moment. It was seriously beyond words - despite thinking I knew how genuine and decent he was from his stories, my expectations still fell short of reality. What a guy. Maybe 1 hour later, who did I run into but Pinky Ravi from Weaveworks!! I met Scott Rigby the next day too - what an awesome duo these two were. We knew them from their talks, obviously, but also from the OpenGitOps group meetings that we've been attending since joining Kubeshop. They gave us their time to listen to our vision for the kubefirst platform and now we're even talking about how we might offer a second GitOps driver option with Flux CD on the kubefirst platform - how exciting that would be!!!
We had so many great conversations and met so many amazing people throughout the week, so many new opportunities to partner on initiatives. If networking in the kubernetes space is a goal of yours there really is nothing quite like KubeCon.

Pitching on the floor is admittedly a little exhausting

Turns out pitching your product feels a lot like being on stage giving a talk. I've given some long talks in my day and I'm a pretty social person. I've always wondered how long I could be up there. Turns out for me it's exactly 8.5 hours - after that I was immediately ready to crawl under a rock and hide for the rest of my life. But the pitching was great and we loved getting so much immediate feedback on our platform from so many different people in different environments with different needs. That amount of valuable feedback in that short amount of time would have been impossible to collect any other way.‍

There's some room for fun at KubeCon too

There is indeed some time in the evenings where you can take a breath and enjoy the event a little - especially if you're not cramming in a release at the last minute. Kubeshop is a global and geographically distributed team so it was especially neat to take a breath with our work family and soak in the moment we had all worked so hard to achieve.

Never give up - it's soooo worth it

If you're working on a passion project, especially a self-funded one, it can be hard to keep going. Nights and weekends aren't easy to add to your workload. Cloud bills can pile up. I hope no matter what your passion is, you'll get across your first finish line and make it to an event like KubeCon. The satisfaction of turning your passion into a product that's respected by the most amazing peers on the planet is something few get to experience, but I bet it only happens when you refuse to give up.
Thanks for reading about our dream come true moment. It didn't happen because we're geniuses. We're here because of countless strangers who were willing to listen to our story, hear about our product, and help us find our way. If I can ever pay it forward and give you my thoughts on your passion project, I hope you'll consider me an ally and reach out. I'm pretty easy to find on Linkedin and Twitter.‍

How Kubefirst Builds Kubernetes Platforms in 8 Steps

Kubeshop — Thu, 22 Sep 2022 00:00:00 +0000

An Open Source Approach to Self Hosting a GitOps Platform

Kubernetes is one of the most transformative open source projects in the history of computing. It provides a straightforward framework for running software in containers and provides simple solutions to all of the complexities that arise from microservice architectures: load balancing, autoscaling, high availability, resource pooling, application inventory, configuration, fault tolerance, and observability. It also abstracts your software architecture from your cloud, allowing you to pick up your complex solution and run it in another cloud provider with very little impact to your software ecosystem.
Because Kubernetes is so efficient at managing containerized software, vendors have invested the last half decade adopting a “Cloud Native” architecture, meaning their software can run easily on Kubernetes. This has produced a thriving open source community that is heavily committed to running software in a consistent, predictable, manageable way with engineers that share a uniform vision. According to the CNCF, Kubernetes is now the second largest open source project in the world behind only Linux. The cloud native ecosystem is flourishing and it’s exciting to be a part of.
If you plan to self-host software, of any complexity, in 2022 then you should consider running it on Kubernetes. Managing Kubernetes used to be a challenging undertaking. These days, with cloud-managed Kubernetes distributions like GKE and EKS, cluster management is no longer a heavy burden. Cloud providers can now offload the management of the control plane from the engineers who are responsible for the cluster and the applications in it. This recent evolution, coupled with a cloud native landscape that provides a solution for almost every requirement you could imagine, makes the draw to Kubernetes undeniable.
One of the few challenges that remains for Kubernetes is how to get started. Kubernetes is a complex engine with a sizable learning curve. When you couple that complexity with such an enormous CNCF landscape of cloud native tools, it’s easy to understand why many Kubernetes teams struggle to get their initial platforms established quickly. Adding a cloud native tool to your existing Kubernetes infrastructure couldn’t be easier, but starting from scratch can be a lot to take on.
At Kubefirst, we’ve spent years helping startups get started with Kubernetes, and wanted to share our roadmap on how to get started when adopting Kubernetes for the first time.

Step 1 - Decide on your git provider‍

Your git provider is the home for your source code, and the starting point for any continuous integration and delivery you’ll have in your future. Typically, this boils down to a choice between GitHub and GitLab. Choosing the right one for your organization depends on what kind of source code you have and who needs to see it. GitHub tends to be the go-to git provider for open source repositories while self-hosted GitLab tends to be the go-to git provider for private source repositories and ultimate control of your Git source code uptime and access.
GitHub is a SaaS offering, meaning they host your public or private repositories in their cloud instead of yours. GitLab also has SaaS, but a lot of their popularity spawns from their open source offering with the ability to self-host your git server and repositories in your own cluster.
These are both great products - one or the other will fit your needs quite nicely.

Step 2 - Automate Your Infrastructure as Code

Infrastructure as Code (IaC) is the foundation of any modern organization’s cloud infrastructure. IaC is a way of describing the cloud resources that you need in simple declarative code. Establishing your infrastructure as code means it will be clearly defined, versioned in git, and repeatable for a good disaster recovery posture.Each public cloud has its own proprietary IaC implementation like AWS CloudFormation or GCP Deployment Manager, but you should avoid these. There are great IaC tools, such as Terraform, Pulumi, and Crossplane that don’t lock you in with a cloud provider. Terraform is currently the industry standard for IaC and supports a lot of technologies. When using Terraform, don’t treat it like a command line tool, treat it more like a managed control plane by automating it with a tool like Atlantis, which gives Terraform the superpower of being fully auditable and integrated with your engineers’ pull request workflows in their git provider.
Other technologies to consider are Pulumi which allows users to code their infrastructure in more popular programming languages, or Crossplane, which allows users to code their infrastructure in YAML. Crossplane is an up-and-coming technology in our view that works especially well with the GitOps discipline.

Step 3 - Choose Your GitOps Driver

GitOps is a discipline that has gotten a lot of attention over the last couple of years and proponents make a compelling argument that it is the right way to manage Kubernetes resources.
GitOps marries your git provider with your Kubernetes engine and serves as an application control plane for your desired state. If set up correctly, a GitOps workflow can provide a complete registry of all Kubernetes resources across your organization in a single git repository.The GitOps approach provides substantial value in securing your clusters, managing your application inventory, scaling your applications across clusters, all while avoiding a bunch of software delivery scripting that would otherwise be needed in your continuous integration layer.
Choosing the right GitOps driver for you is one of your most important architectural decisions when designing your new Kubernetes platform. OpenGitOps offers a set of principles that define the GitOps discipline in a vendor-agnostic way to help guide you through this decision making process. The ultimate goal is to have a single GitOps repository be the exclusive mechanism for how anything gets established across your entire system in an automated fashion.

Step 4 - Commit to a Secrets Manager

On the surface, secrets management seems like it’s something easy to understand and a problem that’s simple to solve. Your application needs a password for a database connection, and as long as you can store that secret someplace secure, good enough right? The problem is that secrets are everywhere and need to be revocable and replaceable. There are application secrets, system secrets, CI secrets, cloud access secrets, leasable secrets, certs, and SSH keys, and they all have their own lifecycles and access requirements. Establishing a secrets manager too late in a project can be a major producer of technical debt, as secrets will scatter through your cloud provider’s secret system, your serverless system, your CI tools, and your engineers’ localhosts in a way that makes credential leaks easy and rotation difficult.If you get your secrets manager in as a priority, your organization can establish a healthy secrets rotation policy up front. Hashicorp Vault is the best in class open source secrets manager and it runs extremely well in Kubernetes.

Step 5 - Set up an Artifact Repository

This step is a detail more likely to fluctuate from shop to shop, in part because you have to define the types of artifacts that your codebase will produce. In a cloud native environment, this will be, at minimum, the container registry. If you're also packaging your Kubernetes applications with helm, you’ll also need a chart repository. If you plan to have language-specific libraries like npm packages for Nodejs, you’ll need a place to store those packages as well.
In the olden days of 2020, DockerHub was the go-to for container storage, but with their recent decisions to rate limit image pulls, many organizations are starting to host their containers either in their own cloud provider’s registry, or in an artifact repository that they host themselves in a tool like Harbor, Artifactory, Nexus, or in git providers GitHub or GitLab which also have certain package artifact repositories built in.

Step 6 - Build Out a Continuous Integration Pipeline

Continuous integration is the cornerstone of DevOps. CI is the spot where application source code ends and its packaging, publishing, testing, and promotion through environments begins.
There are many great CI tools of old and new. In our view, you should look into a few different technologies:Kubernetes-native, git agnostic options:

Tekton
Argo Workflows Self-hosted, git provider specific options:
GitLab Runner
GitHub Actions Runner Controller # Step 7 - Establish Authentication and Authorization As your project grows, authentication and authorization will require constant refinement and reassessment on a journey towards implementing the principle of least privilege. If you’re starting a new project, it is critical to start with some separation of duties between your team members. Roles should be established in your identity provider, your cloud, and your Kubernetes cluster. These roles should be leveraged by your platform tooling through configuration with your OIDC provider.To manage the assignment of these roles, many organizations will implement a user module in their infrastructure as code. Doing so affords you a consistent, transparent, and secure mechanism for controlling who has access to what. Engineering onboarding and offboarding becomes a matter of a simple Terraform pull request. # Step 8 - Wire Up Your Cluster to Enable Observability There are many open source options to build an observability platform, but it is tough to do it better or more affordably than a SaaS observability tool like Datadog. If running your observability in Datadog is within your budget, you should strongly consider doing it while you’re discovering and exploring your new cloud native needs. Datadog allows you to install an agent into your cluster that will enable application logging, container resource utilization, tracing, dashboarding, alerting, and an endless sea of evolving features that you just keep getting surprised by. Easy to use - single pane of glass - lets teams get good at Kubernetes fast. Self hosting highly available observability throughout your infrastructure and applications is a complex undertaking where you're committing engineering hours to keep your observability tuned and monitored with well maintained log indices and good expiration policies. As you get further down the road of your cloud native journey, you’ll discover that there are indeed cloud native tools to solve each of the problems that datadog solves - Prometheus for metrics, Grafana for dashboarding, Jaeger for tracing and application performance monitoring, and many different options for logging. If the cost savings are compelling enough, transitioning to a self-hosted observability ecosystem is a great year two or three goal in your cloud native journey. # The 1-Step Alternative At Kubefirst, we’ve spent years refining the process of provisioning platforms from scratch with the most popular cloud native tools. Now, with our open source kubefirst CLI you can have all these pieces automated, integrated, and self hosted in your cloud in under 25 minutes. You can remove any of our pieces and replace them with yours, or just expand from here and flourish in your new instant cloud native ecosystem. Whether you decide to build the platform yourself or not, these are the technologies that the Kubefirst community has adopted. Our users will be using these same tools this same way. If you think that’s valuable to your organization, we’d love for you to join our community. If you want to keep tabs on our project, throw us a Github star for our open source effort.

Forem: Kubeshop

Introducing Botkube Fuse: The Platform Engineer’s Copilot

The Problem: Context Switching is Draining Your Productivity

The Solution: Your Intelligent Platform Assistant, Right in Your Terminal

Botkube Fuse in Your Daily Workflow

How It Works

Ready to Dive In? Set Up Botkube Fuse in Minutes

Monokle, Helm & Quality Kubernetes Deployments

Monokle, Helm & Quality Kubernetes Deployments

How teams leverage Helm in Kubernetes deployments

What are the challenges of working with Helm charts?

How does Monokle Desktop help with deploying to Kubernetes via Helm?

Navigate your Helm charts

Preview and debug Helm charts

Example: Defining releases with Helm

Next steps for Monokle

Take the Helm with Monokle

A Dream Fulfilled at KubeCon NA

Let's hear it for the sponsors!

GitOpsCon vs kubefirst local

Walking through KubeCon is like walking through a kubernetes cluster

Meeting some of the great folks in the space

Pitching on the floor is admittedly a little exhausting

There's some room for fun at KubeCon too

Never give up - it's soooo worth it

How Kubefirst Builds Kubernetes Platforms in 8 Steps

An Open Source Approach to Self Hosting a GitOps Platform

Step 1 - Decide on your git provider‍

Step 2 - Automate Your Infrastructure as Code

Step 3 - Choose Your GitOps Driver

Step 4 - Commit to a Secrets Manager

Step 5 - Set up an Artifact Repository

Step 6 - Build Out a Continuous Integration Pipeline

GitOpsCon vs `kubefirst local`