Kubernetes ist zum Rückgrat der modernen digitalen Infrastruktur geworden – es treibt alles an, von SaaS-Plattformen bis hin zu unternehmenskritischen Systemen im Gesundheitswesen, in der Finanzbranche und in der öffentlichen Verwaltung.
Doch eine Sache wird immer noch weit unterschätzt: Kubernetes allein reicht nicht.
Der Betrieb von Kubernetes in Produktion erfordert weit mehr als das Upstream-Projekt. Du brauchst Netzwerk, Storage, Observability, Security-Hardening, Upgrade-Tooling und operative Prozesse – alles eng integriert und kontinuierlich gepflegt.
Genau hier kommen Kubernetes-Distributionen ins Spiel.
Und wenn du diese Komplexität nicht selbst betreiben möchtest, gibt es eine Abstraktionsebene höher: Managed Kubernetes oder Managed OpenShift.
In diesem Beitrag werfen wir einen Blick auf die Kubernetes-Distributionslandschaft im Jahr 2026 und erklären, warum das Auslagern des Betriebs oft die klügste Wahl ist.
Metal³ (pronounced “metal cubed”) is an open-source project that provides a set of tools for managing bare-metal infrastructure using Kubernetes.
Mission
The Metal3 Project's mission is to empower organizations with a flexible, open-source solution for bare metal provisioning that combines the benefits of bare metal performance with the ease of use and automation provided by Kubernetes.
Goals
There are a number of great open source tools for bare metal host provisioning, including Ironic. Metal³ aims to build on these technologies to provide a Kubernetes native API for managing bare metal hosts via a provisioning stack that is also running on Kubernetes. We believe that Kubernetes Native Infrastructure, or managing your infrastructure just like your applications, is a powerful next step in the evolution of infrastructure management.
The Metal³ project is also building integration with the Kubernetes cluster-api project, allowing Metal3 to be used as an infrastructure backend for Machine objects from the Cluster API.
These components integrate seamlessly to leverage the Kubernetes ecosystem and automate the provisioning and management of bare-metal infrastructure.
kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster.
Important
This is a supported replacement of the original GoogleContainerTools/kaniko repository, which was archived in June of 2025. Further details in History and Status.
kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster.
kaniko is meant to be run as an image. We do not recommend running the kaniko executor binary in another image, as it might not work as you expect - see Known Issues.
metal-stack® is a set of microservices implementing Metal as a Service (MaaS), turning a bunch of hardware into elastic cloud infrastructure. It is built to manage the lifecycles for hundreds and thousands of servers inside your on-premise data center.
Talos Linux is a modern Linux distribution built for Kubernetes.
Talos Linux is Linux designed for Kubernetes – secure, immutable, and minimal.
- Supports cloud platforms, bare metal, and virtualization platforms
- All system management is done via an API. No SSH, shell or console
- Production ready: supports some of the largest Kubernetes clusters in the world
- Open source project from the team at Sidero Labs
Github: Talos releases
You can use Docker with the Dev Containers extension in a few ways:
- Docker installed locally.
- Docker installed on another machine or remote environment.
- You only need Docker installed on the remote host, rather than Docker installed locally.
- Other Docker compliant CLIs, installed locally or in a remote environment.
- For instance, Rancher Desktop is another way to install Docker, providing container management and Kubernetes on Windows, macOS, and Linux.
- Since Rancher Desktop supports Docker CLI via Moby, you can use Dev Containers extension with it. You may learn how to get started in Rancher Desktop's guide.
- Dev Containers interacts with CLIs; it makes no assumptions about how a container engine works and does not interact with container engines or daemons directly.
- Note that other Docker compliant CLIs are not officially supported.
Continue reading to learn alternate ways you can install and use Docker or a Docker compliant CLI.
- VSCode extension: Dev Containers
- GitHub - microsoft/vscode-remote-release: Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
- Visual Studio Code Remote Development
- Developing inside a Container using Visual Studio Code Remote Development
The K10 data management platform, purpose-built for Kubernetes, provides enterprise operations teams an easy-to-use, scalable, and secure system for backup/restore, disaster recovery, and mobility of Kubernetes applications.
K10’s application-centric approach and deep integrations with relational and NoSQL databases, Kubernetes distributions, and all clouds provides teams the freedom of infrastructure choice without sacrificing operational simplicity. Policy-driven and extensible, K10 provides a native Kubernetes API and includes features such full-spectrum consistency, database integrations, automatic application discovery, multi-cloud mobility, and a powerful web-based user interface.
Given K10’s extensive ecosystem support you have the flexibility to choose environments (public/ private/ hybrid cloud/ on-prem) and Kubernetes distributions (cloud vendor managed or self managed) in support of three principal use cases:
-
Application Mobility
-

Kubernetes is an open-source orchestration engine for automating deployments, scaling, managing, and providing the infrastructure to host containerized applications. At the infrastructure level, a Kubernetes cluster is comprised of a set of physical or virtual machines, each acting in a specific role.
The master machines act as the brain of all operations and are charged with orchestrating containers that run on all of the node machines. Each node is equipped with a container runtime. The node receives instruction from the master and then takes actions to either create pods, delete them, or adjust networking rules.

k3s ist eine schlanke Variante zum vollen Kubernetes (k8s) Stack. Der k3s Cluster lässt sich daher mit wenigen Schritten installieren und einrichten. Dieses Tutorial beschreibt dir wie du den k3s Cluster installieren kannst.
Running a Kubernetes Cluster in your own data center on Bare Metal hardware can be lots of fun but also can be challenging. One of the changeless are exposing your service to an external Load Balancer, Kubernetes does not offer an implementation of an external load-balancer for bare metal cluster implementations. The Kubernetes implementations of Network Load Balancers are only available on specific Cloud Providers like AWS, GCP, Azure, etc.. and is enabled by specifying the –cloud-provider= option. leaving a gap/challenge if you create your own Bare Metal Kubernetes Cluster. While their are many workarounds to address this issue most of them are not perfect and have their own list of challenges. while I was looking for a for a solution, most recently came across a project called MetalLB, at first I was quite sceptical if its going to work, but after testing this for a while I have to say, I am quite happy with the solution.
In this post we’ll look at how ingress works in a K3s cluster. For background, I recommend reading the Networking Section of the K3s documentation.
Ingress Overview
K3s automatically deploys the Traefik Ingress Controller and provides a service load balancer called Klipper.
The Gateway API project is the successor to the Ingress API. However, it does not include the Ingress resource (the closest parallel is the HTTPRoute). As a result, a one-time conversion from your existing Ingress resources to the relevant Gateway API resources is necessary.
This guide will help you with the conversion. It will:
- Explain why you may want to switch to the Gateway API.
- Describe the key differences between the Ingress API and the Gateway API.
- Map Ingress features to Gateway API features.
- Show an example of an Ingress resource converted to Gateway API resources.
- Mention ingress2gateway for automatic conversion.
At the same time, it will not prepare you for a live migration or explain how to convert some implementation-specific features of your Ingress controller. Additionally, since the Ingress API only covers HTTP/HTTPS traffic, this guide does not cover the Gateway API support for other protocols.
The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your cluster, and helps you obtain a deeper understanding of how Kubernetes works.
![]()
Podman is a daemonless container engine for developing, managing, and running Open Container Initiative (OCI) containers on Linux systems. Included in Red Hat Enterprise Linux 7.6 and later, Podman lets you create and manage rootless containers, which don't require root access to be built and deployed.
Podman is an excellent alternative to Docker containers when you need increased security, unique identifier (UID) separation using namespaces, and integration with systemd.
Download the Podman Cheat Sheet and explore basic commands for managing images, containers, and container resources. You’ll learn how to:
- Work with image repositories
- Build container images
- Create and run containers
- Manage container processes and resources
- Work with a host compiler’s file system
With Red Hat Developer cheat sheets, you get essential information right at your fingertips so you can work faster and smarter. Easily learn new technologies and coding concepts and quickly find the answers you need.
The original Quadlet repository describes Quadlet this way:
What do you get if you squash a Kubernetes kubelet?
A quadlet
Quadlet is a tool for running Podman containers under systemd in an optimal way by allowing containers to run under systemd in a declarative way. It has been merged into Podman 4.4.
Welcome

Traefik is an open-source Edge Router that makes publishing your services a fun and easy experience. It receives requests on behalf of your system and finds out which components are responsible for handling them.
What sets Traefik apart, besides its many features, is that it automatically discovers the right configuration for your services. The magic happens when Traefik inspects your infrastructure, where it finds relevant information and discovers which service serves which request.
Traefik is natively compliant with every major cluster technology, such as Kubernetes, Docker, Docker Swarm, AWS, Mesos, Marathon, and the list goes on; and can handle many at the same time. (It even works for legacy software running on bare metal.)
With Traefik, there is no need to maintain and synchronize a separate configuration file: everything happens automatically, in real time (no restarts, no connection interruptions). With Traefik, you spend time developing and deploying new features to your system, not on configuring and maintaining its working state.
Developing Traefik, our main goal is to make it simple to use, and we're sure you'll enjoy it.
Running Vault on Kubernetes is generally the same as running it anywhere else. Kubernetes, as a container orchestration engine, eases some of the operational burdens and Helm charts provide the benefit of a refined interface when it comes to deploying Vault in a variety of different modes.
In this tutorial, you will set up Vault and its dependencies with a Helm chart. You will then integrate a web application that uses the Kubernetes service account token to authenticate with Vault and retrieve a secret.
![]()
Lightweight Kubernetes. Easy to install, half the memory, all in a binary of less than 100 MB.
Great for:
- Edge
- IoT
- CI
- Development
- ARM
- Embedding K8s
- Situations where a PhD in K8s clusterology is infeasible
Strimzi provides a way to run an Apache Kafka cluster on Kubernetes in various deployment configurations.